Agile teams are commonly told to own their process, to choose their WoW. This is very good advice for several reasons:
- Context counts. People and teams will work differently depending on the context of their situation. Every person is unique, every team is unique, and every team finds itself in a unique situation. A team of five people will work differently than a team of twenty, than a team of fifty. A team in a life-critical regulatory situation will work differently than a team in a non-regulatory situation. Our team will work differently than your team because we’re different people with our own unique skillsets, preferences, and backgrounds.
- Choice is good. To be effective a team must be able to choose the practices and strategies to address the situation that they face. The implication is that they need to know what these choices are, what the trade-offs are of each, and when (not) to apply each one. In other words, they either need to have a deep background in software process, something that few people have, or have a good guide to help them make these process-related choices. Luckily this book is a very good guide.
- We should optimize flow. We want to be effective in the way that we work, and ideally to delight our customers/stakeholders in doing so. To do this we need to optimize the workflow within our team and in how we collaborate with other teams across the organization.
- We want to be awesome. Who wouldn’t want to be awesome at what they do? Who wouldn’t want to work on an awesome team or for an awesome organization? A significant part of being awesome is to enable teams to choose their WoW and to allow them to constantly experiment to identify even better ways they can work.
In short, we believe that it’s time to take back agile. Martin Fowler has coined the term agile industrial complex (AIC) to refer to the observation that many teams are following a “faux agile” strategy, sometimes called “agile in name only” (AINO). This is often the result of organizations adopting a prescriptive framework, such as SAFe, and then forcing teams to adopt it regardless of whether it actually makes sense to do so (and it rarely does). Or forcing teams to follow an organizational standard application of Scrum. Yet canonical agile is very clear, it’s individuals and interactions over processes and tools – teams should be allowed, and better yet supported, to choose and then evolve their WoW.