Agile Adoption Patterns
Adopting “agile” in large organisations is notoriously difficult. I’ve seen (and sometimes worked for) plenty of large companies that fail to reap the reward of business agility which should result from adopting agile engineering practices.
A few years back, a lot of companies adopted “agile” in the following manner: they brought a consultancy firm in to work out a strategy, they hired some scrummasters, they delivered a few days training to their project managers and developers.
Hopefully we’ve all realised that this doesn’t work. Agile adoption is not just learning and applying scrum. It’s much, much more.
Firms like Leading Agile and Thoughtworks specialise in helping large organisations handle the process of transforming an organisation from one shape into another.
Richard Durnall wrote about a pattern of adoption he’d observed when working through agile transformations, and Dan North expanded on it in his 2014 talk on the subject. They both suggest that the process of agile transformation often seems to have six stages: the first two being people and tools. It’s these that the Agile Manifesto set out to deal with, and consequently, it’s these two that modern Scrum handles best. At it’s core, Scrum is a set of tools that help people to apply the agile values and principles.
In organisations that don’t have the benefit of a senior agile thinker (I can’t think of a better term), this is pretty much where agile adoption stops.
That’s partly because we’re still unsure how to traverse the last four levels. There is no best practice, and instead we’re faced with a bewildering array of complex frameworks (LeSS and SAFe being two) which promise to solve our problems.
Just like by-the-book scrum is rarely the best solution for a mature team who truly understand the philosophy of agile, these frameworks are rarely the best solution for large-scale agile transformation.
Here are the six stages of agile adoption, as imagined by Dan North, plotted against the resistance he’s experienced in getting through each one…
Stage 1: The People Break
We change their working environment, typically to open-plan offices. We change the structure of their teams, from division of labour-oriented to cross-functional. We change their working practices by introducing User Stories, pair programming, TDD and the like. We change what good looks like, and how they are measured.
As a consequence of all this, people break. They become confused and angry. They often feel uncomfortable or inadequate — particularly if they didn’t voluntarily sign up for agile adoption.
We can fix the people by employing experienced scrummasters, delivering good training and coaching, and by having expert agile coaches on hand to ease the myriad growing pains associated with agile adoption at team level. Because agile is generally a more interesting way of working (and often more fun), most people jump on the bandwagon pretty quickly.
Stage 2: The Tools Break
As people start to get on board, we find that our tools start to break. The metrics by which we measure productivity and success are no longer adequate: KPIs need reimagining. Terms of Reference need redefining or binning. Traditional project management methodologies and the tools that support them need replacing. Even the tools we use to communicate and report change. Email is replaced by face-to-face conversation and IM. Project plans are replaced by whiteboards and stacks of index cards.
This is usually easy to fix after a bit of thinking and trial-and-error. Teams will naturally adopt better tools and processes as they begin to adopt a more agile mindset. Retrospectives offer a fantastic opportunity to refine teams’ tools and processes.
Stage 3: The Governance Breaks
Once individual teams have embraced agile practices and adopted new management and tech tools, we begin to run into the problems associated with Agile at Scale.
We have issues associated with cross-team dependancies, delivery assurance and alignment of work at programme and portfolio levels. We realise that we need a way to make product and technical trade-offs at a programme level. We find it hard to coordinate teams. We’ve no idea when our teams will deliver market-ready product.
This is the bit that’s hard to solve, and inevitably takes an awful lot of considered thought and experimentation. We need to establish a clear vision for our culture and product. We need to establish principles and guidelines for our teams to work within. We need to build a transparent culture where everyone in the company is accountable to everyone else. We also need to develop tools to support all this.
Portfolio- and programme-level Kanban boards are a good tools to start with, and Spotify’s model should provide some inspiration too.
Stage 4: The Customer Breaks
We’ve now solved our governance problems and reached a point where we have a bunch of small agile teams working synergistically to deliver business value. Or at least we think they’re delivering business value.
We now have a broken customer model. Most agile methodologies insist that a Product Owner or Customer is present on-site — embedded in each team. That works well if a team is delivering a product, but now we’ve got thirty teams working across three separate programmes, each with their own product owner. Our “customer” has become a placeholder for the product direction.
At scale, the customer is no longer the customer — it’s a nebulous concept. “The customer” is really a placeholder for the product direction, or understanding the market — Dan North
“Customer” encompasses everything from product strategy to market engineering.
How do we deal with this? That depends entirely on how we’re set up. We need to ensure there’s a process which allows speedy feedback from both the business and actual users. A clear product vision will help, as will many of the ideas from the Lean Startup. Clear, open communication between delivery teams, marketing teams and the like is also important.
Stage 5: The Money Breaks
“We’re used to being in top-down cost accounted organisations” — Dan North
How do we fund work which cuts across multiple teams and programmes? How do we estimate costs when there are no fixed project plans? The traditional method of divvying up pots of money between programmes and then between teams doesn’t work very well in this new way of working.
And so our internal financial model is broken. We can try to fix that by adopting new models of accounting: Throughput accounting and Beyond Budgeting are two ways we can help solve these issues.
‘Beyond Budgeting’ means beyond command-and-control toward a management model that is more empowered and adaptive. It’s about rethinking how we manage organizations in a post-industrial world where innovative management models represent the only sustainable competitive advantage. It is also about releasing people from the burdens of stifling bureaucracy and suffocating control systems, trusting them with information and giving them time to think, reflect, share, learn and improve. Above all it is about learning how to change from the many leaders who have built and managed ‘beyond budgeting’ organizations. — The Beyond Budgeting Institute
Stage 6: The Organisation Breaks
So far, we’ve changed a lot of stuff…
- We changed our team structure and environment.
- We changed or employees mindsets and working practices.
- We changed our technical and managerial tools.
- We changed our entire governance model (and probably our company structure as a result).
- We changed how we do market engineering and product strategy. This is where Agile™ starts to enable business agility.
- We changed our accounting methods and tools, along with our entire approach to financing projects.
In fact, we’ve probably changed so much our organisation’s old structure and culture is now at odds with the new way of doing things — it’s broken.
At this point, it probably makes sense to rebuild the organisation around value streams, flow and validated learning, and encourage a culture that promotes transparency, speed, innovation and agility (in the proper sense of the word).
Dan North gave an excellent talk in 2014 covering much of this stuff. You should watch it when you get a minute…
In Summary
Agile transformation is by no means easy, and in my view it’s the responsibility of everyone in an organisation to think about how it can best be achieved. In particular, it’s the job of senior executives to actually lead the change and to empower their managers to help them.
When we say that agile cannot survive without executive level sponsorship… we are not asking for permission and a pep rally, we are asking them to lead change — Mike Cottmeyer
If you got any value from this article, I’d appreciate it if you’d take a second and recommend it on Medium (by clicking the ❤ button), and let me know you liked it on twitter 👍.
