I was part of a large-scale Agile transformation as a lead coach. It was a great learning experience, and I want to share my experience of the transformation in this article.

Definition of a large-scale Agile transformation

Where there are multiple teams working on multiple services/products/projects from various different locations having different policies, practices, time zones, and technologies being used. Most of the time, more than one team shares the same backlog with the same sprint schedule.

Groundwork for the transformation

Any organization that would like to shift to Agile has to assess the need of the transformation. The assessment should include the following points:

• Are there any issues with the current software development approach?
• Is the current time to market helping the organization achieve the revenue targets?
• Are the customers of the organization happy with the products?
• Are the products that are being delivered having expected quality?
• Are there any gaps between the product management and software development teams?
• Is there productivity loss due to a considerable amount of rework on the delivered products?
• Is the current feedback approach not working to catch up with market fluctuations and/or stakeholder expectations?

If the majority of the points above prove to be negative, then it is time to try for Agile transformation. Agile can help solve most of these issues in a positive way due to its simplified frameworks, engineering practices, iterative and incremental way of delivery, collaborative way of working among product teams and development teams, effective feedback loops, etc.

Decide on the transformation approach

There are two ways to transform the organization into Agile. They are: Phased and Big Bang implementations. Based on my experience, it will be effective to go with a Phased approach in which we identify the teams that have less pressure on delivery and introduce them to Agile by providing a dedicated two to three days of training. Then we would provide coaching to those teams for a few sprints and get them to a stable level. This process will have to continue till all the teams of the division/organization are transformed. This is an iterative and incremental approach.

Also, you must decide which Agile frameworks (Scrum, XP, Kanban etc.) will be suitable for the organization based on the type of work the teams perform.

The training program will have to include the contents below as well as some class activities/games to explain the concepts in an easy and straightforward way to the participants:

• Why Agile
• Agile introduction and fundamentals
• Agile values and principles
• Lean and Kanban introduction
• Respective framework explanation in depth (e.g., Scrum/XP/DSDM, etc.)
• Agile estimation
• Agile communications
• Engineering practices
• Other related topics

It will be better to plan a separate training for Product Management teams that cover Vision creation, Roadmap, user stories, release planning, how to track the progress, value based metrics etc.

The executive management team also has to undergo training and coaching, briefing to set the right expectations about the transformation. This will further help seed the mind-set change within the management team. There should be a sponsor from the management team who is empowered and accountable for the transformation.

Create the transformation road map

This can be done based on the number of teams to be transformed, their locations, how much coaching they need (how many sprints), etc. It will be better to have some experienced external coaches help in the transformation as they are not influenced by your organizational culture and also can give you correct guidance based on their experience..

Make the roadmap visible to all the people in the organization.

Decide structural changes and plan for them carefully

Structure plays a critical role in getting culture aligned to be agile. Agile is all about mind-set, so the transformation team has to consider whether there are any structural changes that need to be done as part of the transformation. They need to be in sync with the senior management team in order to manage management expectations, company reputation, employee expectations, etc.

Do not just try to force-fit the organization’s existing roles into Agile roles. That might not work, and mismatches could impact the entire transformation process.

Decide how to measure transformation progress

This means inspecting and adapting for the transformation process and making necessary changes based on needs. This is also a critical step because if the progress is not as per expectation, organizational strategic objectives could be adversely affected. I recommend having a core transformation team that works together closely to make sure everything is going as per plan, and to respond to changes effectively. This monitoring has to happen periodically after the transformation starts and continue until it is complete.

It is good to have a maturity model in place, against which to measure progress. You could create an Agile Maturity Scorecard with a list of areas and corresponding weight for each area, or create different maturity levels and assess the teams against those levels. For example, below is one way to assess the maturity of Agile teams using a maturity level-based assessment.

Level 1 Maturity (SHU)

• Understand the Agile values and principles from the point of view of value.
• Conduct all Scrum ceremonies as per the guidelines.
• Collaborate visibly within the team.
• Have the product team and development team work toward a common goal (vision).

Level 2 Maturity (HA)

• The team delivers working software at the end of the sprint.
• The team follows proper estimation methods and is consistent in terms of understanding.
• Team’s pace is sustainable and it can be measured.
• Basic engineering practices are introduced and practiced (pair programming, TDD).

Level 3 Maturity (RI)

• Teams are able to improve their productivity.
• Feature teams are formed.
• Advanced engineering practices are implemented.
• Continuous integration is in place.
• Teams come up with innovative ideas to improve the delivery.
• Quality measures are in place.

Based on the need, introduce interim short training programs to the teams during the maturity journey.

Decide the required changes to tools

Your organization may be using some tools already as per the existing software development method. Those tools may not be suitable for Agile-based methods, however. So in this case the transformation core team has to identify the suitable tools and plan to present them to the teams. The selection of tools will be dependent on the organization’s size, the number of locations from which the organization operates, etc. If your organization is small, then a simple Excel workbook will be sufficient to manage an Agile project. If your organization is large and has multiple delivery locations, then you might want to try tools such as VersionOne, HP Agile Manager, JIRA Agile, etc.

You may need to plan on a separate training session just for these tools. This training can be provided once teams complete their basic Agile training and complete a few sprints.

But never deviate from the fundamental value “Individuals and interactions over processes and tools”.

Start the transformation

This is the step where the actual transformation gets kicked off. In this phase, the teams that are identified for the transformation will first undergo the two to three days of classroom training, in which coaches will cover the key topics using a slide deck, some classroom activities, and games.

After the training, these teams will be assisted by the coaches for at least four to five sprints. At this point, the teams will start implementing the Agile frameworks for their projects. The coach will closely work with the teams on all the Scrum ceremonies and help them understand the framework from a value perspective rather than a practice perspective.

During the initial few sprints, I strongly recommend that the teams use a physical task board so that they will see how the stories and tasks are moving and how the team needs to collaborate. Once they are familiar with the framework, they can move to any tool, such as VersionOne/JIRA. The physical boards will improve the interactions and collaboration.

Keeping visible information radiators is important for the Agile teams during transformation. One idea that can get high transparency of transformation activity is to have a “coaching Kanban board” at a central location in the organization. On this you can display the teams that are pending for training/coaching, teams that are in progress for coaching, teams that have completed coaching and started sprinting on their own. This board has to be managed by the coaching team and must be kept up to date. You can also try the WIP (Work in Process) limits, based on the coaches’ bandwidth available for the in-progress column.

Also, the coaches should practice a daily stand-up at their level in front of the coaching Kanban board, so that they practice what they preach. This will influence the teams in a positive direction to practice the Scrum ceremonies effectively.

Track the transformation progress (inspect and adapt)

This should be a continuous activity that happens at periodic intervals. The transformation team has to gather required data from the teams and check against the maturity levels or the score card described above. Based on the result, required amendments have to be planned in order to achieve the expected goals for all the teams in the process of transformation.

As part of the tracking of the transformation, you may find some gaps or identify some improvements. Those have to be plugged into their respective areas and you can see how it impacts the ongoing process. Based on this, you might need to extend the transformation time for some teams, or you might need to continue the dedicated coaching for a few more sprints to cover maturity gaps.

Expand the transformation

Once the first set of teams is done with the transformation and achieves the maturity level you expect, you will be able to get a grip on the time needed. This you can consider “transformation velocity.” This will help you come up with required adjustments to your transformation road map and proceed further.

Decide suitable scaling method 

Inorder to have a release cadences, manage inter team dependencies effectively, increase transparency across all locations, you may need to go for scaling model. The additional practices that are available in different scaling methods may help your organization in managing the complexity effectively and improve collaboration and communication. There are many scaling approaches available including: SAEe, LeSS, Scrum@Scale, Nexus etc.

It’s important to remember that you may have to give a short training to your teams on the scaling model that you have chosen. Hence the teams have to have a good understanding of the additional practices of the scaling method well.

Possible challenges and corresponding solutions

1. Management buy-in and patience

• Budget and time required for transformation
• Fear of loss of productivity during the transformation
• Possible push for a big-bang approach
• Expectation of quick maturity, so an expectation of improved delivery from the first sprint
• Forcing a return to old ways when it takes longer than expected to see results

Solution: Management buy-in is key for any transformation, so setting realistic expectations up front is critical. The transformation core team has to provide coaching and briefing to the management team so that they will have an idea of the expected outcomes and plan accordingly to choose teams for the transformation.

2. Teams might feel the new approach is more pressure-filled (resistance).

Solution: Change takes time to become visible. Set expectations for the team early, and make them start with baby steps so that they can see results quickly. Also, initially teams are not cross-functional and they will be in forming and storming stages, so it is good to take a small amount of work so that pressure will be under control. Introduce them with quick wins.

3. Scrum ceremonies turn into any other general meetings.

Solution: If the ceremonies are not strictly timeboxed, they will become normal meetings. Also, the specific agenda to be circulated for each ceremony, and ensure that people come on time for meetings. Coaches should play an important role initially so that teams understand the value of the meetings and follow the guidelines.

4. Initial sprints may not deliver any working software.

Solution: It is natural that the teams cannot have a proper rhythm initially. So let them choose small and easy stories first that deliver at least some business value, and let them try to deliver those stories. Slowly they can expand the delivery volume while they become cross-functional. The coach must encourage the team to become cross-functional and support them in achieving that.

5. Teams may not want to become cross-functional, as they may feel their primary skill will be impacted negatively.

Solution: This is related to mind-set. A developer does not want to become a tester and vice versa. The coach can help them understand the importance and purpose of developing secondary skills based on their interests and capabilities, and slowly try to get them there. Let the team try to do pairing up so that slowly it will create interest in developing secondary skills.

6. Quality may be impacted in the hurry of delivering stories.

Solution: Quality and speed do not go hand in hand unless there is good practice and close collaboration. So the product owner, ScrumMaster, and the teams have to work very closely to define the Definition of Ready (not part of core Scrum), Definition of Done, clear acceptance criteria, informal reviews based on need, etc. These will help achieve the expected quality. From the beginning itself introduce the engineering practices.

7. Product owners misuse the flexibility of “responding to change.”

Solution: First of all, every change has some cost involved, and some value too. The product owner and team should discuss and then act on changes. Sometimes changes that do not have any value may be requested by the product team, and the teams have a right to ask why that change is required. So product owners have to know the value-based prioritization. Also proper interactions with stakeholders and conducting effective Product backlog refinement will help address this challenge.

8. Teams get into a compressed Waterfall way of working (intra sprint waterfall).

Solution: It is very natural to fall in this trap during the initial times of transformation; the coach has to change this thinking and make the teams work in an iterative and incremental model. They need to take the top one or two stories from the sprint backlog and complete them end to end, then move on with the rest of the stories. This will ensure that the team will be able to deliver business value at the end of the sprint. Coach should be able to explain how this way increases the probability of meeting the sprint goal and how transparency gets improved and how risk can be minimised.

Some useful tips

• Initiate a “community of practices” to share knowledge and learnings.
• While creating the teams, try to go for self-formed teams.
• Try a pod structure to change the organizational structure.
• Keep big, visible information radiators and keep them up to date.
• Expose impediments through a visible board and try to close them before they impact the sprint goal. Encourage that teams resolve the impediments at the team level, and coach the ScrumMaster to solve the beyond team-level impediments (Global/Systemic).
• Define a small set of metrics and take the teams’ buy-in for those metrics. Below are some metrics you can try:
  • Sprint goal success rate: This metric helps Scrum teams realize how continuously they are delivering value to the customer. If this is low, that indicates there is some issue within the process that has to be fixed. Reasons could be taking too much into the sprint, requirements changing during sprints, team skill-set issues, collaboration problems, or other reasons.
  • Say-do Ratio: To see the rate at which teams are delivering stories (business value).
  • Cycle time (if you are using Kanban): Helps you assess the cycle time and, by using continuous improvement tools, you can come up with a plan to improve that cycle time.
  • Escaped defects: This helps the teams see how quality is managed in their delivery. If it is increasing sprint by sprint, that means quality is getting decreased, so you need to plan to improve it.
  • Team happiness index: This is another powerful metric to see how well the teams are motivated. The team’s feelings will have a direct impact on their productivity. Measure this at the end of every sprint.
  • Customer satisfaction: This metric will help you see how happy your customers are with your delivery pace and process. You can measure it through a questionnaire run on a periodic basis.
• Do not use metrics to compare teams. Also, don’t select metrics that are easy to capture but not useful.
• A monthly newsletter will help communicate the progress of the transformation.
• Periodic executive management updates to all employees will also boost the transformation.
• Try to automate build, deployment, and testing as much as possible, with alerts enabled. This will eliminate a lot of waste and you can achieve mistake-proofing.