Scrum celebrated its 25 year anniversary last year with an update to the Scrum Guide and lots of socially distanced parties. Over that quarter of a century, Scrum has gone from a niche method used by software developers to mainstream adoption with many millions of people using Scrum or at least parts of Scrum every day. Now Scrum is not just a smart way of delivering software, it is a fundamental part of any enterprise agility transformation.
Over the last few months, I have been speaking to a few organizations that started these transformations years ago and I noticed a pattern. A pattern I would like to label ‘The Agile Hangover’.
First there comes the Agile party. Over the last 25 years, many software development departments have tried to adopt Scrum. Sometimes this has included some organizational change, sometimes it is focused on teams. Many organizations started with a team approach, added more teams to the same project using Nexus or other approaches. Then started looking at a broader use of Scrum with scaling methods such as LeSS and SAFe or developed their own. Those ‘transformations’ were IT-centric, focused on improving the IT, or the Product Development function. Other parts of the organization looked from afar and were only involved when their department interfaced with the technology part of the organization. Many of the people in those departments looked bemused when they were told to start using terms like Sprint, Product Owner, Sprint Review, and Retrospective. Lots of passion, energy, and money were spent on the desire to improve. This improvement basically was motivated by three things:
- More predictable - Increasing the predictability of projects helped them not to be late. For many organizations, the ability to estimate upfront and then deliver on that estimate was always a source of frustration for IT and the business they served. When a project was finally delivered there were always fingers pointing from both technology and the business.
- Faster Delivery - Faster or more stuff delivered. The holy grail of every change is that we will get more stuff done, more software delivered to customers at a faster rate.
- Improved Quality - Many organizations were looking for improved SLAs and fewer production-level bugs from the applications delivered. This was even more true when the products were being supported by outsourced vendors.
Rarely did these efforts focus on happy customers, innovation rate, worker attribution, or customer value. They also treated the problem and solution as a technology instead of a holistic business problem.
And many organizations saw better outcomes. Teams delivered more stuff or at least the customer understood all the stuff that was being delivered. Planning was more predictable because it led to smaller batch sizes and more transparency in terms of understanding. And because of practices such as Test-Driven Development (TDD), Continuous Delivery (CI/CD), and other software practices, quality improved.
So, they got better outcomes. That is a good thing, right? Yes, of course, it is a good thing. But the interesting challenge is what happens next? What happens when the business needs to start becoming more agile? What happens when the goal sounds similar but is VERY different?
That is where the hangover hits. To overuse this metaphor, the business wants to party, but IT has had its moment and frankly wants to focus on other things like flow, new technologies like AI and data science. They are already agile. They use Backlogs, they have taken a Scrum class, and now they have an Agile hangover and the last thing they want is a new set of training, some coaching, and everyone getting in their face asking about ‘how we improve?’ or ‘What does value mean?’. They are done with Agile and want to move on.
The uncomfortable truth is that you are never ‘done’ with Agile. In fact, Agile should never be your goal. The goal is to deliver business value in an ever-changing context and get better at doing it. The value and the context are unique to your situation. The measure of success is the value delivered, not how agile we are. Agility is a means to the ends not the end in itself. So, that ultimately means as organizations strive for business agility the reality is that people in technology that have attended the Agile party before will have to revisit it again. In fact, they should never have gone home in the first place. The reality is that things are always changing and the mechanisms to support change at the team, product, department, and organizational level need to be in place always. Yes, the amount of change work that comes out of these groups will change as the organization ebbs and flows based on its needs.
Ok, so how do you deal with an Agile hangover?
- Focus on the outcomes. It is not about Agile, adopting Scrum (even if you do introduce Scrum to business teams) it is about delivering value in a flexible and agile way.
- Align to the business and customer. By making everyone have a clear line of sight to the customer, you better equip everyone to appreciate working differently.
- Respect the experiences and learning from before. Spend time with IT teams that have been doing Scrum for a while. Listen to their advice, ask questions about why that worked, and what would things like Definition of Done look like for a business-aligned team.
- When talking about change, focus on the why rather than the gimmick. For example ‘we are introducing the ‘Spotify Model’ would instead be, ‘we are creating teams of teams aligned to key parts of our customer value stream and supporting them with discipline-based communities.’ This would create great conversations about why, how do we measure success, what are the outcomes I should expect.
- Put in place measures that support the why rather than the how. Measures are great for helping process improvement but are not a good measure of success or help reinforce the goal. What are the outcomes we are striving for? How can we learn if we are moving towards those outcomes?
And perhaps the biggest learning is to not take yourself too seriously when delivering any message. Come from a place of humbleness and empathy. Imagine what it is like for someone working in a team to always be receiving messages like ‘this is the new transformation program’ without any way of influencing that program. And everyone comes from a different place with a different perspective of reality. This is valuable and helps drive great solutions but means that listening is a key part of dealing with the agile hangover! And bring donuts. That always helps :-)