The prevailing agile methodologies don’t really fit the way that modern product teams work. Some practices need to be added, some discarded. Most of all though, the mindset that’s encouraged by the way agile is commonly taught and understood needs to be shifted.
Agile - the agile of the Agile Manifesto - is service centric not product centric. In fact, the word “product” does not appear in the Agile Manifesto or the 12 Principles at all. We need a new name for the agile - the “product agile” - that works in the context of modern, empowered product teams building modern digital products.
As a name I like Product Agile, which defines itself in opposition to service agile, but I prefer Empowered Agile. It borrows directly from Marty Cagan, whose work documents and evangelises the practices common in the best product teams all over the world.
Empowered Agile is a positive and inspiring brand, and it has to be if it’s going to stand a chance of solving the entrenched problems of service agile.
There are teams all over the world already living in this happy empowered future, but most companies aren’t. They’re still stuck with adversarial relationships between the teams who deliver software and “the business” that provides “requirements”. Even after an agile transformation the hoped-for product innovation doesn’t materialise. I’m suggesting that this is partly because service agile lends itself to being viewed as a delivery framework that promises increased speed within the technical teams, but does not require any real change upstream.
In this vein, there is much money being made at the moment by large consultancies selling concepts such as the Scaled Agile Framework (SAFe) or Large Scale Scrum (LeSS). These methods take on the challenge of delivering large projects by taking Scrum and adding multi-team choreography and coordination. These frameworks are not suited to product innovation because inherently they are scaled, and with scale they lose agility. There is too much space between the technologists and the user needs and the time penalties imposed by the choreography make the rapid learning required by product teams impossible.
There isn’t a name yet for the type of agile that fits with product teams1, but it needs a name in order to compete with the likes of LeSS and SAFe in the minds of the leaders of technology organisations. Empowered Agile could become the toolkit of choice for any product organisation that realises it must innovate to survive and thrive.
The Agile Manifesto was a rallying cry for bespoke software development consultants fighting against project management processes left over from the industrial age. They were coming together from a number of different agile backgrounds to state their shared principles. They were in general against big design up front, large batches, and penalties for changing requirements and in general for iterating on working software, and continuously improving teams.
However, although collaboration with customers and business people is front and center in the manifesto, it’s clear that the mindset of technology teams serving “the business” is still there.
Looking at what was written:
From the four values:
Modern digital product teams don’t negotiate contracts with each of their customers for bespoke work. Even a large enterprise client generally only has limited influence over the product roadmap, and any features that they ask for usually won’t be exclusive to them. This is the language of a bespoke software consultancy.
From the 12 principles:
Yes, working software is essential and it must provide value to satisfy customers. Yes, working in small batches is better. But no, working software is not the primary measure of progress for a modern digital product. It’s a measure of output with no reference to the outcomes desired.
The customer of the manifesto is not the customer of the product at all - they’re the sponsor from another part of the business commissioning the work, or they may be the client stakeholder of the bespoke software development consultant.
We know now that we can’t innovate on digital products and features without deep knowledge of who is going to buy it and who is going to use it. The key issue with the manifesto here is that room is left for separating the team that is expected to innovate from the real end users and customers. The people doing the innovating - whoever it is speaking to and thinking about customers and writing the requirements - in service agile are too far from the technology. If you’re too far from the technology you miss out from the insight that engineers and designers can bring; what is (to paraphrase Marty Cagan) at the intersection of customer needs and the only now possible.
The solution is to push responsibility for deciding what to build to the teams themselves, and this implies real contact with the real customers.
The why and what of what is produced gets a bespoke service mindset treatment in the manifesto. “Requirements” come from “the business” and the software must be “valuable”. Progress for the team is measured in terms of “working software”, presumably signed-off as delivering on the requirements by an internal or client stakeholder - this is measurement based on outputs.
In the world of digital product innovation value is hard-won and cannot be taken for granted. Any value created is always in relation to a real business outcome. But it is quite normal for working software to be delivered that doesn’t deliver any positive business outcome at all, so working software alone can’t be the measure of progress. Instead, it is far better to shift to measuring team success as progress on business outcomes.
In order for a team to innovate, it needs to know what the desired business outcomes are and how to measure them. There needs to be a realisation that not all working software delivers value, and there needs to be a way to discover what does. It’s not good enough for the team to consider itself to be somehow separate from “the business” and as such not have to worry about the specifics of the actual value, if any, that it is producing.
The key changes from service agile are that we need to push down responsibility for deciding what to do to the teams and increase trust to the point where teams are allowed to work with the real customers and users. The good parts of the manifesto should be retained and improved upon - the focus on small batch work, continuous improvement for example. In addition though, I think the following principles are key:
Empowered Agile needs to be for product teams, including all of the people that can be on those teams, usually developers, product managers and designers. It can’t fall into the trap of being viewed as a way to make the delivery teams create software more quickly.
It also needs to imply change upstream - a team can’t be doing Empowered Agile if the work is all output dictated by senior stakeholders within the company.
An Empowered Agile team should be able to release changes into production without needing to rely on other teams. To achieve this, the technology and organisation needs to be structured to minimise dependencies - in other words to “minimize the blast radius of change”.
This is the issue that frameworks like LeSS and SAFe are trying to address with inter-team choreography. This leads to a loss of agility, so the solution is to descale the work instead of scaling the process3. The teams, the technical architecture, the release strategy, the safety culture, the product strategy and the product itself all need to be arranged such that any individual team can discover and deliver value in their zone of influence without having to wait for others.
Practices from the DevOps movement4 such as continuous deployment and chaos engineering can deliver consistent, fast and safe release of high quality software5. Techniques such as microservices, event driven architecture or even domain discipline within a monolith can be used to decouple the work of one team from another. See the book Team Topologies for how teams are being structured in successful technology organisations to achieve scale without losing agility6. An obvious example of a product strategy that allows for teams to work in a decoupled manner might be a two sided marketplace where the buy-side and sell-side teams are free to operate independently from each other with separate desired outcomes, subject to constraints.
An Empowered Agile team is trusted to deliver on business outcomes agreed with upstream stakeholders, within any constraints imposed by the company and product strategy.
An Empowered Agile team’s success is measured against progress on the outcomes, and not on the quantity of working software delivered.
Traditionally a team might be expected to deliver software on a roadmap with set dates and features dictated by senior stakeholder. Whilst high integrity commitments to implement specific features by a certain date are sometimes necessary - to integrate with a key partner for example - these should be minimised. Any roadmaps should be largely thematic, based on the high level strategy and vision of the product.
All this requires that senior stakeholders actually have a defined company and product strategy. If they don’t, then it’s impossible to set the outcomes that the individual product teams should chase. I like Stephen Bungay’s definition of strategy as a deployable decision making framework7, which neatly describes how upstream staff must set the direction (and constraints), thus empowering employees to make the right decisions.
Finally, Product Managers on Empowered Agile teams must be more than just service agile Product Owners who take orders for features from upstream and administer the delivery of the backlog. A successful Product Manager needs to be competent to understand the company and product strategy, know how to speak directly to customers and users and generally be worthy of the trust required to be able to make product decisions within their zone of influence.
Product discovery is the work of finding out which new software will progress the team towards the desired outcomes. This work needs to be carried out by the Empowered Agile team in parallel with the work of delivery of working software. See the work of Teresa Torres with regards to what Continuous Discovery looks like8, and the existing practice of single team Dual Track Agile9 for how this discovery work can successfully be integrated into a team that is simultaneously delivering production quality software.
Really none of the above practices are new, and in fact there are many successful organisations around the world who already work in a similar way. The key challenge is getting agreement and mindshare from the large mass of companies who don’t yet realise that they are being left behind. Agile itself, in the form of Scrum and other frameworks, does have that mindshare - there can’t be a technology leader anywhere that hasn’t heard of or can’t see at least some of the benefits of agile. This is why I think it’s a good idea to take that brand and iterate on it rather than starting something new. I hope that Empowered Agile sticks as a concept and as a name.
Maker of internet things. Digital product person - into product management, building and running product teams and full stack web development.
Recently I've been reading, listening, thinking and writing about how people and companies can succeed with digital products. I've got a newsletter with selected thoughts and curated resources that you can sign up to here:
