On June 30th Christopher Handscomb and I presented a webinar based on our joint research on the topic of the value of enterprise agility. Over 400 people joined that webinar and there were a number of questions that we did not have time to address. This blog is our attempt to answer some of them. To avoid duplication we have grouped some questions.
Question: During an Enterprise Agility Transformation, there is often a tendency to strive for quick, short term financial gains, or other performance improvements; can you provide examples on how to find that balance to achieve longer-term sustainable growth?
DW - That is true at the enterprise, department, product, and team level. Everything we do has an impact on different time horizons. The trick is to balance those needs every Sprint. For example, if you focus on only the things required for today such as purchasing cloud services, or picking a tool that will not support the rest of the business, or even putting only the best people in your pilot teams you run the risk of being isolated and not being able to take their learning across the enterprise. But if you spend too much time in the future you will never deliver today. Every situation is different, but my approach is to focus on today and do the things that are right to deliver value with a mind to the future; this may be either in terms of the choices you make to do something differently because of the future impact, or explicitly not and making a note for review when you grow the use of agile.
You can never build the perfect process and everything changes over time, so by focusing on delivering the value today you get an immediate return. Then, you can use that learning to seed the next steps, etc. I have seen too many organizations that never quite delivered value because they spent so many cycles worrying about tomorrow.
CH - I’d like to add a couple of points. Firstly, I see Enterprise agility - building an agile organizational system - as being all about creating resilience and sustainability over time. Many of the core backbone processes of an agile organisation (e.g., planning, prioritisation and people deployment) work in service of identifying and resourcing medium- to long-term priorities and cascading these smoothly into the backlogs of individual units and teams. And that brings me to my second point: even the longest term objectives need to be broken down and ultimately show up on a backlog to be progressed in the next sprint. Processes and systems to allow this to happen seamlessly is part of the ‘stable backbone’ of any agile operating model.
Question: How important is C-Level understanding of Business Agility vs Employee Understanding?
CH - Executive understanding and commitment is absolutely essential, perhaps the most important thing when embarking on an enterprise-wide agile transformation. Successful transformation to an agile operating model touches all aspects of an organisation - structure, process, people, technology - and needs to do so in an integrated way. An agile transformation just won’t get going without active senior leadership; it is doomed from the start. And I really mean active engagement. Leaders must commit real time to understanding agility, e.g., through visiting other agile companies to get inspired and learn. Once the transformation is underway, the leadership team must remain fully aligned and committed to an aspiration, and devote a significant proportion of their time, typically 4-12 hours a week.
DW - I think it is important that any C-Level executive has enough of an understanding of agility to help remove team impediments and set the right direction. And that increasingly means a very good understanding. Imagine choices around incentives, compliance, or priorities. These 3 things require an understanding of agility because an industrial approach will end up removing value and causing friction for the teams. For example, people incentives that are planned annually and based on individual performance will encourage people to focus on those objectives instead of the objectives of the team. Without a clear understanding of the implication of a strategy, an executive will not make the right choices or set the right direction.
Of course, a C-Level exec does not have to learn Scrum or Kanban to the level of detail required by teams and supporting functions, but getting some appreciation and understanding is a must.
Question: A few times mentioned tribes and squads. It's taken from Spotify/ING model. Does it mean that it's your recommendation for big companies?
DW - I would never be bold enough to recommend the ‘Spotify’ model because the context that Spotify works within is very different from your context. I would however strongly recommend that every organization looked at why Spotify did what they did and how those design ideas would manifest in your organization. For example, the clear separation between work alignment and skill/craft development that is provided by Spotify is an interesting idea that every organization should explore. By asking the question why did Spotify organize in that way and what problems did this fix or create enable leaders to think outside of their normal box. To be effective in the modern ‘digital’ world requires leaders to challenge the existing operating model. Organizational models, skills development, team models, incentives, promotional, leadership styles, and even what things are called need to be thought through with a focus on enabling teams to deliver value frequently.
Being a Scrum person I am pretty happy with the use of the word Scrum Team, but I see value in questioning every element and building the right operational model for you. Even if that means we change the name Scrum Team to Squad :-)
So the bottom line is to learn from others but do your own thing. Look at Spotify, SAFe, Nexus, SAFe and Disciplined Agile, all have merit, but then look at your own situation. Build your own approach and then test it. Implementing an agile operating model is a complex problem, so using an agile approach is a must. Learn from others, pick a few things, get going, and then inspect the result and adapt.
CH - Building on that, any prescribed blueprint is not very agile! However, I’ve found it’s also not particularly helpful to give organisations too many choices when they’re just starting out, and ignores valuable learning from others. Rather, having a template as a starting point is very useful for companies who are relatively low on the agile maturity curve. The ‘Spotify’ model with squads, tribes and chapters is one such template which, I believe, works well as a basis for many different types of company. It can be readily tailored and clearly explained. I then encourage organisations to learn, adapt and improve all aspects of their operating model once some agile muscle has been built.
Question: COVID-19 may be considered a Black Swan event. Why should we prepare orgs for another?
CH - We were talking about agility long before COVID-19. Indeed, the research we spoke about in the webinar was conducted at the end of last year and demonstrated the impact of enterprise-wide agility in more ‘normal’ times. We conclusively showed that organizations undertaking a successful agile transformation see substantial improvements in customer satisfaction, employee engagement and operational performance. All of which translates to up to 30% improvement in financial performance. This is the type of impact that gets companies excited.
COVID-19 battle-tested the agile model in a way that we couldn’t have imagined before. We have done research that actually confirms that agile organizations reacted faster and better.
During the crisis nearly every organization, agile or not, pulled out the crisis management playbook, which has a lot in common with the agile playbook. This allowed faster decisions, a breakaway from bureaucratic processes, and more open communication. Agile organizations still had an edge, driven by specific levers/practices that others could not replicate “on the fly”, such as structurally cross-functional teams, real empowerment of the front-line and ability to quickly reset priorities via quarterly business reviews.
What we are finding is that, having experienced this new way of working, many organizations are now asking how to structurally adapt their operating model to avoid going back to old behaviors – the time is ripe for agile
DW - If the pandemic is a Black Swan event is open for debate. But I do believe that change, which COVID-19 was a VERY big example of is the new normal. In fact, big change as in the case of COVID-19 is much easier for companies to respond to because it is easy to see and easy to rally to. But little frequent changes are much harder to build organizations to withstand. For example, small buying changes by customers, or small changes to supply networks, or small changes to use of a product are hard to see but over time might result in a fundamental shift which makes a product out of date, or too expensive. I think we need to build organizations for change, change at the macro level in terms of strategy and mission, and change at the team or product level to better serve customers and deliver more value.
When I think about enterprise agility I am struck by the idiom ‘the straw that broke the camels back’. The organization of the future has a flexible back, improved straw senses, and is focused on why people are requiring the movement of Straw. Not only can it withstand a massive influx of Straw, but is also able to deal with a world without Straw! :-)
Question: It seems that going agile may necessitate a shaking up of business units or alteration of your org chart. If so, is there an "agile" way to go agile? How does an organization know where to start?
DW - The reality is the only way to adopt agile is to do it in an agile manner. Changing people is by its very nature a complex problem. The only way to see how the change works is to do something and monitor its results. To sense and respond through transparency. That means that not only should any agile change be supported with true north and appropriate measures, but it should also include a mechanism to effectively plan, act, and learn. At Scrum.org we recommend a change team that would start with Scrum as the foundation looking at the ideas of a change backlog, regular Sprints with effective reviews, retrospectives to think about how they are working, and planning the next Sprint. That Change Team might be populated by a few key coaches or Scrum Masters and people from other groups like HR, Finance, the PMO with an external coach acting as the Scrum Master. The Product Owner is the executive who is driving the change. Sprint Reviews are a fantastic way to monitor progress and provide feedback.
CH - Building on what Dave has said, I’d like to emphasise that an agile transformation is not like a ‘traditional’ reorganisation in many ways. The first major difference is that it is typically much more iterative. Whereas a traditional reorganisation typically doesn’t change anything until a detailed blueprint of the end state has been developed, this simply doesn’t work when moving to an agile model. I encourage organisations just to get going: often starting small with pilots or frontrunners, but actually start changing something. Even an individual agile team can help an organization learn, demonstrate impact and create the catalyst for further change.
As well as being iterative, an agile transformation is typically much more holistic than other forms of reorganisation. An agile operating model needs to function together as a system with structures, processes and technology all working together and all underpinned by the agile mindset and capabilities.