A common question I get during my Agile training courses is what is the difference between Agile Adoption and Agile Transformation. It's a great question. I see five key differences worth talking about.
But first let's agree on our terminology. These are my working definitions for these two terms though I realize that people don't use these two terms consistently.
Agile Adoption Defined
My definition and the generally accepted definition of Agile Adoption is "a change in process to one that is consistent with the Agile Values and Principles". This could be adopting the Scrum Framework, Kanban, Lean Software Development, eXtreme Programming (XP) or one of the other agile methods. The focus here is on a process change. Agile Adoption is viewed as moving from one process, such as waterfall or SDLC, to an Agile process or framework. This might also be called an Agile transition or a Scrum transition. Most organizations first experience Agile in this way. When an organization runs an "agile pilot" they are generally referring to Agile Adoption.
I've been through a lot of these Agile Adoptions. The most common is the transition from Waterfall to Scrum. A company with experience using a more traditional, plan driven approach wants to experiment with Agile. So they 'Adopt Agile' by transitioning to the Scrum Framework. That involves forming one or more dedicated and cross-functional teams. Hopefully the teams are supported by a process coach (i.e. the Scrum Master), they list all their work as a backlog of features, and then invite a business stakeholder (i.e. the Product Owner) to prioritize the work and make business decisions.
Rather than work in phases, the Scrum team works in timeboxed iterations called Sprints. Within each 1 to 4-week sprint, the team plans their work and delivers small chunks of fully developed solutions.
Most people are referring to agile adoption when they "go agile". A popular annual report on Agile from Version One cites "barriers to further adoption", "reasons for adopting agile" and "benefits of agile adoption". It doesn't use the term transformation anywhere.
Agile Transformation Defined
Agile Transformation may be defined as "the process of transforming an organization’s culture and nature to one of agility". Transformation is about a fundamental change in the way people think and feel. Some people distinguish this from adoption by calling adoption "doing agile" and transformation "being agile".
Agile methods and frameworks are tools or enablers in an Agile transformation. In other words, Agile is a vehicle, but not the destination. The destination will vary from one organization to another, but for most organizations it is about attaining true business agility - ability to be flexible, to be responsive to change. And to make those changes quickly and cost effectively. It also means a culture where people are empowered and enabled to do their best work.
Agile transformations are anything but easy. They are disruptive, disturbing and potentially very disappointing. The risks of failure are high. It will take a long-term investment to change ingrained ways of thinking and working, and the company culture. But the payoffs can be tremendous, as we can see below.
5 Key Differences Between Agile Adoption and Transformation
1. Speed of Change
Agile adoptions are pretty fast. You can adopt Scrum or Kanban in a day or less. Training on Agile can take from one to three days. I've also seen teams begin practicing Scrum immediately, without training, under the guidance when they had an experienced Scrum Master or Agile Coach.
In one of the first Agile Adoptions I was involved in 6 years ago, I turned up on the client site on a Monday and the team was using Scrum on Tuesday. We used a lightweight training approach where the team got just enough training to do their work. We worked on a just in time basis, starting with an overview of agile values and principles, then a quick review of the Scrum Roles, Artifacts and Meetings, and then Sprint Planning. They the team planned their first sprint and began work. It wasn't pretty, and as I recall the team failed to deliver completed work in their first 2-week sprint. But they had adopted Agile. (BTW I don't recommend this approach!)
On the other hand, an Agile Transformation can take a long time, measured in years. Some organizations begin an Agile journey with a goal of continuous improvement. In lean this is called the perfection challenge. Organizations will never arrive.
So whoa, I know what you are thinking, my leaders and stakeholders won't give me years to work on an Agile Transformation! So what can be done instead is to look at this longer program of change and break it up into reasonable milestones and smaller initiatives. That is where having an overall transformation roadmap spanning 12 to 24 months can be helpful.
Another key difference between Adoption and transformation is the reference timeframe. Most agile adoptions focus on a completing a project. Projects are temporary in nature and so adoption may be viewed as a short term, temporary way of working. People may see a choice between Agile and Waterfall being made on a project by project basis, and individuals may be on an agile project for a while and then back on a waterfall one later. It is easy to see how this could undermine buy in for Scrum or any kind of encouragement to live by the Agile Values and Principles.
In a transformation, organizations set up long standing teams that are aligned to customers, products or applications. People don't switch back and forth between Agile and Waterfall and they don't worry about getting assigned to a new project. They join a team and stick with them. Great leaders will actually let people choose what teams they want to work on. (See my Bank of America success story for more).
3. Productivity Gains
Teams can be very productive using Scrum. In fact, the simple steps of having one person set priorities, getting the team working together, bringing transparency and avoiding the waste of rework, work in progress, and detailed planning up front can often really boost productivity in those organizations. To the extent Teams Cross-train and build T-Shaped skills, they can reduce bottlenecks and increase flexibility. And teams that use retrospectives can learn to continually improve.
My colleague Michael Sahota estimates that introducing Scrum will boost a team's productivity by 20%. Perhaps the teams he was working with were already doing well. My experience with helping over a hundred teams adopt agile is more like a doubling, or 100% improvement in productivity. And it is even higher if you factor in reductions in building the wrong things- unnecessary features and functions.
While that is great, the benefits of an Agile Transformation on an organization are significantly higher. On this I tend to agree with Michael that the benefits are in the neighborhood of 300%. Some of the key benefits include:
- Reduction in managers
- Higher employee morale, job satisfaction, and employee engagement…joy even
- More creativity and innovation
4.Impact on the Organization Structure
Agile Adoption rarely has a significant impact on the organizational structure. We simply pull people from their various functional silos - front end developers, QA, backend developers, DBAs and we temporarily assign them to a cross functional development team. Team members still report to the same manager and that manager has HR responsibilities.
As a result, managers tend to favor hierarchies and strive to protect their turf, which contributes to silos, local optimizations, and significant inefficiencies. The functional silos that were designed for efficiency are now one of the main causes of lack of agility. They slow down decisions and create power struggles while the broader organization misses out on market opportunities and loses market share to more nimble competitors. It's easy to see the inefficiency but much harder to change. The answer is to move to long standing, cross functional teams. See this great online training workshop from Gary Hamel on how to do exactly that: Hacking the Bureaucracy.
In an Agile Transformation, the organization structure cannot be ignored. As Craig Larman states in his laws of organizational behavior, Culture follows structure. In a transformation, those functional organizations are replaced by groups of teams aligned to customers or internal products. The basic building block for this organization are those cross-functional and self-organizing teams.
Agile transformation is not trivial nor for the faint of heart. Transformation directly impacts power and control in an organization and that is enough to bring out people's defenses. No one wants to give up the hard-fought turf and spoils of war. No one wants to give up the powerful feeling of commanding a large group of people.
5. Change in Culture
In an agile adoption, the immediate team and stakeholders may feel like they've changed. They may feel more empowered and hopefully are being supported to self-organize. They may be striving to live to the agile Values and principles. With support from protective coaches and enlightened managers, they might be able to live in a culture bubble which is separate from the culture of the org and protected by an Ozone layer.
Unfortunately, I've also seen Scrum pilots where the culture is not any different from that of the broader organization. Scrum is used more like a weapon and the Agile Values and Principles are not valued or practiced. See this article on Dark Scrum by Ron Jeffries, one of the authors of the Agile Manifesto and a long time agile thought leader.
In an Agile transformation, it is actually the culture that is being transformed. Agile is not the goal. Agile is the vehicle to achieve the goal of cultural transformation. Key aspects of this culture change could include:
- Respect for people
- Investment in growing people's skills
- Continuous improvement mindset
- Empowerment and distributed decision-making
- Focus on customer satisfaction