Large-Scale Agile Transformation Approach - Phased and Big Bang implementations – Tricky scintillating Artifact

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, culture, time zones, and technologies being used. Most of the time, more than one team shares the same backlog with the same sprint schedule, if those teams are working on the same product.

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 considerable amount of rework on the delivered products?
• Is the current feedback loop not working to catch up with market fluctuations?

If the majority of the points above prove to be negative, then it is time to move to Agile transformation. Agile can help solve most of these issues in a positive way due to its simplified frameworks, engineering practices, collaborative way of working among product teams and development teams, small and colocated teams, 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, DSDM, FDD, etc.) will be suitable for the organization. If there is maintenance work, then Lean and Kanban also can be considered.

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

Important: There should be training planned and conducted for the product teams, and this is critical. In Agile, the product owner is the person who is responsible for the product vision, ROI, and success. So if that person doesn't have a proper understanding of Agile values and principles -- concepts such as value-based prioritization, product backlog management, working with delivery teams with a sense of collaboration, release planning -- that will impact the entire transformation.

The executive management team also has to undergo some coaching and briefing to set the right expectations about the transformation. This will further help seed the mind-set change within the management team.

Decide on 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. Budget also plays a key role in planning the road map. If you can afford it and the time line is your key constraint, then you can bring experienced external Agile coaches in to complete the transformation within a shorter time frame. Otherwise, you can develop a few internal Agile coaches and create the road map accordingly.

My recommendation is to have at least a few external coaches because they come with previous experience of other organizations' transformations, challenges, and best practices.

Decide on structural changes and plan for them carefully

Structure plays a critical role in changing the culture. Agile is all about mind-set (culture), 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 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 affected. I recommend having a core team within the transformation team (maybe a lead coach and a couple of other coaches) 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 Score Card 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.
• Velocity can be measured.
• Basic engineering practices are introduced and practiced (pair programming, TDD).

Level 3 Maturity (RI)

• Velocity is consistent and the team tries to improve its velocity.
• Feature teams are formed.
• Advanced engineering practices are implemented.
• Continuous integration is in place.
• Teams come up with innovative ideas to improve the delivery.

Please note, it naturally takes some time to move from one level to another. It depends on several factors. Moreover, the time needed to move from one level to another may not be same for all teams. The transformation team has to keep this point in mind and plan the necessary arrangements.

Check the impact at the organizational level for various policies

There will be definitely some changes required in terms of some organization-level policies -- for example, the performance appraisal process. Based on the duration of the transformation, the transformation and senior management teams have to work with the HR team to come up with a suitable process for performance appraisals.

My recommendation is to create an appraisal process whereby there will be more importance given to team-based appraisals rather than to individual-based appraisals. However, it could be a combination of the two.

Decide on 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.

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 understanding 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.

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 progress based on the progress plan

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.

There may be few challenges you observe during the transformation, and they are discussed in a separate section below.

Make changes as and when required

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 on scaled Agile implementation

Once you complete the transformation at one location, you need to look at choosing a scaling model. There are several scaling approaches already available, but as far as I know, SAFe and LeSS are the two approaches most often chosen by organizations for scaling. Both approaches have pros and cons, so you need to review them thoroughly and decide which approach will work best for your organization.

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, involving normalized story points, joint Scrum ceremonies, etc., based on the approach that you go with. Hence the teams have to have a good understanding of these topics first.

Also, when you go for a scaled approach, it's good to have common release schedules so it will be easy to manage the ceremonies and have a better forecast. If for any reason one team falls back, then they can have either a shorter sprint or an extended one in order to catch up with the common release schedule with the other teams.

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
• Expectancy 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.

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.

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 tester and vice versa. The coach can help them understand the importance 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. Documentation may go for a toss with wrong understanding of Agile values and principles.

Solution: One thing that has to be emphasized during the trainings and coaching is that "Agile does not say documentation is waste." However, it is fine not to follow any template or format to document. So encourage the teams to take pictures from whiteboard discussions and record the important meeting sessions for reference, and use some kind of shared information space such as MOSS, confluence, etc.

7. 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, Definition of Done, acceptance criteria, informal reviews based on need, etc. These will help achieve the expected quality.

8. 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.

9. Teams get into a compressed Waterfall way of working.

Solution: Some people say that within a sprint we should work in Waterfall. But this is not really true; the coach has to change this thinking and make the teams work inan 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.

10. Attrition

Solution: When you make changes to the structure to get a change in culture, it might create some disappointment among employees. Especially for people who worked with an authority earlier, working in a servant-leader role is not now appealing. So it is sometimes not avoidable, but along with management impact analysis, it needs to be done and proper knowledge transfer has to be done by the people who want to move away.

Some best practices

• Initiate a "community of practices" to share knowledge and best practices.
• While creating the teams, try to have a team self-forming activity
• 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.
• 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.
• Velocity: To see the rate at which teams are delivering stories (business value).
• Sprint burn-down: To show what is remaining in the sprint, it can be effort hours, number of stories, story points, etc.
• Release burn-up: Helps the product owner come up with a forecast for the remaining product backlog items.
• 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.

Reference(s) -

-         Icagile, SCRUMINC, Atlassian, AgileAtlas.org, PMI, APM, Agileprocess, barryovereem & Agilefaqs blogs

-         www.scrum.org

-         www.scaledagileframework.com

-          www.agilekrc.com

-         www.agiletestingframework.com

-         www.scrumalliance.org

 

 

"Be the change YOU want to see...

Roll up your sleeves and show them how its done"

 

- Mahatma Gandhi