Jan 25, 2018 - 5 Key Differences Between Agile Adoption and Agile Transformation
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 between Agile Adoption, and Agile Transformation. People don't use these terms consistently and I am not sure there is a standard. Below is my proposed definition for each these terms.
What is Agile Adoption
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 with the most common being the transition from Waterfall to Scrum. Frequently there is a company with a history of using a traditional, plan driven approach. They want to experiment with Agile to go faster, be more productive, or make it easier to respond to change. 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.
What is Agile Transformation?
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; the ability to be flexible and 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
So here is my take on the five key differences between 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.
2. Timeframe
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
- Empowerment
- 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 reinforce the hierarchy and 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. Or read this client success story on how Bank of America did it.
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, though rarely does the change extend beyond the team. The team 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 team 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. You can read this article on Dark Scrum by Ron Jeffries for examples, or read my related post, We Fix Bad Scrum.
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
- Flexibility
- Focus on customer satisfaction
Anthony
Anthony Mersino is the founder of Vitality Chicago, an Agile Training and Coaching firm devoted to helping Teams THRIVE and Organizations TRANSFORM. He is also the author of two books, Agile Project Management, and Emotional Intelligence for Project Managers. Learn more by visiting www.VitalityChicago.com.
If you enjoyed this post, you might be interested in the following blogs: