Agile Adoption Roadmap

• there is definitely broad awareness of Agile
• there are many companies who are on the Agile bandwagon because it is seems like the right thing to do
• there are many Agile “book-read” folks who have not really experienced an Agile implementation
• there are some teams who are “cherry-picking” parts of Agile process for their own Agile implementation
• there are fewer teams who are applying end-to-end Agile methods and practices across their lifecycle
• the companies that have made the cultural shift to the Agile mindset are still a minority

The question becomes, does this really represent a pervasive enough understanding of Agile and a thorough enough adoption of Agile across the industry for it to be mainstream?

IMHO, there are two indicators of what is meant by mainstream. The first indicator is whether enough people or teams who have implemented Agile can recognize common steps to a successful Agile implementation. The second indicator is whether those that have implemented Agile have actually made the cultural shift (aka, Agile mindset or self-empowered teams, servant-leader mentaility, etc. ) in order to gain the benefits of Agile and to make it mainstream? The focus of this article will tackle the first indicator.

Approaching an Agile Adoption

The focus of this article is to help the reader understand some practical steps in getting Agile up and running successfully by a product team. The goal is not to say that this is the definitive list, but to give those that are planning to adopt Agile some key areas to focus on in their Agile adoption journey.

It is important to think of an Agile adoption effort as a project. I emphasize this because adopting Agile is not not like turning the ignition key to start an engine. Instead it is a cultural change journey with numerous stops along the way. With this in mind, an Agile adoption effort may be divided into three phases: Readiness, Deployment, and Support.

Agile Adoption Roadmap

Throughout each phase, it is very beneficial to on-board an Agile Coach to improve your chances of success. The Agile Coach helps a team adopt and improve Agile methods and practice. They should have years of Agile experience having implemented Agile on several product teams and have participated as a ScrumMaster, Product Owner, or Agile team member on an Agile project. Their hands-on and consulting experience helps the team stay focused on the tasks in the journey to Agile. Let’s examine the tasks within each phase more thoroughly.

Agile Readiness

The goal of the readiness phase of Agile adoption is to understand the current state of the product team, setting the expectation for change, and to establish an overall strategy and plan for the engagement. This phase typically lasts about one to three months. Tasks to consider getting the product team ready include:

• Determine suitability of product
  • While some may state that Agile methods can be applied to all product development, some products have more uncertainty than others and are more likely to benefit more from applying Agile methods and practices. This analysis can help you target the product teams that can benefit most from Agile, so that you get the biggest benefit for the effort (aka, bang for the buck).
• Determine willingness of team
  • This involves evaluating the team for their willingness to move to Agile. It is important to understand those teams and team members that are Agile friendly, those that are unfriendly to Agile, and those that are uncertain about the changes it will bring. This analysis allows you to respond accordingly by either improving team member willingness or adjusting the team composition (e.g., more Agile friendly types).
• Determine capability of team
  • This involves evaluating the team’s capability in applying Agile. It is important to determine what skill sets you have on the team and the team understanding of implementing Agile. This allows you to determine the type and level of Agile and engineering training that is needed by team members
• Assess engineering practices and Agile mindset of the team
  • This is to determine what engineering practices are being applied and how effective they are. This also assesses how Agile the team may already be in the approach they use to software development. This is applicable to existing product teams who have a release already under their belt. This allows you know which engineering practices are team strengths and which need improvement.
• Identify an Agile Coach
  • Your coach should be an Agile professional experienced in applying and executing Agile methods and practices on product teams, with the capability of completing the tasks included in the readiness phase. An experienced Agile Coach will increase the chances of a successful Agile adoption.
• Establish a strategy and plan for implementing Agile
  • Much like a backlog and Sprint Planning, this is where you establish a prioritized list of tasks and implement them within a sprint context (e.g., Scrum) or continuous flow context (e.g., Kanban). Consider using the tasks in this article as a starting point. This should be initiated by discussing the goals of the Agile adoption effort with the team to ensure their understanding. This will help make certain that the work is planned and prioritized effectively.
• Establish periodic progress meetings
  • Much like like the Daily Stand-up, this is where the team or at least a core group meet regularly to assess the progress of the prioritized tasks. This ensures that there is a focus on an effective adoption of Agile
• Establish Agile Roles amp; Organization
  • This is where we structure the team into appropriate Agile roles (e.g., Agile team member, ScrumMaster, and Product Owner) and determine if more than one Scrum team is needed (e.g., multiple Scrum teams that make up a large project team). This may require some restructuring to reduce functional relationships to improve team empowerment. The purpose is to ensure that we have a organizational structure that is most suited to Agile.
• Determine Stakeholder support
  • This involves identifying which stakeholders (e.g., Senior Management) are the Agile sponsors, then determining how supportive and Agile friendly they are. Identifying their level of support allows you to be aware of friend or foe, potentially increase the level of Agile knowledge and support of the stakeholder, and be aware of any risks to Agile support.
• Establish the Agile methodology and practices framework
  • This involves building a set of Agile practices (e.g., Sprint Planning, Story Writing, Daily Stand-up, End of Sprint Review, Retrospective, Scrum of Scrums, Continuous Integration and Build, etc.), techniques (e.g., sizing, etc.), and criteria (e.g., “done”, acceptance, etc.) for the product team. This also includes establishing an Agile framework that works within the governance context of the organization. The result is that the team will have an Agile structure to begin with and can hone practices and process over time. This can also be used as the basis of Agile team training.
• Consider Agile tool needs
  • This involves determining if Agile tools will be part of the initial Agile deployment, and what tools may be used to help you get started. An Agile tool evaluation is typically in order unless there are already defined Agile tool standards within your company. Agile tools are commonly thought of as Agile planning tools , but may also include test tools, continuous integration tools, and collaboration tools (amongst others). The benefit with tooling is that it may help support the Agile process, improve interaction with distributed teams, and enable automation. If the team is fortunate enough to be colocated, then a physical team wall is a suitable replacement for an Agile planning tool.
• Focus on Agile mindset and cultural shift
  • While it is important to provide a focus on Agile practices and tools, a specific focus on establishing an Agile mindset is important. This involves a focus on self empowerment, servant-leader, assertiveness, volunteering, etc. The benefit is that this ensures there is a focus on the Agile mindset.

Agile Deployment

The goal of the deployment phase is to execute the Agile approach and practices and help the team apply them to the project. This phase typically lasts about one to three months. Tasks to consider getting Agile deployed within product teams include:

• Set up the Agile Planning tool
  • During the readiness phase, there should have been a focus on Agile tool needs, and if so, a selection of a tool or tools. Once the tool has been selected, approved, ordered, and received, it is time to install and deploy the tool for team use. This ensures that the team has a common interface, and access to the user stories and work ahead.
• Provide Agile Training
  • This involves providing role-specific training to those that will be applying Agile. While off-the-shelf Agile training is fine, it is beneficial to incorporate context-specific details into the training, or provide a one-off training that walks the team through the Agile methodology and practices framework that was established during the readiness phase. Types of training to consider are:
    • Agile for the Team – Agile training with a view from the team’s perspective. This should include the Agile methodology and practices with a specific focus on Agile engineering practices
    • Product Owner training – Agile training with a view from the Product Owner’s perspective. Specific focus should be given to writing user stories.
    • ScrumMaster training - Typically Certified ScrumMaster (CSM) training. Given the abundance of CSM training held throughout the world, it may be best to approach this using an external vendor.
    • Agile Tool training - If there is an Agile planning tool, it is beneficial to train the Product Owner (to establish and manage their backlog), the Agile team (to refine stories and use their wall), and the ScrumMaster (to manage burndowns and other reporting).
  • While there is an obvious benefit to Agile training, it is important to ensure there is an emphasis on adapting to the Agile mindset.
  • In addition, consider providing periodic Agile Qamp;A sessions. These sessions provide the opportunity for team members to ask questions that come up after they have had formal training.
• Deploy the Agile methodology and Agile practices
  • As the project gets kicked off, and Agile methods and practices start getting used, this where the Agile Coach (or someone experienced in Agile) helps deploys the Agile practices to aid in improving the execution. This may involve helping apply the practices for the first three sprints and providing coaching and mentoring to the team to correctly apply the practices. This ensures that the Agile practices are being understood, deployed as defined, and applied with an Agile mindset.
• Periodic Meetings to ensure deployment is on track and directionally correct
  • As the deployment phase is underway, it is important to have brief periodic meetings to ensure there is a focus on the deployment activities. The benefit of doing this is to ensure the team sees that Agile adoption is not seen as a trivial effort, but does have the focus on the leaders on the team.

Agile Support

The goal of this phase is to provide the necessary support (e.g., coaching and mentoring) to the team deploying Agile, and the validation to ensure that practices have actually been implemented and improved as appropriate. This phase typically lasts about six to nine months. By the end of the Agile Support phase, internal Agile Champions should emerge and the team should be able to operate effectively without the Agile Coach. Tasks to consider during the Agile support phase include:

• Provide continued Coaching and Mentoring
  • This involves continued interaction with the team to resolve issues and challenges seen within the project context. This ensures the team knows that you are available to answer questions and assist as needed. It is not uncommon for some folks to want to regress back to a more waterfall or hierarchical approach, so it is particularly valuable to have the Agile Coach remain available to redirect the approach back to Agile.
• Provide In-session Validation of Practices
  • This involves occasionally attending Agile related sessions (e.g., Sprint Planning, Daily Stand-ups, End of Sprint Reviews, etc.) to validate the application of the Agile practices within the team. This helps the team understand if they are applying Agile appropriately and can help them hone (e.g., inspect and adapt) as appropriate.
• Provide periodic check-in meetings to monitor direction.
  • These are short periodic sessions where the progress of the Agile adoption is discussed. This gets less frequent over time. Agile adoption is a cultural shift which takes time, so these sessions ensure there is still focus on the implementation, and risks and issues continue to be discussed and resolved.
• Provide periodic Agile assessments to gauge adoption level.
  • This is where you assess the current state of the software engineering practices being applied as well as the Agile mindset of the team. This provides the team with a new baseline of adoption which can be compared to previous Agile adoption assessments. This allows you to gauge the level of adoption that has occurred and to determine where to target improvements.
• Provide additional focus on tools and automation
  • This is where you ascertain if additional tools or automation could help the team. Sometimes when velocity plateaus, this can be the result of a lack of automation. While tools should not be the primary focus of an Agile implementation, tooling and automation can help the team incorporate effective QA and Configuration Management (CM) practices (amongst others) and improve team velocity.
• Groom local Agile Champions
  • This is where you continue to work with the Agile ScrumMaster(s), Agile Team, Product Owner(s) to ensure they have the true Agile mindset and are applying Agile effectively. This is where you would identify a person or two who is passionate about Agile and has the experience to help others apply it effectively. The benefit is that once the Agile Coach departs, there is a local Agile Champion that has been groomed to take over and keep the team focused on the Agile approach.

Summary

As you embark on adopting Agile, understand that it is really a journey. Because of this, an Agile adoption effort should be thought of as a project so that you can remain on course. Hopefully this article can help the reader with some practical steps in getting Agile up and running successfully. Understanding that it is important to consider the readiness phase prior to deployment will lead to a more robust and less problematic Agile adoption. The journey to Agile is a cultural change with numerous stops along the way. Consider starting off on the right road.

References

Agile Coaching for Your Agile Company, by Alan Atlas, CST, CSC, Agile Coach, Rally Software and Mark Kilby, CSM, Agile Coach, Rally Software, Agile Journal, August 2010.

Agile Development: Mainstream Adoption Has Changed Agility, by Dave West, Tom Grant, with Mary Gerush, David D’Silvia, Forrester, January 20, 2010.

Chapter 9: Evaluating Tools Suited for Agile, part of Adapting Configuration Management for Agile Teams,by Mario E. Moreira, Wiley Publishing, 2010

A special Thank You to Deborah Smead for reviewing this article.