Steps to Successfully Become an Agile Organization

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.