Mar 3rd, 2014
By: Aaron Sanders
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 validate the solution
All too often what looks like identifying the problem is really attempting to prove the awesomeness of the solution.
- 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. If you’d like help beyond what these stories relate, contact us about our training and services.
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 @aremsan.
Feb 24th, 2014
By: Aaron Sanders
Feb 24th, 2014
By: Aaron Sanders
Every so often, I see something like this on twitter
— Seb Rose (@sebrose) February 20, 2014
and decided to take all the downloads from the Agile Product Deign (apd) presentations, and upload them to our SlideShare account. To make it easier to see all the presentations in one place, I tagged them with apd.
Here’s another post in the series of how the book Thinking, Fast and Slow has made an impact on me. This time, I’d like to concentrate on the consequences I see for teaching classes. For starters, I’m glad to see that the book compliments the things I learned from Sharon Bowman’s Training from the Back of the Room, as well as from Chip and Dan Heath’s book Made to Stick.
Many people are familiar with process evaluation like The Nokia Test. There are also mash-ups of popular assessments, and I like The Borland Agile Assessment about the best. The reason I like it, is because it focuses on qualities (We work in an environment of trust and respect), rather than compliance (Single Product Backlog). When we do a process health check, we try to evaluate the qualities of the process rather than on complying to any method, system, or framework. How do you know if your process is working? How do you diagnose teams, or have them reflect deeply on their own process? Please let us know in the comments!
Evaluate Process Qualities, not Process Compliance
Evaluate process based on qualities you hope to see in a process and not process compliance. Successful approaches encourage continuous process innovation and improvement, and recognize that success is more a function of the skills of individuals and their willingness to collaborate, improvise, and improve.
- Ben Linders on Evaluate Process Qualities, not Process Compliance
- Der perfekte Product Design Sprint - die besten Methoden für kompakte 5 Tage | produktbezogen.de on Describing Agile Product Discovery
- Colin Claverie (@Coclav) on Evaluate Process Qualities, not Process Compliance
- Aaron Sanders on Consequences of Thinking, Fast and Slow – Blog Series
- Jean Tabaka on Consequences of Thinking, Fast and Slow – Blog Series