Scaling Agile with Agility: A Focus on Teams

Agile delivery has hit a tipping point, with the majority of IT organizations finding some level of agile success. For these organizations, the next logical step is to scale this success into an "enterprise adoption", taking the value they are getting from a single team and replicating it.

This is often where it all starts to go wrong. Enterprise agile adoption is a large endeavor requiring changes to many processes and systems and adoption of new tools. Because of its size and visibility, it becomes a "strategic initiative" with large amounts of funding, plans, and oversight. Ironically, for the majority of these programs, it is done following a waterfall process with phase gates and deliverables. Activities like "Roll out JIRA" and "Train everyone on agile fundamentals" become the focus, with the agile adoption team is being measured on the number of people who become agile by getting the tools and having the training.

But isn’t adopting agile a complex problem? And, isn’t the whole reason why we have adopted agile to solve complex problems? Shouldn’t we approach the agile adoption in an agile way?

It is time to use agile to adopt agile. But what does that mean?

At the heart of all agile approaches and Scrum, in particular, are two concepts: Firstly, an empirical approach through inspection and adaption. This means that instead of breaking the work into activities, teams instead focus on outcomes and deliver on that outcome, incrementally. Sprints or iterations are the motion to execute on those incremental experiments. Daily Scrums, Sprint Reviews and Retrospectives are tools used to focus the team on inspection and adaption. Secondly, inspired by Lean Thinking, is the idea of empowered, self-organizing teams who can get work done. In practical terms, this means allowing teams to do anything necessary, within reason, to execute on their goal without any constraints of job role, authority level or even location.

Applying those concepts to scaling agile means:

• Focus on the teams – they are the ones doing the real work, delivering the customer value and are painfully aware of the problems that they are facing.
• At the program or product level, connect teams of teams. For teams that are logically working together, instead of relying on process and systems to connect them, extend the agile team to include a team of teams or a Nexus. By logically grouping teams you provide an additional group of people who can get work done and resolve any issues that are getting in the way of delivering value.
• Provide an enterprise/organization backlog that takes the issues raised by the teams and makes them transparent to the organization. The challenge with this is ensuring that this does not become a "the dog ate my homework" approach by the teams who put things in this backlog to avoid thinking around a problem. Thus, it is important that you empower the Scrum Masters and agile change experts to make the right call on when things should be added to the enterprise backlog.
• Create an Agile/Scrum Team at the enterprise level that is responsible for taking the most important things in the enterprise backlog and driving them to resolution. If using Scrum, this team should include a Scrum Master, Product Owner and Developers who are empowered to make enterprise level changes to enable the Agile/Scrum Teams to thrive and deliver more value.
• Put in place evidence-based metrics that ensure everyone in the organization is moving in the right direction and that priorities become clearer because of the relationship between the work and the metrics. For example, if cycle time and innovation ratio are key for the organization, they should form the basis of the dashboard that drives change, rather than number of people trained or tools adopted.

This does not mean that the shift to agile will be easy or that issues such as lack of empowered product owners, no access to legacy test environments, and legacy system integration issues will magically disappear. But, by focusing on an empowered change team who uses an empirical process to incrementally roll out agile, organizations will be much more likely to improve and see change vs. measuring metrics that don’t always lead to value.

Also, this simple approach highlights the fundamental shift to agility, which is a movement away from relying on process and systems to resolve issues and integrate work to a team-centric approach with a lightweight model for improved transparency. With this approach, even if the organization does not become agile, at least everyone knows what happened and has the experience to prove it.

Dave West is CEO and Product Owner with Scrum.org. He is a frequent keynote at major industry conferences and is a widely published author of articles and research reports, along with his acclaimed book: Head First Object-Oriented Analysis and Design, that helped define new software modeling and application development processes. He led the development of the Rational Unified Process (RUP) for IBM/Rational. West managed Ivar Jacobson Consulting for North America. Then as VP, research director Forrester research. Prior to joining Scrum.org he was Chief Product Officer at Tasktop where he was responsible for product management, engineering and architecture.