Agile Adoption – Then and Now
Believe it or not, there was a time when Agile was unheard of in the mainstream. It was a fringe concept thought only applicable to hippie programmers and tiny startups. In those days, Agile was a virus that infected the organization via idealists and frustrated developers; but instead of weakening its host, Agile strengthened it.
These days, nearly every organization that develops software has a strategic initiative to adopt Agile. As someone who’s been passionate about Agile since the first time I used it in 2006, I’ve been part of many conversations where an executive utters the words “we need Agile”. Typically, those executives imagine a monolithic black box that intakes requirements, massages it with process, then spits out perfect code…but in iterations!
Imagine their dismay when they are months – and dollars – into an Agile adoption initiative, and they are facing down resistant employees, thrashing teams, minimal progress and whispers of “can’t we just go back to the old way?”. How does this happen? Why are we seeing more and more adoption failures? Is it simply a result of a larger sample size? Maybe; but that’s not the whole story.
I’ll share with you two stories of Agile adoption based on real life experience. At the end of each, I’d like for you to guess which organization will cross the chasm to truly embody the values and principles set forth by the Agile Manifesto.
Company A
Company A is a large organization with thousands of employees. They produce widgets but use software to build, market, and sell their widgets. After attending a technology conference, their CIO, Terry, returns to champion the adoption of Agile.
After obtaining the appropriate budget approvals (~3 months later), Terry forms an Agile Adoption committee with representatives from each line of business. The committee spends 3 months developing process and training materials.
Terry also hires a top project manager to scope, plan and execute the initiative. Everyone kneels in awe of the glorious “Master Project Plan to Implement Agile”. Expectations are communicated to all involved; timelines are drawn; roles are assigned; training courses are provided; and the initiative begins in earnest 6 months after Terry attended the conference.
Company B
Company B is also a large organization with thousands of employees. The also produce widgets and use software to build, market, and sell their wares. Incidentally, their CIO, Alex, attended the same conference.
Upon returning to work, Alex reached out to her product management teams and inquired about their customer satisfaction levels. Over the next week, Alex talks to employees from various levels of the organization to map out their software development lifecycle and its bottlenecks.
The following week, Alex and team select areas where the cycle time (i.e. the time to deliver working software to a customer) is high as candidates for experimentation. The teams time-box the experiments and make small, incremental improvements.
After a couple months, they scale up the efforts and use the early participants as change agents to replicate success elsewhere. Alex ensures participants are provided appropriate training. However, they’re allowed sufficient latitude to experiment. Lastly, Alex provides forums to share those wins and setbacks as quickly and organically as possible.
Which Company Will Succeed?
Without knowing the conclusion to the stories, which will likely succeed? Why?
Agile adoption is actually a decision to change your organization’s culture. No edict can truly force that type of transformation. As a change agent, you must know why you are asking the organization to change – what gaps are you filling, or what pitfalls are you attempting to avoid?
Plans are great, but they are just that. Passion, experiments, successes and failures are what will motivate others that this new path leads to a better outcome. Training is vital, but only in the context of forming a common language, not prescribing a rigid framework.
Improving Your Chances of Success
If you are reading this with plans to usher in an Agile adoption at your organization, the following are a few insights:
- Dig for the problem: You must first diagnose the disease before applying the remedy. Adoption for its own sake is wasteful. Luckily, the problems Agile helps address are universal- but you must still know the why.
- Articulate the situation: Spell out why the problem(s) will lead to imminent doom (or at least a reduction in profits next year); let that be your lighthouse when things turn south.
- Ask for help: The biggest mistake in transforming a culture is doing so in isolation. Find those who understand the problem and situation – as well as the mild skeptics – and ask them to participate.
- Big bang vs. rolling wave: The rollout method used is dependent on your organization. The key is checking your assumptions before selecting one; and inspect and adapt along the way.
- Support but don’t disempower: In other words, ensure that there is support readily available to teams as they experiment and fail. But don’t jump in to prescribe or tinker at the first sign of trouble. This is where a good coach can help the team power through their obstacles.
- Radiate everything: Make progress visible and encourage collaboration. Tools are great, but walls and whiteboards are even better. Let transparency be the driver of self-reflection and improvement. Don’t punish smart failures, use them as teachable opportunities for the future.
I can probably list 20 more tips; but in truth, the biggest advice I can offer is to remain open to the possibility of a better outcome and take incremental steps towards it. Good luck!
