The death of agile

The Death of Chatterton by Henry Wallis or a depiction of everyday man flu.

We agilists can be a bunch of drama queens: “the death of agile” cri-de-coeur should be accompanied by swooning and frantic fanning. Nonetheless, while lots of corporations are now declaring themselves done with their agile transformations, those who have actually experienced a well-run agile project know that it all feels a little bit shallow. When I’m at my most despairing, I’ll throw myself down on the couch and decry:

  • Vaguely recurring, vaguely defined meetings retitled as “stand-ups”
  • Teams that are building burn-up charts without any sense of their historical capacity
  • Agile software engineering practices confined to the parts of the portfolio where they’re easily implemented – rather than everywhere.

These are the trappings of a superficial agile transformation.

When I’m more sanguine, I see that these are just opportunities to improve our practice in more areas of the business.

We’ve had a lot of success with our engineering teams in implementing agile within their own sphere of work. But it’s not enough. My focus now is on two areas in particular:

Product ownership

I think the product owner is the most misunderstood role in our agile practices. It’s also one of the most difficult roles when it’s not set up properly. Melissa Perri explains some of the confusion well in this article. For me, the product owner is the person who is responsible for ensuring that the things delivered deliver the most value most quickly to the business. As such the product owner is someone who sits between users, stakeholders and delivery team without being exactly aligned with any one of them:

Role of the product owner
Sitting in between these groups is a tough job for a product owner

A product owner talks to users – regularly. Ideally, he/she/they do this in the company of properly trained UX researchers in order to elicit exactly what the user wants. In the best run projects, there’s a user forum dedicated to listening and talking to users where the product owner and delivery team explain the features delivered and to come. The product owner is not craven to user needs although most product owners I know don’t talk nearly enough to enough different types of users. And I’m still shocked at how many products go out without good instrumentation and feedback mechanisms.

Users and stakeholders – as well as the delivery team – should all come together in the showcase. The product owner is probably doing updates separately in other project meetings to his/her/their stakeholders and at different degrees of detail depending on their seniority. At those meetings, stakeholders are sure to have ideas about priorities and focus for the product. Product owners should not be craven to stakeholders’ input but many product owners I know are far too subservient to their stakeholders’ opinions. Very few product owners are set up with the right level of empowerment or accountability for outcomes.

A product owner talks to the delivery team daily. Why would he/she/they do this? Because how can the product owner deliver anything unless it’s comes through the delivery team? The best product owners form a really close relationship with the delivery team. They work with the teams to adjust the work so that value emerges quickly and reliably. But product owners should not be craven to the delivery team’s sense of what’s possible; it’s the product owner’s job to challenge the delivery team to do more and better. The advanced agile delivery team provides plenty of metrics to allow the product owner to do that. It is the product owner’s job to understand those metrics and to hold the delivery team to account for improvement because improvements represent better return on the investment in the delivery team. On the other hand, I also see a lot of product owners wash their hands of delivery teams’ difficulties with a lofty “I wrote the requirements”. Excellent product owners know how to write requirements in a way that makes them easy to implement, can explain to the delivery team about why those stories matter, and is open to suggestions from the delivery team about how to implement them.

End-to-end delivery teams

I’ve recently stopped using the term “development team” because I’ve found that it constrains people’s thinking about the nature of the team. The best agile teams have all the resources needed to deliver a solution without recourse to other teams. The reason is simple: when all the people, knowledge and resources are available within the team, you don’t need expensive coordination meetings or processes to handle the work hand-off protocols. That’s often impossible in an enterprise setting but I’m often surprised at how often we don’t even try to set them up in this way.

Enterprises worry a lot about utilisation of different skills. All skills are scarce at some level; enterprises tend to concentrate these skills into pools because, with the right processes and planning, you can ensure that you have exactly the “right” number of those skills with no waste. Agile team formation goes against that: you put all the right skills into the team to accomplish the goal. As so often, I find myself coming back to sports team analogies when we look at agile teams. An enterprise-view of a soccer team would say, “Hey, we’ve noticed that the goalkeeper only seems to be 10% used on this team – let’s create a pool of 10 goalkeepers for 100 soccer teams – when the goal is under attack, have the team submit a ticket and we’ll assign a temporary keeper.”

Similarly, it’s inconceivable that every member of a sports team would not know the score of the game or not recall the score of every game in the season. And yet, when I talk to team members of agile teams, only the iteration manager or the manager knows the team’s capacity, or how many defects it had last iteration or its average work-in-progress. That points to a failure in the team’s understanding of its purpose. Usually it’s not the team’s fault that they don’t know why they’re there. 

I often see teams that are “set up” before the outcome of their work is even defined. One danger there is that when you fill teams with bright people and don’t clearly define what you want them to achieve, they will invent that purpose for themselves. Another danger is that they’ll just passively accept whatever is thrown at them or refuse to do work because they don’t have the skills. You can’t form a team without knowing what you need it to do – and yet, with our approach to development teams, that’s exactly what happens. We build teams that conform to a mould: two BAs, three developers, three testers, one iteration manager, whatever. Stamp and repeat.

Whenever I ask people to describe the best team they’ve ever been on, it’s still rarely a team at work. Even after we’ve “done” our agile transformation. But it is possible to have the best team time at work and if we want to do that at enterprise scale, we have to have properly empowered product owners who can challenge a truly end-to-end team to do its best work ever. A bit more thought about how we set up teams and connect them properly to really empowered product owners should be the next step in our agile transformation.

This entry was posted in Uncategorized and tagged . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s