Original photo by Fechi Fajardo, adapted by BK on Flickr
I’m going to admit something to you as an Agile coach. Clients that I work with make mistakes, and I can’t prevent them all. I don’t even try to.
Now before you decide, “That’s it. There’s NO WAY that I’d work with someone like THAT”, and pass on reading the rest of this post I’d like you to know something else, too. I think that not only is it OK to make mistakes, it’s a valuable way to learn. Perhaps even a secret to success.
So I wanted to muster the courage to admit to it. You’re still here? Fantastic. Maybe you believe this, too. If that’s the case, and you’re thinking about how to fit discovery into your Agile delivery process, you might enjoy reading about some of the mistakes that were made in a new series, “Misadventures in Agile Discovery (MAD)”.
For now I’ll start by listing out the mistakes, with a brief description. Later, I’ll fill in the details in separate posts describing the mistake further, why it’s a problem and how it was fixed. When something in the series is posted, I’ll come back here and link to it. Let’s try it out. Ready? Here goes. It’s MAD to:
- Have a separate discovery team
The discovery work is outsourced, to an external vendor or an internal department. Or, one team is responsible for the discovery while another is on the hook for the delivery. - Have a separate discovery phase
When the teams separate out, the phases become separate. Even if it’s one team doing all the discovery and delivery work, they decide to do it serially. - Put all work through discovery
With every work item the team needs to learn: what do people want, can they use it, or can the team build it. - Use discovery to justify the solution
All too often what looks like identifying the problem is really attempting to prove the awesomeness of the solution to a problem that doesn’t exist. - Build everything that goes through discovery
Why bother with going through discovery if it’s just going to get built, anyway? - Never change your Key Performance Indicators (KPIs)
If you even have them. The KPIs remain the same for every opportunity, and release after release. - Avoid talking to users
Because they’re tough to find. Or there’s too many of them. Or we’re afraid of revealing intellectual property. - Only talk to users
The team constantly interacts with users, and are loath to change anything without talking to them. - Allow the data to rule
It’s tough to make a mistake if everything requires empirical evidence to make a decision. - Start Agile discovery and delivery at the same time
Organizational change is tough and trying to start both at once can be overwhelming.
While I don’t want to prevent all the mistakes, coaching helps teams avoid the disastrous ones, learn from others and gain competency in Agile discovery and delivery practices.
Aaron is an Agile coach who loves is job because he enjoys helping people to love their job, too. You can follow him on twitter @_aaron_sanders.