This guide and toolkit for accelerating large-scale agile adoption emerged from 5 agile transformations at 3 companies over 1 decade. It is based on hands-on experience from internally leading and supporting agile transformations of business units of 100-450 people across continents. No theory — just worn wrenches and bruised knuckles from a company-insider.
Aligning to the Agile Mindset, rallying Agile Leaders and Managers, creating a compelling Agile Journey Chart and Vision, planning and executing an Agile Transformation Roadmap, leveraging Change Management principles, and rolling out Agile Team Training and Coaching are a subset of my favorite tools and practices to help transform organizations.
1.0 INTRODUCTION
This paper is chronologically-organized in the order that sessions are typically conducted to launch a major agile transformation of 100-450 people. The broad categories are Align, Plan, and Rollout. A small set of my favorite tools and practices are then grouped inside those categories as described in the following paragraphs. Each section will include the practice or tool purpose and description as well as my experience using it.
In the Align phase (section 2), a shared understanding of the agile mindset is established. Sessions are held with senior leadership, management, and the organization-at-large. The single topic covered in this phase is:
- Agile Mindset Alignment so everyone shares a common understanding of what agile truly means.
An overview of some of the Agile Mindset session content with contests/games is covered.
In the Plan phase (sections 3-5), leaders and managers are prepped for the roadmap transformation planning session and execution to follow. The topics covered in this phase are:
- Agile Leader Training and Coaching so managers are supported and know their role.
Session format and some content of the internal Agile Leader Training contents with a manager “should/should not do” game is covered. - Agile Journey Chart and Vision so the past is managed and a desirable, better place imagined. The session format for creating a Journey Chart and Vision is covered.
- Agile Transformation Roadmap so the when, what, how, measures, and value are clear.
An in-depth description of the Agile Transformation Roadmap template is covered.
In the Rollout phase (sections 6-8), people, process, and technology/infrastructure transformation teams form and execute on roadmap topics such as: Roles and Responsibilities definition, Scrum Team, Product Owner, and Stakeholder Training, Definition of Done, Change Management, internal Agile Coaching Program, Continuous Integration, Automated Test, Program and Portfolio Management, and so on. The topics covered in the Rollout phase are:
- Agile Transformation Teams (People, Process, Technology/Infrastructure) so nothing is missed and clear ownership established. The teams’ structure and operating model are covered.
- Change Management Plan so the burden of being and doing things differently is eased.
The change management model used and a useful stakeholder-change matrix tool are covered. - Agile Team Training and Coaching so teams are jump-started and quick wins achieved.
Just-in-time training, a wave adoption model, and internal agile coaches are covered.
2.0 AGILE MINDSET ALIGNMENT
The purpose of the Agile Mindset training and alignment is to put everyone on the same page of what agile is and is not. Surfacing and starting to alleviate people’s fears about agile and the effect that it will have on their job is another key goal of the session.
The 1½ hour training session is an entertaining and informative presentation with a brief game quiz and highly-interactive question and answer period. The slide portion covers the agile mindset based on the 4 values in the Agile Manifesto and the 12 principles. Each value is explained through real stories from my own experience. The importance of storytelling to bring these values to life cannot be overemphasized. The agile principle’s picture game reviews the 12 founding concepts followed by an interactive quiz. Pictures are flashed that the participants then shout back the corresponding principle. Small, spongy “green brain” stress toys imprinted with the 4 agile values are tossed out as prizes that add to the fun and learning.
Agile planning and delivery is described as well as a brief overview of Scrum and Kanban to address some of the mechanics of how agile might work in their environment.
2.1 Experience
I was at a non-agile conference and asked 28 Product Development leaders if they thought they knew what agile was. All of them raised their hands. I then asked how many of them thought their definition of agile was the same as their neighbors. None of them raised their hands. For me, this experience just reinforced the importance of this upfront training to get everyone aligned on what agile is.
Those who come to the session often believe they know what agile is and in truth, many do. A typical session’s agile knowledge-level demographic fits a bell curve. People at the front of the curve admittedly have little agile knowledge and are anxious to learn. People at the back really are agile experts and often help others during the session. The majority in the middle are the toughest. They “kind of” know what agile is which sometimes interferes with new learning. Often ceremonies, tools, iterations, or process used in “doing” agile are confused with “being” agile.
The agile principle’s picture game is a winner every time! The value is high-energy during the session and high-retention afterwards. At session close, the participants are asked to name the values and principles sans pictures. They do astonishingly well due to the principle-picture memory association effect.
“We tried agile before and it didn’t work” consistently comes up. Asking a few questions in a respectful manner about what it is they actually did almost always reveals that they were not truly agile. Declaring so is unnecessary as it becomes obvious. Frequent objections heard include: big upfront design thinking, command and control culture, nothing useful can be built in 2 weeks, not applicable for large and/or distributed projects, too much time in meetings, specialized roles, huge legacy backlog with little automated testing, and no product owner or customers available.
3.0 AGILE LEADERSHIP AND MANAGER TRAINING
Following Agile Mindset Alignment for everyone is Agile Leader and Manager Training. Its purpose is to help leaders and managers understand their role and responsibilities in an agile environment. They can raise and discuss concerns with their peers in a safe environment and discover how they can actively engage in their organization’s agile transformation. They learn how to provide value as managers in an organization with self-managed teams.
Day 1 – All Leaders and Managers
Participants start off with an agile “love it/hate it” exercise. They place dots on a continuum indicating how they feel about agile and how they think their team/organization might feel. The ensuing, non-instructor led discussion allows people to immediately become engaged in the learning and more readily benefit from the viewpoints of their peers.
The agile values and principles are explicitly mapped onto the company’s employee values and leadership success profile. The participants more easily relate to agile when they tie it to something they are already familiar with. The various Scrum ceremonies are explained and managers learn the frequency and kind of interaction they should have with their teams and stakeholders. The leaders form teams and discuss their responsibilities and what behaviors as managers they should and should not do. Managers practice interpreting various agile charts so they know how their teams are doing and how they might help. For organizations that are just beginning their move to agile, leaders are taught how agile transformation roadmaps are created and how they can be strong, active sponsors. Short, instructive but entertaining videos are sprinkled throughout the day.
Day 2 – Frontline Manager-Focused
Managers who have positional authority responsible for members on scrum teams are the primary audience for this session; however, VPs and executives commonly attend too. Elements of running a scrum are incorporated into the session. The participants prioritize the class backlog of topics that are of the most importance to them and we correspondingly organize our day to work our way down that backlog. Suggested topics include User Stories, User Story Splitting, Scrum Ceremonies, Distributed Agile, Release Planning, et cetera. We facilitate time-boxed working sessions for topics that come up that are specific to the participant’s particular environment with no instructor-prepared materials.
3.1 Experience
Before accepting an agile leader job, I asked the hiring VP if they had any agile leader and manager training; the answer was no. We both agreed how critical it was and had it rolled out within a few weeks of hiring on. I believe it is that important! Gaining access to leaders in the company who might not have been as willing to have an initial one-on-one to talk about transforming their business unit to agile has been especially valuable. Intact management teams at the sessions are highly-preferable for gaining alignment and solving common problems.
The discussion of what managers should and should not do is the most exciting and engaging activity in the training. It is loud, raucous, and intense with debate. The shared journey for the managers and eventual alignment of what it means to be a manager in their own organization is by far the greatest value of the exercise; not the instructor-provided agile “right answer.” Frontline managers are polled to see if they feel they currently spend enough time on strategic work. Most say not as much as they should and concur that turning over more of the day-to-day tactical work would afford them that opportunity. However, some remain skeptical as to how feasible that would be which is to be expected at this very early stage of their agile journey.
Although it is always a challenge to get managers to commit to the 1 or 2-day training, the average net promoter scores have always been very high. After a half-decade of delivery, I have only had one executive, an IT leader tell me that they thought agile and hence the training was not applicable for them in their organization.
4.0 AGILE JOURNEY CHART AND VISION
Preferably, the Agile Journey Chart and Vision session comes after agile leaders and managers have been trained (previous section) but not always; sometimes scheduling challenges get in the way. The purpose is to acknowledge where an organization has been, to align where they want to go over the coming year(s), and at a high-level identify what needs to be done to make that happen.
Typically, a single, combined 2-day session is conducted to create both the Agile Journey Chart and Vision plus the Agile Transformation Roadmap (next section.) It is conducted with a T-shaped representation of the organization; that is, representatives from the top (VPs, Senior Directors), the foundation (individual contributors), and cross-functions (QA, PM, Support, et cetera.) For an organization of 150-450 people, this is between 20-30 employees.
Current State
Teams of roughly 6-8 people write on sticky notes what is currently working well and what is not. They consider three tracks: People, Process, and Technology/Infrastructure. After working at their tables for about 30 minutes, they present and post their work on the wall. Discussions for deeper understanding occur. A quick affinity grouping exercise is done by everyone in the room.
Future State
The future state is similarly done. Discussions about what is truly desirable and achievable make this exercise take significantly longer than the Current State.
Transformation Activities
The teams briefly outline on sticky notes the training, coaching, tooling, definitions, et cetera needed to achieve the future state. The activities are generally at a very high-level; for example, “training and coaching is needed for all scrum teams.” The Agile Transformation Roadmap (next section) is where high-level activities are broken down into more specific, actionable items. On the Roadmap, training would then be expanded into Scrum Team Training, Scrum Master Training, Product Owner Training, and so on.
4.1 Experience
The current state exercise goes pretty quickly. People want to get to the future state definition and are even more anxious to identify the steps necessary to get there. However, spending some time on the current state and how they got there is wise. Recognizing what has been tried before – successes and failures – is important for people to be able to “move on.”
Often leaders resist allocating 2 days of time and resource. After all, it is a big time investment in planning, acknowledging the value of change management, and recognizing that customizing agile for the organization is more important than expediency realized by a one-size-fits-all approach. Launching “inevitable” activities such as training and coaching for teams in parallel or even before the event starts often lessens the angst of planning versus executing. Timing the event in conjunction with another already planned one is a best practice that allows people from remote sites to attend and participate too.
“Things are working just fine the way they are” is often heard from some at the start of the Current State definition. At this point, leaders must step up to explain why they are not just fine. Often the explanation is they may be okay now but they will not be if something does not change. Juxtaposed to that are people who easily get into a state of “nothing works right.” Reminding them of their business success and reassuring them that they are “not broken” is important to keeping the group positive and moving forward.
5.0 AGILE TRANSFORMATION ROADMAP
Again, this session is usually conducted as a 2-day event that includes the Agile Journey Chart and Vision (previous section) creation at the start. The purpose of the Roadmap is to provide a quarterly, measurable plan of improvement activities to rollout agile to the customized level of maturity that explicitly meet the outcomes of the specific business and organization. Because every organization is different, every roadmap is too.
The roadmap can be thought of as a matrix with several timeline columns (Current State, 1st quarter, 2nd quarter, …, Future State) and four rows (What, How, Measures, and Value) as follows:
What
The teams plan the goals to be achieved in the next quarter. For example, half of the scrum teams trained, coached, and stood up with 3 successful sprints under their belt, the definition of done at the release level specified, weekly integration of software, and so on.
How
The teams identify the training, activities, and tools needed to reach the goals for the next quarter. Teams and roles identified, 2-day scrum team training, 1-day product owner training, and coaching for 3 sprints all from the same vendor who is to be identified are training examples. Program manager, quality, and development team created to specify release level definition of done is an activity example. Integration “tiger” team formed to develop weekly, daily, and finally continuous integration strategy over the coming months is a tools-related example.
The What and How rows are each further subdivided into threads of:
People team topics including Training, Coaching, Change Management, Transformation Program Communications, Performance Management, Organizational Structure, and so on.
Process team topics including program priorities and approvals, standards, guardrails, release planning and tracking, audit compliance, metrics (business, program, team, and adoption), development lifecycle, decision making, schedule, continuous process improvement, program and portfolio management, and so on.
Technology/Infrastructure team topics including environments (development, QA, production, et cetera), SCM branching strategy, continuous integration, continuous deployment, automated testing, defect tracking, agile program management tool, and so on.
Measures
The teams specify the measures to verify the goals have been met for each quarter. Thirty-five team members trained, 5 CSM Scrum Masters and 2 CSPO Product Owners in place, 3 formal Sprint Reviews conducted for each of the 5 teams are examples of transformation roadmap measures.
Value
The teams elaborate both the business and personal value gained in reaching the goals for the next quarter. For example, business value might be risk-reduction as the teams are demonstrably working on and delivering the highest value items for the business. Business value is critical or there is no reason to do the improvements to start with. The personal value to the team members may be a better work-life balance and a feeling of camaraderie and accomplishment as the team delivers and demonstrates their software to stakeholders on a regular cadence. Personal value is an important change management acceleration factor in large scale agile transformations.
5.1 Experience
Before the event, I have heard some people object to it as they feel they already know what they will have to do such as some particular training, or an organization-wide definition of done for release, or many other obvious activities. This is absolutely true. So why spend the time to do this roadmap creation activity as a group? There are many reasons but the primary ones are to ensure alignment across the organization of what being agile means to them, to create deep buy-in and desire to move to agile, to encompass critical aspects of the transformation often ignored besides just training and coaching, and to setup the tactical implementation for a successful agile transformation. In large transformations without this event, I have witnessed significant, recurring problems where the organization has a wide disparity in thinking of what agile truly means to them and/or seems to be waiting for someone else to make them agile.
The intent is to get as much of the roadmap filled out as possible during the event. In practice, there is usually only enough time to do a good job of the what and the how for the first quarter and a preliminary plan for the second quarter. This is fine though and consistent with agile planning principles. There is always a backlog of improvement items to be refined and planned for later by the transformation teams (next section.) Sometimes those teams are left to defining the measures and value too. This is due to the sense of urgency in the session to define quality what and how next steps over anything else. It is not at all surprising in our action-oriented organizations to see the measures and value definition be somewhat deferred.
The very first time conducting an agile roadmap transformation session, threads of enabling, execution, assessment, and governance emerged and worked very well. Since that initial effort, using the 3 threads of people, process, and technology/infrastructure pre-populated with potential topics has made the roadmap planning process more efficient. It helps people think about areas they might have otherwise missed without being prescriptive and limiting. It is not at all unusual for topics to overlap between teams; for example, the guidelines for checking code is often shared between the process team and the technology/infrastructure team managing SCM. The transformation teams manage the overlap themselves via simple communication.
6.0 AGILE TRANSFORMATION TEAMS
Typically, within a week of the Agile Roadmap event (previous section), the agile transformation teams are reformed to carry the work forward that was planned in that event. The purpose of the people, process, and technology/infrastructure teams is to drive the rollout of agile across the organization.
Team membership significantly changes from the people who did the planning at the Roadmap event. The leader of each team in the event stays on to maintain continuity. New people self-select into the teams of their interest on a part-time basis. While the initial plan for the first two quarters is created in the Roadmap event; the ownership of that plan and the backlog is assumed by the new teams. Team members, a product owner, and a scrum master for each team operate in a Scrumban fashion on a cadence defined by the team. The overall agile transformation program leader conducts a weekly scrum of scrums-like event to check progress, remove barriers, share learnings, and make adjustments.
6.1 Experience
The improvement agile transformation teams are always very excited to operate their teams in an agile manner using a prioritized backlog. Most team members have never actually been on an agile team before especially those who were not developers. For the most part, the teams really want to be Scrum teams but given the nature of the team membership being part-time and the improvement backlog inevitably being lower-priority than their “day job”, it really is not practical. An informal Scrumban-like process works best. In the best transformations, executive agile sponsors step up and give visible rewards to high-performing improvement teams which boosts morale, improves productivity, and raises agile adoption program awareness. This is especially important in the early-going.
The input to the improvement teams after the session is in a format that is part roadmap and part backlog. Some teams continue to maintain the roadmap format on wiki sites while others abandon it in favor of just a prioritized backlog. It works well in both cases. This does not diminish the importance of a roadmap. The initial value it provides for alignment, consideration of all aspects of a transformation (not just training and coaching), ownership of the change, and getting the effort kicked off is enormous.
7.0 CHANGE MANAGEMENT
This area is addressed by the “People” Agile Transformation team (previous section) that was formed after the roadmap session (section 5.) The purpose of change management in large scale agile transformations is to accelerate the cultural shifts from traditional engineering and management mindsets to ones that are more agile.
The change management part of the program generally follows the 8-step John Kotter model as first described in his book Leading Change (Kotter, 1994). Those steps are: establishing a sense of urgency, creating the guiding coalition, developing a vision and strategy, communicating the change vision, empowering employees for broad-based action, generating short term wins, consolidating gains and producing more change, and anchoring new approaches in the culture.
Creating a stakeholder-change matrix with one axis to identify the major sets of people in the transformation and the other axis to map applicable change management issues has been a useful tool in getting my hands around the cultural shift challenge. The stakeholder sets include people such as developers, QA engineers, program managers, front-line managers, et cetera. The kind of change management issues for each stakeholder include: the type of resistance you might expect, a planned response to help manage it, the benefit they will gain in moving to agile, training they might need, additional resources they might need, a rewards and recognition plan, and a communication plan.
The communication plan is particularly important in large scale transformations. When rolling out agile coaching and training across many teams in waves over a two- to three-month period, those teams in the latter waves might think that they have been forgotten or the program has lost steam. By constantly showing the progress and the rollout plan, teams are reassured that the program is going strong, on track, and their turn will soon be up!
Some of the change management tools and techniques in the trenches used were simple but quite effective. For example, creating colorful and interesting advertisement-like posters, hosting pizza learning lunches, conducting “grill-the-agile-expert” forums for people to express their concerns, establishing a small bookshelf with agile materials in the hallway, creating agile quizzes and awarding agile-related prizes, and so on were all used to raise awareness and increase knowledge of agile.
7.1 Experience
A small number of leaders have told me that change management was not needed for their organization; that they would just tell their people how things were going to change and they would just start doing it. In some pockets of the organization, that was true but generally not for everyone in the organization. This is due to the way large scale agile affects how people work up and down the management chain, cross-functionally, and cross-teams. We are not just talking about a few, disparate teams running Scrum in isolation. Additionally, being agile in the way you think and operate is different from just doing some agile practices. Again, the cultural shift to “being” agile is very difficult.
Most people in engineering organizations have heard of change management but are not aware of what it truly entails and how to make it actionable. Regrettably, a few think of it as “just so much fluff” but by far most managers exhibit a great interest in it. I believe this is due to their desire to learn something new as well as use it for their own current job function apart from the immediate purpose in driving the agile transformation.
Helping to make the organization “ready and willing” is a reasonable sound bite for what we are trying to do with the stakeholder-change matrix; ready in terms of capabilities and skills, willing in terms of motivation. In practice, this matrix is rarely completely filled out; rather high-likelihood and high-impact issues are identified and addressed.
In my experience, the result of most change readiness assessments conducted with different organizations over many years has been that they were not ready for any more change at this time. That in itself is not very useful if the change has already been mandated regardless. However, I believe they are still worth doing if for no other reason than the huge benefit of awareness, education, and enablement of primarily managers to better deal with the transformation change.
People who were very outgoing and had exceptional people skills made the best leaders as change agents in the most successful transformation efforts.
8.0 AGILE TEAM TRAINING AND COACHING
This area is undoubtedly the first one tackled by the “People” Agile Transformation team (section 6) that was formed after the Roadmap event (section 5.) The main purpose is to help teams efficiently move to operating and delivering as a self-managed, agile team. Scrum team training and agile coaching are the primary delivery methods.
The Scrum team training is delivered “just-in-time” the week of or before the first sprint. In most cases, delivery is done by a Scrum team trainer who becomes the agile team coach. External vendor coaches train from their own materials. Internal agile coaches and trainers use in-house developed materials that cover the standard Scrum topics like ceremonies, roles, process, and so on. The team’s own requirements are used in exercises for user stories and backlog refinement. The training is conducted with a backlog that comes from both the instructors and attendees. The instructors prescribe topics like roles and ceremonies as well as recommend others to the attendees. However, the attendees ultimately prioritize their class backlog essentially setting their own agenda thereby increasing their sense of ownership for their own learning.
Rather than flipping a switch and having all teams trained and coached at the same time, they are typically staggered in waves of roughly 7-10 teams at a time over a period of a quarter or so. This enables “what works and what doesn’t” learnings from the earlier teams to be incorporated into succeeding teams being stood up. It also makes the pace of change to agile more palatable to those in the organization who are more risk-averse which is common in large corporations.
Obviously there is much more training necessary than just for the team such as Product Owner, ScrumMaster, User Story/Story Splitting, Kanban, Scrumban, and so on that is needed but not covered in this paper.
8.1 Experience
Teams retain much more when the timing of the training is very close to when they actually have to start using it for their first sprint often within just a day or two. They are much more engaged and feel the training is practical as the exercises incorporate their own work product; not just theory or some fictitious project that has nothing to do with the team’s domain. No one questions that the 2-days of training time is well-spent when it is moving the team closer to their deliverables.
I have yet to have a training that the attendees did not love having direct input into the agenda by setting and prioritizing the class backlog. The only disappointment is when there is not enough time to cover everything on their big backlog. Often, those missed items are covered afterwards by the trainer turned coach.
Teams that have already established a relationship with their trainer absorb and act on coaching advice from that same person faster than someone new. On top of that, utilizing internal agile coaches when possible is an added bonus. The team already trusts them and knows they are familiar with their domain and culture. I am a strong proponent of developing internal agile coaches as it integrates agile champions into the corporation for long-term sustainability of agile. For more on this topic, see “Organically Growing Internal Agile Coaches” (Padula, 2009) in the bibliography. Internal agile coaches directly address the last step of “anchoring new approaches in the culture” in John Kotter’s Leading Change model. The downsides to internal agile coaches are their views are not always as quickly accepted as an external expert opinion and they often have “day jobs” too which prevent them from devoting as much time to coaching.
9.0 WHAT WE LEARNED
Key success factors for me in leading large scale agile transformations over the past decade include:
- starting with the importance of the agile mindset and not just “doing” agile practices,
- creating a compelling vision that people are aligned with and highly desire,
- designing a customized agile transformation roadmap that takes into account people, process, and technology/infrastructure — not just team training and coaching,
- ensuring ownership of the transformation by putting most of it in the hands of the organization that is making the change,
- integrating change management practices into the transformation and not just expecting people to do it because leadership says so,
- providing direct training and coaching to the leaders and managers so they know what their new role is and how to behave with self-managed teams,
- delivering agile team training “just-in-time” before the first sprint.
Finally, this has been my experience and only covers a small subset of my favorite tools and techniques that could fit into the limited space of this paper. Additionally, there are many others I have not had the opportunity to try that work well too. Each situation and organization is different. That is why for large-scale transformations I strongly advocate the customized transformation roadmap approach; it accommodates almost any situation and any agile model as well as new approaches and tools for a successful agile rollout!
10.0 ACKNOWLEDGEMENTS
I cannot begin to name all the people who have contributed and been critical in these transformations over the years. However, I would like to give special thanks to Jim Sartain, Paul Stephens, Connie Fang, Anu Saripalli, Joumana Youssef, and Michael Leftwich who have all been major champions and leaders alongside me on varying agile journeys. I also want to thank Joseph Yoder from the Agile Alliance for providing me his insightful feedback on this paper.
