Mark C. Layton

Article / Updated 01-23-2024

Agile principles are designed specifically to increase the success of your projects. Agility in project management encompasses three key areas: Making sure the development team can be productive and can sustainably increase productivity over long periods of time Ensuring that information about the project’s progress is available to stakeholders without interrupting the flow of development activities by asking the development team for updates Handling requests for new features as they occur and integrating them into the product development cycle An agile approach focuses on planning and executing the work to produce the best product that can be released. The approach is supported by communicating openly, avoiding distractions and wasteful activities, and ensuring that the progress of the project is clear to everyone. All 12 principles support project management, but principles 2, 8, and 10 stand out: (2) Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. (8) Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. (10) Simplicity — the art of maximizing the amount of work not done — is essential. Following are some advantages of adopting agile project management: Agile project teams achieve faster time-to-market, and consequentially cost savings. They start development earlier than in traditional approaches because agile approaches minimize the exhaustive upfront planning and documentation that is conventionally part of the early stages of a waterfall project. Agile development teams are self-organizing and self-managing. The managerial effort normally put into telling developers how to do their work can be applied to removing impediments and organizational distractions that slow down the development team. Agile development teams determine how much work they can accomplish in an iteration and commit to achieving those goals. Ownership is fundamentally different because the development team is establishing the commitment, not complying with an externally developed commitment. An agile approach asks, “What is the minimum we can do to achieve the goal?” instead of focusing on including all the features and extra refinements that could possibly be needed. An agile approach usually means streamlining: barely sufficient documentation, removal of unnecessary meetings, avoidance of inefficient communication (such as email), and less coding (just enough to make it work). Creating complicated documents that aren’t useful for product development is a waste of effort. It’s okay to document a decision, but you don’t need multiple pages on the history and nuances of how the decision was made. Keep the documentation barely sufficient, and you will have more time to focus on supporting the development team. By encapsulating development into short sprints that last one to four weeks or less, you can adhere to the goals of the current iteration while accommodating change in subsequent iterations. The length of each sprint remains the same throughout the project to provide a predictable rhythm of development for the team long-term. Planning, elaborating on requirements, developing, testing, and demonstrating functionality occur within an iteration, lowering the risk of heading in the wrong direction for extended periods of time or developing something that the customer doesn’t want. Agile practices encourage a steady pace of development that is productive and healthy. For example, in the popular agile development set of practices called extreme programming (XP), the maximum workweek is 40 hours, and the preferred workweek is 35 hours. Agile projects are sustainable and more productive, especially long term. Traditional approaches routinely feature a death march, in which the project team puts in extremely long hours for days and even weeks at the end of a project to meet a previously unidentified and unrealistic deadline. As the death march goes on, productivity tends to drop dramatically. More defects are introduced, and because defects need to be corrected in a way that doesn’t break a different piece of functionality, correcting defects is the most expensive work that can be performed. Defects are often the result of overloading a system — specifically demanding an unsustainable pace of work. Priorities, experience on the existing project, and, eventually, the speed at which development will likely occur within each sprint are clear, making for good decisions about how much can or should be accomplished in a given amount of time. If you’ve worked on a project before, you might have a basic understanding of project management activities. In this table, you find a few traditional project management tasks, along with how you would meet those needs with agile approaches. Use the table to capture your thoughts about your experiences and how agile approaches looks different from traditional project management. Contrasting Historical Project Management with Agile Project Management Traditional Project Management Tasks Agile Approach to the Project Management Task Create a fully detailed project requirement document at the beginning of the project. Try to control requirement changes throughout the project. Create a product backlog — a simple list of requirements by priority. Quickly update the product backlog as requirements and priorities change throughout the project. Conduct weekly status meetings with all project stakeholders and developers. Send out detailed meeting notes and status reports after each meeting. The development team meets quickly, for no longer than 15 minutes, at the start of each day to coordinate and synchronize that day’s work and any roadblocks. They can update the centrally visible burndown chart in under a minute at the end of each day. Create a detailed project schedule with all tasks at the beginning of the project. Try to keep the project tasks on schedule. Update the schedule on a regular basis. Work within sprints and identify only specific tasks for the active sprint. Assign tasks to the development team. Support the development team by helping remove impediments and distractions. On agile projects, development teams define and pull (as opposed to push) their own tasks. Project management is facilitated by the following agile approaches: Supporting the development team Producing barely sufficient documents Streamlining status reporting so that information is pushed out by the development team in seconds rather than pulled out by a project manager over a longer period of time Minimizing nondevelopment tasks Setting expectations that change is normal and beneficial, not something to be feared or evaded Adopting a just-in-time requirements refinement to minimize change disruption and wasted effort Collaborating with the development team to create realistic schedules, targets, and goals Protecting the development team from organizational disruptions that could undermine project goals by introducing work not relevant to the project objectives Understanding that an appropriate balance between work and life is a component of efficient development

Article / Updated 01-23-2024

Agile approaches focus on customer satisfaction, which makes sense. After all, the customer is the reason for developing the product in the first place. While all 12 principles support the goal of satisfying customers, principles 1, 2, 3, and 4 stand out for us: (1) Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. (2) Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. (3) Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. (4) Business people and developers must work together daily throughout the project. You may define the customer on a project in a number of ways: In project management terms, the customer is the person or group paying for the project. In some organizations, the customer may be a client, external to the organization. In other organizations, the customer may be a project stakeholder or stakeholders in the organization. The person who ends up using the product is also a customer. How do you enact these principles? Simply do the following: Agile project teams include a product owner, a person who is responsible for ensuring translation of what the customer wants into product requirements. The product owner prioritizes product features in order of business value or risk and communicates priorities to the development team. The development team delivers the most valuable features on the list in short cycles of development, known as iterations or sprints. The product owner has deep and ongoing involvement throughout each day to clarify priorities and requirements, make decisions, provide feedback, and quickly answer the many questions that pop up during a project. Frequent delivery of working functionality allows the product owner and the customer to have a full sense of how the product is developing. As the development team continues to deliver complete, working, potentially shippable functionality every four to eight weeks or less, the value of the total product grows incrementally, as do its functional capabilities. The customer accumulates value for his or her investment regularly by receiving new, ready-to-use functionality throughout the project, rather than waiting until the end of what might be a long project for the first, and maybe only, delivery of releasable product features. This table shows some customer satisfaction issues that commonly arise on projects. Use the table and gather some examples of customer dissatisfaction that you’ve encountered. Do you think agile project management would make a difference? Why or why not? Customer Dissatisfaction and How Agile Might Help Examples of Customer Dissatisfaction with Projects How Agile Approaches Can Increase Customer Satisfaction The product requirements were misunderstood by the development team. Product owners work closely with the customer to define and refine product requirements and provide clarity to the development team. Agile project teams demonstrate and deliver working functionality at regular intervals. If a product doesn’t work the way the customer thinks it should work, the customer is able to provide feedback at the end of the sprint, not before it’s too late at the end of the project. The product wasn’t delivered when the customer needed it. Working in sprints allows agile project teams to deliver high-priority functionality early and often. The customer can’t request changes without additional cost and time. Agile processes are built for change. Development teams can accommodate new requirements, requirement updates, and shifting priorities with each sprint, offsetting the cost of these changes by removing the lowest-priority requirements — functionality that likely will never or rarely get used. Check here for a blank template of this agile form. Agile strategies for customer satisfaction include the following: Producing, in each iteration, the highest-priority features first Ideally, locating the product owner and the other members of the project team in the same place to eliminate communication barriers Breaking requirements into groups of features that can be delivered in four to eight weeks or less Keeping written requirements sparse, forcing more robust and effective face-to-face communication Getting the product owner’s approval as functionality is completed Revisiting the feature list regularly to ensure that the most valuable requirements continue to have the highest priority

Cheat Sheet / Updated 10-26-2022

Scrum ensures transparency, inspection, and adaptation to enable a focus on continuous improvement, scope flexibility, team input, and delivering quality products. Scrum aligns with the values and principles of the Agile Manifesto, which focus on people, communications, the product, and flexibility. This Cheat Sheet outlines the main principles of the scrum project management method.

Article / Updated 03-15-2021

Agile is a descriptor of a mindset approach to project management that focuses on early delivery of business value, continuous improvement of the product being created and the processes used to create the product, scope flexibility, team input, and delivering well-tested products that reflect customer needs. The seeds for agile techniques have been around for a long time. In fact, agile values, principles, and practices are simply a codification of common sense. This figure shows a quick history of agile project management, dating to the 1930s with Walter Sherwart's Plan-Do-Study-Act (PDSA) approach to project quality. In 1986, Hirotaka Takeuchi and Ikujiro Nonaka published an article called “The New New Product Development Game” in the Harvard Business Review. Takeuchi and Nonaka's article described a rapid, flexible development strategy to meet fast-paced product demands. This article first paired the term scrum with product development. (Scrum referred to a player formation in rugby.) Scrum eventually became one of the most popular agile frameworks for delivering value to customers. In 2001, a group of software and project experts got together to talk about what their successful projects had in common. This group created the Manifesto for Agile Software Development (commonly referred to as the Agile Manifesto), a statement of values for successful software development: Manifesto for Agile Software Development* We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. * Agile Manifesto Copyright © 2001: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas. This declaration may be freely copied in any form, but only in its entirety through this notice. These experts also created twelve principles behind the Agile Manifesto that help support the values in the Agile Manifesto. Agile, in product development terms, is a descriptor for approaches that focus on people, communications, the product, and flexibility. If you’re looking for the agile methodology, you won’t find it. However, all agile methodologies (for example, Crystal), frameworks (for example, scrum), techniques (for example, user story requirements), and tools (for example, relative estimating) have one thing in common: adherence to the Agile Manifesto and the twelve Agile Principles. Martin Fowler, one of the co-authors of the Agile Manifesto, writes that many different words were discussed for naming their movement. They considered lightweight methods, adaptive, and many others until landing on agile as the best descriptor of the adaptiveness and responsiveness to change they were seeking. Other synonyms are resilient, nimble, and healthy. When you think of agile, think healthy. Healthy organizations and teams are agile, resilient, nimble, and responsive. How agile projects work Agile approaches are based on an empirical control method — a process of making decisions based on the realities observed in the project. In the context of software development methodologies, an empirical approach can be effective in both new product development and enhancement and upgrade projects. By using frequent and firsthand inspection of the work to date, you can make immediate adjustments, if necessary. Empirical control requires: Unfettered transparency: Everyone involved in an agile project knows what is going on and how the project is progressing. Frequent inspection: The people who are invested in the product and process the most regularly evaluate the product and process. Immediate adaptation: Adjustments are made quickly to minimize problems; if an inspection shows that something should change, it is changed immediately. To accommodate frequent inspection and immediate adaptation, agile projects work in iterations (smaller segments of the overall project). An agile product development effort involves the same type of work as in a traditional waterfall project: You create requirements and designs, develop product features, document what was done and why, and continuously integrate new features. You test the product, fix any problems, and deploy the product for use. However, instead of completing these steps for all product features at once, as in a waterfall project, you break the project into iterations, also called sprints. This figure shows the difference between a linear waterfall project and an agile project. Mixing traditional project management methods with agile approaches is like saying, “I have a Tesla Model S. However, I'm using a wagon wheel on the front left side. How can I make my car as fast and efficient as the other Teslas?” The answer, of course, is you can't. If you fully commit to an agile approach, you will have a better chance of project success.

Article / Updated 03-15-2021

Traditional approaches to project management focus significantly on processes, tools, comprehensive documentation, contract negotiation, and following a plan. Although agile product development remains dedicated to addressing each of these, the focus shifts to individuals, interactions, working functionality, customer collaboration, and responding to change. Becoming agile requires change Waterfall organizations didn’t get where they are overnight and won't change overnight. For some organizations, decades of forming habits, establishing and protecting fiefdoms, and reinforcing a traditional mindset are engrained. The organizational structure will require some type of change, the leadership will need to learn a new way of looking at developing people and empowering them to do their work, and those doing the work will have to learn to work together and manage themselves in ways that may feel foreign. Organizational change initiatives typically fail without a strategy and discipline. Here, we define failure as not reaching the desired end state goal of what the organization will look like after the change. Failure is often due to being unclear as to the goal or because the change plan doesn’t address the highest risk factors and challenges impeding the desired change. Lewin's change philosophy Kurt Lewin was an innovator in social and organizational psychology in the 1940s and established a cornerstone model for understanding effective organizational change. Most modern change models are based on this philosophy, which is unfreeze — change — refreeze, as illustrated. If you want to change the shape of a cube of ice, you first have to change it from its existing frozen state to liquid so that it can be changed or reshaped, then mold the liquid into the new shape you want, then put it through a solidification process to form the new shape. Unfreezing is implied between the first two states in the figure, and the changes made are implied during the unfrozen state. Unfreeze The first stage represents the preparation needed before change can take place — challenging existing beliefs, values, and behaviors. Reexamination and seeking motivation for a new equilibrium is what leads to participation and buy-in for meaningful change. Change The next stage involves uncertainty and resolving that uncertainty to do things a new way. This transitional stage represents the formation of new beliefs, values, and behaviors. Time and communication are the keys to seeing the changes begin to take effect. Refreeze As people embrace new ways, confidence and stability increase, and the change starts to take shape into a solid new process, structure, belief system, or set of behaviors. This simple pattern provides the foundation for most change management tools and frameworks. ADKAR’s 5 steps to change Prosci is one of the leading organizations in change management and benchmarking research. One of Prosci’s change management tools, ADKAR, is an acronym for the five outcomes (awareness, desire, knowledge, ability, and reinforcement) individuals and organizations need to achieve for successful change. It is a goal-oriented model for individuals, and a focus model for the discussions and actions organizations need to take together. Organizational changes still require change for individuals, so the secret to success is affecting change for everyone involved. ADKAR outlines the individual’s successful journey through change. The five steps of the journey also each align with organizational change activities. Typically, these steps are completed in the order listed, but a non-linear approach is realistic in our experience. You may need to readdress previous steps multiple times as you progress through each step. Awareness Humans find change difficult. When change initiatives come top-down in an organization, people may verbally agree to them, but their actions tell a different story. Mismatch of actions and words is usually innocent and natural. Without awareness, or an understanding of the factors influencing management’s desire to change, or especially without a recognition that something should change, individuals will not be motivated to change. Informing the individuals in an organization, helping them have a shared understanding of the challenges that exist, and then assessing whether awareness is common constitute the first step to successful, lasting change. It is the basis, without which the initiative won’t make progress. Desire Based on their awareness of a challenge needing to be addressed, individuals will have an opinion on whether or not change is necessary or desired to address it. Making the connection between the awareness of an issue and what could or should be done about it is the next step. Once desire exists for the individuals in an organization, there is motivation to move together to change. Knowledge Desire is key, but it won’t result in change by itself. Knowledge of how to make the change and where each individual fits into the change make up the next crucial part of the change process. Individuals throughout the organization need to understand what the changes mean for them, and leadership needs to facilitate education and actions in a cooperative way across the organization. Knowledge often comes from expanding understanding and skills through training and coaching. Ability With new knowledge of how to change, implementation requires acquiring skills, redefining roles, and clearly defining new performance expectations. Other commitments may need to be delayed or replaced with new behaviors or responsibilities. Continued coaching and mentoring may be required, and leadership needs to be clear that this reprioritization of commitments is expected and encouraged. Reinforcement Changes don’t stick after one successful iteration. New behaviors, skills, and processes must be reinforced through continued corrective action and coaching to ensure that old habits don’t return. The ADKAR model surrounds these steps with assessments and action plans to guide leaders and individuals through their change journey. ADKAR should be used iteratively, using scrum, inspecting and adapting each step. Kotter’s 8 steps for leading change John Kotter’s eight-step process for leading change identifies eight common but preventable reasons why organizations fail at their change initiatives, and addresses each with actions that should be taken to successfully lead change: Create a sense of urgency: The leadership action is to create a sense of urgency to pull people out of complacency. People get used to the status quo, and learn to deal with it. Helping others see the need for change requires the creation of a sense of urgency for change. Leaders must communicate the importance of immediate action. Build a guiding coalition: The leadership action is to build a guiding coalition. Successful change will require more than just one active supporter, even if that one person is at the highest level of the organization. Executives, directors, managers, and even informal social leaders with influence need to be unified in the need for and vision of a change. This coalition must be formed and drive the change. Form a strategic vision and initiatives: Kotter estimates that leadership under-communicates the vision for change by as much as 1,000 times. Even if people are unhappy with the status quo, they won’t always make sacrifices for a change unless they believe in the proposed benefits and that change is possible. As a change coalition, clearly define how the future is different from the past and present, as well as the steps to make that future a reality. Change management also needs to begin with a clear vision of where you’re headed. Enlist a volunteer army: The leadership action is to enlist a volunteer army. Change will accelerate and last if massive numbers of people buy in and are internally driven. As a result of leadership’s effective communication of vision and need, people should rally around a cause they come to believe in. If they don’t rally, reevaluate your messaging, tone, and frequency. Enable action by removing barriers: The leadership action is to remove barriers to action. Some obstacles may be only perceived, but others are real. However, both must be overcome. One blocker in the “right” place can be the single reason for failure. Many people tend to avoid confronting obstacles (processes, hierarchies, working across silos), so leadership must act as servant-leaders to identify and remove impediments that are reducing the empowerment of individuals implementing the changes on the front lines. Generate short-term wins: The leadership action is to generate short-term wins. The end transformation goal usually can’t be achieved in the short term, so fatigue can set in for everyone involved if successes and progress go unrecognized along the way. Evidence of change should be highlighted and exposed early and regularly. This reinforcement increases morale through difficult times of change, and motivates and encourages continued efforts and progress. Sustain acceleration: The leadership action is to sustain acceleration. Celebrating short-term wins sets a false sense of security that change is complete. Each success should build on the previous success. Push on, and push on harder after each success, with increased confidence and credibility. Continue to overcommunicate the vision throughout the transformation. Institute change: The leadership action is to institute change. Leadership will have the opportunity throughout the change process to connect successes and new behaviors with the culture's evolution and growing strength to keep old habits from returning. These connections should be recognized openly and made visible to everyone as soon as successes and new behaviors are realized.

Article / Updated 03-15-2021

Agile processes are different from traditional project management. Moving an organization from waterfall to an agile mindset is a significant change. Through our experience guiding companies through this type of change, we’ve identified the following important steps to successfully become an agile organization. This figure illustrates our agile transition roadmap for successful agile transformation. Step 1: Conduct an agile audit to define an implementation strategy with success metrics An agile audit of your organization is: A three- to five-week review of the existing project management, product development, corporate structure, objectives, and culture Identification of opportunities to improve efficiency, effectiveness, and agility Creation and presentation of an implementation strategy and roadmap An implementation strategy is a plan that outlines the following: Your current strengths to build on as you transition The challenges you’ll face based on your current structure Action items for how your organization will transition to agile product development Implementation strategies are most effectively performed by external agile experts in the form of an assessment or a current state audit. Whether you engage with a third party or conduct the assessment yourself, make sure the following questions are addressed: Current processes: How does your organization develop products today? What does it do well? What are its problems? Future processes: How can your company benefit from agile approaches? What agile methods or frameworks will you use? What key changes will your organization need to make? What will your transformed company look like from a team and process perspective? Step-by-step plan: How will you move from existing processes to agile processes? What will change immediately? In six months? In a year or longer? This plan should be a roadmap of successive steps getting the company to a sustainable state of agile maturity. Benefits: What advantages will the agile transition provide for the people and groups in your organization and the organization as a whole? Agile techniques are a win for most people; identify how they will benefit. Potential challenges: What will be the most difficult changes? What training will be required? What departments or people will have the most trouble with agile approaches? Whose fiefdom is being disrupted? What are your potential roadblocks? How will you overcome these challenges? Success factors: What organizational factors will help you while switching to agile processes? How will the company commit to a new approach? Which people or departments will be agile champions? A good implementation strategy will guide your company through its move to agile practices. A strategy can provide supporters with a clear plan to rally around and support, and it can set realistic expectations for your organization’s agile transition. For your first agile product development effort, identify a quantifiable way to recognize success. Using metrics will give you a way to instantly demonstrate success to stakeholders and your organization. Metrics provide specific goals and talking points for sprint retrospectives and help set clear expectations for the team. Metrics related to people and performance work best when related to teams rather than to individuals. Scrum teams manage themselves as a team, succeed as a team, fail as a team—and should be evaluated as a team. Keeping track of success measurements can do more than help you improve throughout your work. Metrics can provide clear proof of success when you move past your first product and start to scale agile practices throughout your organization. Step 2: Build awareness and excitement After you have a roadmap showing you the “how” of your agile transition, you need to communicate the coming changes to people in your organization. Agile approaches have many benefits; be sure to let all individuals in your company know about those benefits and get them excited about the coming changes. Here are some ways to build awareness: Educate people. People in your organization may not know much — or anything — about agile product development. Educate people about agile principles and approaches and the change that will accompany the new approaches. You can create an agile wiki, hold lunchtime learning sessions, and even have hot-seat discussions (face-to-face discussions with leadership where people can talk safely about concerns and get their questions answered about changes and agile topics) to address concerns with the transition. Use a variety of communication tools. Take advantage of communication channels such as newsletters, blogs, intranets, email, and face-to-face workshops to get the word out about the change coming to your organization. Highlight the benefits. Make sure people in your company know how an agile approach will help the organization create high-value products, lead to customer satisfaction, and increase employee morale. Share the implementation plan. Make your transition plan available to everyone. Talk about it, both formally and informally. Offer to walk people through it and answer questions. We often print the transition roadmap on posters and distribute it throughout the organization. Involve the initial scrum team. As early as you can, let the people who may work on your company’s first agile pilot know about the upcoming changes. Involve the pilot scrum team members in planning the transition to help them become enthusiastic agile practitioners. Be open. Drive the conversation about new processes. Try to stay ahead of the company rumor mill by speaking openly, answering questions, and quelling myths about the agile transition. Structured communications like the hot-seat sessions we mention earlier are a great example of open communication. Building awareness will generate support for the upcoming changes and alleviate some of the fear that naturally comes with change. Communication will be an important tool to help you successfully implement agile processes. Step 3: Form a transformation team and identify a pilot Identify a team in your company that can be responsible for the agile transformation at the organization level. This agile transition team is made up of executives and other leaders who will systematically improve processes, reporting requirements, and performance measurements across the organization. Selecting people for the team who are passionate about and committed to helping the organization become more adaptive and resilient is paramount. The agile transition team will create organizational changes within sprints, just like the development team creates product features within sprints. The transition team will focus on the highest-priority changes supporting agility in each sprint and will demonstrate its implementation, when possible, during a sprint review with all stakeholders, including the pilot scrum team members. Starting your agile transition with just one pilot is a great way to establish a reference model of what a scrum team can look like and to demonstrate the benefits of an agile approach. Having a reference model allows you to figure out how to work with agile methods with little disruption to your organization’s overall business. Concentrating on one pilot to start also lets you work out some of the kinks that inevitably follow change. The following figure shows the types of development efforts that benefit most from the agile approach. When selecting your first agile pilot to establish a reference model for future scrum teams, look for an endeavor with these qualities: Appropriately important: Make sure the product you choose is important enough to merit interest within your company. However, avoid the most important product coming up; you want room to make and learn from mistakes. See the note on the blame game in the later section "Avoiding Pitfalls." Sufficiently visible: Your pilot should be visible to your organization’s key influencers, but don’t make it the most high-profile item on the agenda. You will need the freedom to adjust to new processes; critical product development efforts may not allow for that freedom on the first try of a new approach. Clear and containable: Look for a product with clear requirements and a business group that can commit to defining and prioritizing those requirements. Try to choose a product that has a distinct end point, rather than one that can expand indefinitely. Not too large: Select a pilot that you can complete with no more than two scrum teams working simultaneously to prevent too many moving parts at once. A single-team pilot is preferred. Tangibly measurable: Choose an endeavor that you know can show measurable value within sprints. People need time to adjust to organizational changes of any type, not just agile transitions. Studies have found that with large changes, companies and teams will see dips in performance before they see improvements. Satir's Curve, shown here, illustrates the process of teams' excitement, chaos, and finally adjustment to new processes. After you’ve successfully used agile techniques on one agile product development, you’ll have a reference model and foundation for future successes. Step 4: Build an environment for success One of the agile principles states, “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.” Study the four agile values and the twelve agile principles carefully and seriously to determine whether you’re creating an environment for success or rationalizing that the status quo is good enough. Start fixing and improving your physical and cultural environment as early as possible. Step 5: Train sufficiently and recruit as needed Training is a critical step when shifting to an agile mindset. The combination of face-to-face training with experienced agile experts and the ability to work through exercises using agile processes is the best way to help the team to absorb and develop the knowledge needed to successfully begin. Training works best when the members of the team can train and learn together, and then bring the shared experience back to work with them. A common language and understanding exist among them. As agile trainers and mentors, we’ve had the opportunity to overhear conversations between team members that start, “Remember when Mark showed us how to …? That worked when we did it in class. Let’s try it and see what happens.” If the product owner, development team, scrum master, and stakeholders can attend the same class, they can apply lessons to their work as a team. Recruiting talent to fill gaps in the roles you need avoids the obvious problems you'll have at the start of the transition. Without a dedicated product owner and his or her clear direction to the team, how likely is your pilot to succeed? How will that affect the team’s ability to self-organize? Who will facilitate the many interactions if you’re missing a scrum master? What will the first sprint look like if you’re missing a key skill on the development team required to minimally achieve the first sprint goal? Work with your human resources department as early as possible to start the recruiting process. Work with your agile expert advisers to tap into their network of experienced agile practitioners. Step 6: Kick off the pilot with active coaching When you have a clear agile implementation strategy, an excited and trained team, a pilot product with a product backlog, and clear measures for success, congratulations! You’re ready to run your first sprint. Don’t forget, though — agile approaches are new to the pilot team. Teams need coaching to become high performing. Engage with agile experts for agile coaching to start your pilot right. Practice doesn’t make perfect. Practice makes permanent. Start off right. As the scrum team plans its first sprint, it should not bite off too many requirements. Keep in mind that you’re just starting to learn about a new process and a new product. New scrum teams often take on a smaller amount of work than they think they can complete in their first sprints. A typical progression follows. After you establish overall goals through the product’s vision statement, product roadmap, and initial release goal, your product backlog needs only enough user-story level requirements for one sprint for the scrum team to start development. In sprint 1, scrum teams take on 25 percent of the work they think they can complete during sprint planning. In sprint 2, assuming sprint 1 was a success, scrum teams take on 50 percent of the work they think they can complete during sprint planning. In sprint 3, scrum teams take on 75 percent of the work they think they can complete during sprint planning. In sprint 4 and beyond, scrum teams take on 100 percent of the work they think they can complete during sprint planning. By sprint 4, the scrum team will be more comfortable with new processes, will know more about the product, and will be able to estimate tasks with more accuracy. High-performance patterns—such as teams that finish early accelerate faster—can be learned earlier by using shorter sprints. You can't plan away uncertainty. Don't fall victim to analysis paralysis; set a direction and go! Throughout the first sprint, be sure to consciously stick with agile practices. Think about the following during your first sprint: Have your daily scrum meeting, even if you feel like you didn’t make any progress and especially if anyone is feeling stuck. Remember to state roadblocks, too! The development team may need to remember to manage itself and not look to the product owner, the scrum master, or anywhere besides the sprint backlog for task assignments. The scrum master may have to remember to protect the development team from outside work and distractions, especially while other members of the organization get used to having a dedicated scrum team around. The product owner may have to become accustomed to working directly with the development team, being available for questions, and reviewing and accepting completed requirements immediately. In the first sprint, expect the road to be a little bumpy. That’s okay; agile processes are about learning and adapting. Step 7: Execute the Roadmap to Value When you’ve chosen your pilot, don’t fall into the trap of using a plan from an old methodology or set of habits. Instead, use agile processes from the start. Step 8: Gather feedback and improve You’ll naturally make mistakes at first. No problem. At the end of your first sprint, you gather feedback and improve with two important events: the sprint review and the sprint retrospective. In your first sprint review, it will be important for the product owner to set expectations about the format of the meeting, along with the sprint goal and completed product functionality. The sprint review is about product demonstration — fancy presentations and handouts are unnecessary overhead. Stakeholders may initially be taken aback by a bare-bones approach. However, those stakeholders will soon be impressed as they find a working product increment replacing the fluff of slides and lists. Transparency and visibility — show, rather than tell. The first sprint retrospective may require setting some expectations as well. It will help to conduct the meeting with a preset format, both to spark conversation and avoid a free-for-all complaining session. In your first sprint retrospective, pay extra attention to the following: Keep in mind how well you met the sprint goal, not how many user stories you completed. (Focus on outcomes achieved over outputs produced.) Go over how well you completed requirements to meet the definition of done: designed, developed, tested, integrated, and documented. Discuss how you met your success metrics or desired outcomes. Talk about how well you stuck with agile principles. We start the journey with principles. Celebrate successes, even small gains, as well as examine problems and solutions. Remember that the scrum team should manage the meeting as a team, gain consensus on how to improve, and leave the meeting with a plan of action. Step 9: Mature and solidify improvements Inspecting and adapting enables scrum teams to grow as a team and to mature with each sprint. Agile practitioners sometimes compare the process of maturing with the martial arts learning technique of Shu Ha Ri, a Japanese term that can be translated to “maintain, detach, transcend.” The term describes three stages in which people learn new skills: In the Shu stage, new scrum teams may work closely with an agile coach or mentor to follow processes correctly. In the Ha stage, scrum teams will find that the sprint retrospective is a valuable tool for talking about how their improvisations worked or did not work. In this stage, scrum team members may still learn from an agile mentor, but they may also learn from one another, from other agile professionals, and from starting to teach agile skills to others. In the Ri stage, scrum teams can customize processes, knowing what works in the spirit of the agile values and principles. At first, maturing as a scrum team can take a concentrated effort and commitment to using agile processes and upholding agile values. Eventually, however, the scrum team will be humming along, improving from sprint to sprint, and inspiring others throughout the organization. With time, as scrum teams and stakeholders mature, entire companies can mature into successful agile organizations. Step 10: Progressively expand within the organization Completing a successful pilot is an important step in moving an organization to agile product development. With metrics that prove the success of your pilot and the value of agile methodologies, you can garner commitment from your company to support new opportunities for applying agile techniques. To progressively expand the agile footprint across an organization, start with the following: Support new teams. A scrum team that has reached maturity — the people who worked on the first agile pilot — should now have the expertise and enthusiasm to become agile ambassadors in the organization. These people can become part of a guild to help new teams to learn and grow. Redefine metrics. Identify measurements for success, across the organization, with each new scrum team and with each new product. Expand methodically. It can be exciting to produce great results, but companywide improvements require significant process changes. Don’t move faster than the organization can handle. Identify new challenges. Your first agile pilot may have uncovered roadblocks that you didn’t consider in your original implementation plan. Update your strategy and maturity roadmap as needed. Continue learning. As you roll out new processes, make sure that new team members have the proper training, mentorship, and resources to effectively use agile techniques. The preceding steps work for successful agile product development transitions. Use these steps and return to them as you expand, and you can enable agile principles to thrive in and drive your organization’s success.

Article / Updated 03-15-2021

"Who is my customer?" is a fundamental question everyone must ask as they begin product development. Product development teams explore this question frequently, using product and customer usage data to see trends and watch industries and markets closely. Not clearly understanding who your customer is makes product development difficult and rudderless. Customers range from external paying customers to internal users. Sometimes the customer is even several layers away, spanning wholesalers, distributors, and retailers. Product landscapes also change dramatically and are uncertain. Each new generation of users, from baby boomers to millennials, brings a new set of needs or considerations. Add to that cultures, races, and ethnicities; new or changing technologies or inventions; new laws or regulations; and even results from competitive benchmarking. Customers continually demand faster, better, and cheaper. From cars that receive operating system updates every week to wearables to home automation, customers expect more—and more often. Product providers who can meet these demands remain relevant. Knowing who your customer is will put your product development effort on the right path. But how can you know if you’re on the right path? This uncertainty can be unnerving. Getting comfortable with uncertainty Modern product development is fraught with uncertainty. In fact, it’s the one aspect of product development that’s certain. Rarely can we develop the same solution for our customer’s ever-changing problems. Product providers continually question, “Have we accurately identified our customer and are we addressing the right problem?” Product development teams need to be comfortable with uncertainty. The certainty end of the spectrum is predictable, safe, secure, and settled—aspects you would expect of a low-risk investment. The uncertainty end is fraught with anxiety, worry, doubt, and danger. Product development teams continually strive to address the highest risk and highest value for their customers. They learn and grow, and gain experience and opportunity throughout their product development journey. With iterative product development, the team can present at every sprint a fully-functioning, working product increment—not a half-baked increment—and get feedback. At each sprint, the team aligns the product closer and closer to what the customer needs through a tight, consistent feedback loop. The team becomes more and more certain that what they’re creating is what the customer wants. The team validates assumptions along the way, thus reducing uncertainty. Being comfortable with uncertainty is important because it changes the team’s perspective. It enhances the team’s curiosity rather than giving them a false sense of assurance. Innovation and better ideas result from a curious team, an attribute shared by all famous inventors. Uncertainty enables a team to channel its worry, doubt, and risk into a fruitful learning experience with growth and opportunity. Uncertainty motivates the team, which aligns with Agile principle number 5, “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.” Product development is risky business, in a good way. Common methods for identifying your customer Although you can identify customers and their needs in many ways, we discuss several popular methods used by product development teams. In the context of agile development we refer to customers as the end users and clients as the people paying for the product or service. Product owners and developers who are experts in techniques for better understanding their customer are valuable to their organizations and teams. Scrum masters who can facilitate using these techniques are likewise valuable. Each technique puts the team on the path towards certainty. Product canvas In Inspired: How to Create Tech Products Customers Love (Audible Studios), Marty Cagan wrote, “discover a product that is valuable, usable and feasible.” What he meant by this, as shown in the figure below, is that successful product development hits the sweet spot at the cross-section of: Valuable: Will customers buy it? Usable: Do customers need it? Feasible: Can we do it? Many teams use a visualization technique, such as a product canvas, to start to explore and understand the key factors, partners, unique value proposition, problems, and potential solutions that may contribute to finding the sweet spot, where value, usability, and feasibility meet. The product canvas is a collaborative tool that enables teams, in a brief amount of time, to accomplish two tasks: One, start identifying desired goals or product outcomes. Two, validate assumptions about the problem to solve for the customer and ready the team for development. Product canvas exercises can inspire a clear product vision. Teams use the product canvas as a visualization activity to create a shared understanding of the customer and his or her needs. The tool serves as a starting point for the team's assumptions and enables them to dive deep in gathering new product insights. Product development teams create a shared understanding through visualization. The most effective communication medium for them is face-to-face with a whiteboard, flipchart, or other holistic surface. Why? Whiteboards allow people to not only explain but also draw what they mean. Peter Lencioni, author of “The Five Dysfunctions of a Team” said, “If you could get all the people in an organization rowing in the same direction, you could dominate any industry, in any market, against any competition, at any time.” A shared understanding helps teams row in the same direction. Many variations of canvases are available, such as a lean canvas or a business opportunity canvas. They all serve a similar purpose of organizing ideas, challenging assumptions, and collaborating to find a strategic direction. The following figure demonstrates the product canvas we often use with agile product teams. The left half addresses market and customer issues, while the right half addresses product and business issues. The left half defines the customer segment, customer problems with alternatives, the value proposition, channels, and revenue projections. The right half defines the solution, key stakeholders, success factors, resources, partners, and costs. Both halves enable a team to do a more detailed evaluation of their product. Following, are some categories a team might use in building its product canvas: Customer segment: Describe the target customer segment that needs the problem solved. For whom is the value being created? Early adopter: Describe the initial target customer. Remember, your product can’t be everything to everybody—at least not at first. What market segments are opportunities for testing your product idea first? Problem: Describe the primary problem experienced by the target customer segment. Existing alternatives: Describe available alternatives to your product. Unique value proposition: Describe a single, clear, and compelling message that states why or how your product is different and worth buying. Channels: Describe the channels for acquiring, retaining, and increasing customers. List ideas for creating awareness, interest, activation, and usage. Describe what will entire customers to return and encourage referrals. List upselling opportunities. Solution: Describe the ways the target customer segment’s problems will be solved. Key stakeholders: List the people who are most important to your product. This list may include people whose buy-in and support you need, executives, and influencers. Who are the people you can trust to criticize your product and tell you the truth? Key success factors: Describe how success will be measured—measure outcomes not outputs. Are there key metrics you can use to test your hypotheses? Using metrics allows product development teams to evaluate the success or failure of each product release. Metrics help them see if they truly understand and are solving their customers' problems. Product development teams don’t consider their work completely done until those objectives are met. The product canvas can help identify these business metrics early. Agile product development techniques increase the likelihood that bad or wrong ideas are quickly discarded. Key resources and partners: Describe the critical internal and external people, equipment, or resources needed to deliver the solution to the customer. Revenue/business value: Describe the business value of delivering the product, service, or capability. Consider what will drive revenue, save money, increase customer satisfaction, differentiate you from your competition, improve market positioning, and more. Cost structure: Describe the important costs inherent in the product model. Identify what will be most expensive, for example, resources, activities, development, marketing, or support. Using the foundation of a product canvas not only helps the team to better understand the customer and desired outcomes but also enables the product owner to build a concise yet strategic product vision statement with a supporting product roadmap. Customer map Other customer-focused mapping tools can be powerful visualization activities for a team seeking to better understand its customers. We introduce two common customer mapping tools: a journey map and an empathy map. A journey map helps the team visualize the day-to-day experience a customer goes through when accomplishing a goal or addressing a specific problem. Goals are followed by actions in a timeline format, by calling out the user’s emotions or thoughts. The journey map creates a narrative. The insights gained inform product designs. This figure outlines the flow of a journey map and the relationships between the customer's goals and his or her steps, insights, and emotions. An empathy map helps the team think through the user’s emotions and senses. It explores what the customer sees, hears, thinks, feels, and does. It identifies pain the customer experiences and how the product can give the customer the gains he or she seeks. Teams build customer maps together, learning and digging deeper into their customer’s needs, motivations, and challenges. They openly discuss their perceptions, observations, and insights to validate their understanding along the way. Job-to-be-done lens Jobs theory, developed by Clayton Christensen and the Harvard Business School in response to his overwhelmingly popular theory on disruptive innovation, refers to an approach used to discover functionally, socially, and emotionally why customers make the choices they do. According to the theory, products and services are hired to help the customer make progress. They call the customer’s progress the job-to-be-done, which when understood enables significant innovation. Beware that if a product can be hired, it can also be fired. The jobs-to-be-done approach adheres to four principles: Job is shorthand for what an individual really seeks to accomplish in a given circumstance. Product development teams need to understand the experience the customer is trying to create, which is not a straightforward task. The circumstances are more important than customer characteristics, product attributes, new technologies, and trends. This principle speaks to seeing the innovation through the lens of the customer’s circumstances. Good innovations solve problems that formerly had only inadequate solutions—or no solution. If customers see only two options, a third option that addresses all the relevant criteria can help fickle observers become customers. Jobs are never simply about function—they have powerful social and emotional dimensions. Understanding the social and emotional dimensions of a customer’s choice makes all the difference in the customer's purchasing decisions. Christensen shares how viewing products through the jobs-to-be-done lens significantly increased sales of his sample populations. Specific examples he cites include milk shakes, condominiums, and even Reese’s Peanut Butter Cups. Product development teams use the job-to-be-done theory throughout their product development, particularly as they evaluate the timeline from when customers identify a need to their purchase. This figure shows an example job-to-be-done timeline. Close interactions with stakeholders and customers help validate their assumptions. Product development teams can benefit by considering the job their product or service must fulfill for the customers. Better understanding the job-to-be-done requires customer interviews so you can truly understand their needs. Customer interviews What better way to understand a customer's needs than to talk to the customer? Teams interview customers because they value “customer collaboration over contract negotiation” and “individuals and interactions over processes and tools.” Customer interviews are critical for enabling progressive elaboration techniques such as decomposition and story mapping. The key for performing a successful interview is to get customers to talk by allowing them to tell stories about their problems and imagine possible solutions. You escape from your perspective into the customer’s. Interviewees will discover things they didn’t know and interviewers will discover whether they're making wrong assumptions. Consider the interview as an opportunity to validate the team’s assumptions and to vet both good and bad ideas. This table outlines the types of questions interviewers should and shouldn’t ask. Customer Interview Do’s and Don’ts Do This Don’t Do This Use open-ended questions beginning with why, how and what. Follow up with more questions such as, “Tell me more.” Start with a pitch or description of your product idea. Use questions that invite story telling. Multiple choice or one word/one phrase responses. Tell me about… Do you like…? Do you want…? How do you know...? Would you use this? Can you give me an example of…? What do you think of our product? What do you wish you could do…? What requirement should we add? What do you know about…? How often do you…? How do you feel about…? Would you ever use…? How would life be different with…? Would you pay money for…? When was the last time you…? How often would you…if you could…? What happened when you…? Take vague terms like “difficult,” “expensive,” “complex” at face value Ask about past behavior, rather than hypothetical/ideal What do you mean by…? The types of question on the left invite storytelling. They encourage the customer to answer beyond any biases you may have. The examples on the right give significant constraints to customers on how they can answer the question, and don’t encourage much conversation or storytelling. Instead, get them talking. Product discovery workshop Product development teams use product discovery workshops to gather product ideas and insights from stakeholders and scrum team members. These workshops have many different formats and applications. Workshops, if done correctly, allow creative juices to flow. What is key is creating a safe environment where ideas can be shared openly. Timeboxes (setting a time limit on the discussion) for topics are helpful, as well as plenty of Post-it Notes and markers, and the freedom to diverge, converge, explore, and discover. Some people, especially introverts, find that receiving prepared agendas beforehand is helpful for getting their thoughts flowing. Agendas can also help everyone to arrive prepared and ensure that the workshop objectives are accomplished. Be careful to not use the agenda to provide excess structure, however. Lightweight structure, particularly with workshops, can help the discussion go where it needs to go. The frequency and participants of the workshops depend on the team, the product, and the problem to solve.

Article / Updated 03-15-2021

Scrum teams flourish when scrum team members work closely together in an environment that supports continuous and close collaboration. The agile development team members are central to success. Creating the right environment for them to operate in goes a long way toward supporting their success. Collocate the team If at all possible, the scrum team needs to be collocated — that is, physically located together. When a scrum team is collocated, the following practices are possible and significantly increase efficiency and effectiveness: Communicating face-to-face, taking advantage of the fullness of both verbal and nonverbal communication Standing up — rather than sitting — as a group for the daily scrum meeting (to keep meetings brief and on topic) Using simple, low-tech tools for communication Getting real-time clarifications from scrum team members Being aware of what others are working on Asking for help with a task Supporting others with their tasks One of the benefits of collocation you don’t recognize until it's gone is osmotic communication. When people work in the same physical environment, they hear what’s going on around them, even if they’re not paying close attention. They can join a conversation happening within earshot, contributing something that might have been missed. In addition, they can sense tension or relief as challenges are addressed by other members of the team. Absorbing information that’s happening around you contributes to better informed and empowered team members. All these practices uphold agile processes. When everyone resides in the same area, it’s much easier for one person to lean over, ask a question, and get an immediate answer. And when the question is complex, a face-to-face conversation, with all the synergy it creates, is much more effective and efficient than any form of electronic communication. This improved communication effectiveness is due to communication fidelity — the degree of accuracy between the meaning intended and the meaning interpreted. Albert Mehrabian, PhD, a professor at UCLA, has shown that for complex, incongruent communication, 55 percent of meaning is conveyed by physical body language, 38 percent is conveyed through cultural-specific voice tonality interpretation, and only 7 percent is conveyed by words. Keep this in mind during your next conference call to discuss the design nuances of a system that doesn’t yet exist. Alistair Cockburn, one of the Agile Manifesto signatories, created the following graph. This graph shows the effectiveness of different forms of communication. Notice the difference in effectiveness between paper communication and two people at a whiteboard — with collocation, you get the benefit of better communication. Face-to-face communication means we are physically face-to-face as we communicate. Although technology today supports bringing geographically dispersed people together more effectively than ever before, technology cannot replicate the social effects of people working in the same physical location on effective and real-time collaboration. Scrum teams are most effective when they are physically collocated. However, that doesn't mean agile frameworks such as scrum will not work for a dislocated team. In fact, for the success of a dislocated team, a framework such as scrum is even more important due to its clarity of roles, transparency, and tight empirical feedback loop. In the following discussion, we describe the ideal situation for enabling a scrum team communication, realizing that opportunities to achieve the desired benefits of collocation exist even when collocation isn’t possible. Set up a dedicated area If the scrum team members are in the same physical place, you want to create as ideal a working environment for them as you can. The first step is to create a dedicated area. Set up an environment where the scrum team can work in close physical proximity. If possible, the scrum team should have its own room, sometimes called a team room or a scrum room. The scrum team members create the setup they need in this room, putting whiteboards and bulletin boards on the walls and moving the furniture. By arranging the space for productivity, it becomes part of how they work. If a separate room isn’t possible, a pod — with workspaces around the edges and a table or collaboration center in the middle — works well. If you’re stuck in cube city and can’t tear down walls, be creative and ask for a group of empty cubes and configure them in a way that works for your team, even if that means removing panels. Create a space that you can treat as your team room. The right space allows the scrum team to be fully immersed in solving problems and crafting solutions. Visualizing ideas and work-in-progress brings about shared understanding among the entire team. Unfettered access to other team members is also key for effective and real-time collaboration. Create a space that enables these things. The situation you have may be far from perfect, but it’s worth the effort to see how close you can get to the ideal. Before you start an agile transition in your organization, ask management for the resources necessary to create optimal conditions. Resources will vary, but at a minimum, they should include whiteboards, bulletin boards, markers, pushpins, and sticky notes. You’ll be surprised at how quickly the efficiency gains more than pay for the investment. For example, when one client company allocated a dedicated team room and made a $6,000 investment in multiple monitors for developers, they increased productivity and saved almost two months and $60,000 over the life of development. That’s a pretty good return on a simple investment. Removing distractions The development team needs to focus, focus, focus. Agile methods are designed to create structure for highly productive work carried out in a specific way. The biggest threat to this productivity is distraction, such as . . . hold on, let me quickly respond to this text message. Okay, I’m back. The good news is that a scrum team has someone dedicated to deflecting or eliminating distractions: the scrum master. Whether you’re going to be taking on a scrum master role or some other role, you need to understand what sorts of distractions can throw the development team off course and how to handle them. This table is a list of common distractions and do’s and don’ts for dealing with distractions. Common Distractions Distraction Do Don’t Multiple objectives Make sure the development team is dedicated 100 percent to a single product objective at a time. Don’t fragment the development team between multiple objectives, operations support, and special duties. Multitasking Keep the development team focused on a single task, ideally developing one piece of functionality at a time. A task board can help keep track of the tasks in progress and quickly identify whether someone is working on multiple tasks at once. Don’t let the development team switch between requirements. Switching tasks creates a huge overhead (a minimum of 30 percent) in terms of lost productivity. Over-supervising Let development team members decide among themselves how to accomplish the work to be done after you collaborate on iteration goals; they can organize themselves. Watch their productivity skyrocket. Don’t interfere with the development team or allow others to do so. The sprint review meeting provides ample opportunity to assess progress. Outside influences Redirect any distracters. If a new idea outside the sprint goal surfaces, challenge the product owner to add the item to the product backlog rather than put the accomplishment of the sprint goal at risk. Don’t mess with the development team members and their work. They’re pursuing the sprint goal, which is the top priority during an active sprint. Assigning even a seemingly quick task can throw off work for the entire day. Management Shield the development team from direct requests from management (unless management wants to give team members a bonus for their excellent performance). Don’t allow management to negatively affect the productivity of the development team. Make interrupting the development team the path of greatest resistance. Distractions sap the development team’s focus, energy, and performance. The scrum master needs strength and courage to manage and deflect interruptions. Every distraction averted is a step toward success.

Cheat Sheet / Updated 03-11-2021

Agile project management is becoming agile product development. Products are considered long-term, value-creating assets requiring permanent teams who interactively elaborate, design, develop, test, integrate, document, and even support products until business outcomes are achieved. Agile product development focuses on continuous improvement, scope flexibility, team input, and delivering essential valuable outcomes. Agile development approaches include scrum as a framework for exposing progress, extreme programming (XP) for building in quality upfront, and lean thinking to eliminate waste. These and many other tools and techniques help organizations, teams, and individuals adhere to the Agile Manifesto and the 12 Agile Principles, which focus on small, long-lived, self-organizing teams, effective communications, continuously releasable product, and flexibility.

Article / Updated 07-20-2018

Your customers are the perfect addition to your scrum because they are great sources of product innovation ideas and improvements. Alienating them not only creates ill will, but also cuts off a crucial feedback loop that can lead to innovation. Internet service providers, phone companies, and local utilities consistently rank among the highest in customer service complaints. Where service providers are limited, customer service is commonly (although not always) weaker than in other industries. Customers frequently encounter long hold times, frustrating service, and labyrinthine automated service menus. Pressures on the bottom line have caused many companies to cut the budget for customer service, yet customers are the most crucial stakeholders in any business, and they need to be provided good service. Without the customers, there’s no business. Comcast is an example of a company that has experienced bad press regarding the quality of its customer service. Instances of customers unable to get refunds for bogus charges, wait times forced until closing, and an inability to cancel subscriptions are just a few of the claims that have been made over the years. Although the need for service is enormous, quality is often lacking, and millions of people are willing to spend the time to make others aware of their experience. Customer complaints about the handling of their service calls abound. The service conundrum Perhaps the number-one failure in service is that customers often report that their issues aren’t even solved by the agent. Customers need and expect service representatives to be able to answer questions and solve problems regarding their companies’ products. Unfortunately, all too often, training in companies fails to provide the customer service representatives with the knowledge they need to meet this need of the customers. The service representative may not understand the problem because the customer explains it poorly, or the representative simply doesn’t understand the situation the customer is describing. Seventy-eight percent of customers state that their good customer service experience was due to the knowledge the rep had, while only 38 percent said it was due to personalization. Knowledge matters. Training development for representatives is a high priority. Preplanned answers don’t carry the weight of true depth of knowledge. The cost of losing a customer is far more than the customer’s annual subscription rate. Customer service divisions are often thought of as being cost centers, but in fact they save and make their firms huge amounts of revenue. Following are some statistics that reflect how customer service can affect a business in ways that you may not have considered: It’s more than six times more expensive to gain a new client than to keep a current one. 78 percent of customers have forgone a purchase or transaction due to poor service. Loyal customers are worth up to ten times the amount of their initial purchases. Twelve positive experiences are needed to make up for one negative one. For every customer who takes the time to complain, 26 others tell their friends instead. Information overload In this day and age, too much data is quoted as a source of call center failures. Too much information can paralyze the effective functioning of a service representative. Service representatives can become overwhelmed with too much data that’s hard to use, and many centers haven’t managed this information so that it’s useful to representatives. Perhaps you’ve been on a call with one representative and been transferred to another, only to find that you had to explain the issue all over again. Often, a client’s historical data doesn’t get fed to the rep. It’s frustrating for the customer to rehash his situation or to hear the ominous words “I have no record of your claim here.” Getting the right information to the right people is part of the problem. Sixty percent of customer service centers say they aren’t even able to get certain pieces of customer information (for example, portions of customer history) to service representatives. On top of this, more than 30 percent of representatives don’t gather and record customer satisfaction data. Sometimes, data isn’t consolidated between organizational divisions, or the data is hard to find. Firms are experts at gathering information, but timely and effective distribution of that knowledge is a problem.