Author Archives: Aaron Sanders
It’s MAD to Build everything that goes through discovery
People nod heads with a knowing look when someone informs them that less than 50% of ideas make it to market. That may even seem generous. Companies practicing continuous product discovery collect data on the impact and unofficially report numbers far lower than 50%. These companies test multiple ideas weekly and most are not pursued.
It’s MAD to Use Discovery to Justify the Solution
Have you ever had an executive, a board member, or some other high-ranking person tell you what to build? How were you able to stand up to them? And keep your job? Decreeing the solution happens with such regularity that my Product Owner course is designed to mimic the situation.
The vagabond lifestyle
It’s MAD to Put All Work Through Discovery
I was sitting with a team when their manager came in and asked, “Hey. Are you guys finished with this feature?” The Scrum Master responded, “We haven’t even had time to even begin the discovery on it yet.” The manager looked surprised and said, “Oh, OK. Would you let me know when I can see it?” and walked out. It really surprised me as the feature seemed trivial and so I asked, “What do you need to learn about this? It seems really straight-forward.” “You’re right.” he said, “We could just build this. But we don’t want to.”
Evaluate Process Qualities, not Process Compliance
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, because it focuses on qualities (We work in an environment of trust and respect), rather than compliance (Single Product Backlog). Jeff Patton wrote an article, Performing a Simple Process Health Checkup that is based upon properties taken from Alistair Cockburn’s book Crystal Clear. The following is a modified version that a client and I put together for their context.
It’s MAD to Have a Separate Discovery Phase
Here we are with another Misadventure in Agile Discovery (MAD). This one pairs well with the first misadventure, the separate discovery team. Even when that mistake is corrected and a balanced team is working together through discovery and delivery, the team may decide to spend some time furiously creating a slew of new ideas.
It’s MAD to Have a Separate Discovery Team
Diving deeper into the first item on the list of Misadventures of Agile Discovery (MAD), let’s look into the problem of having a separate discovery team. Let me start with a couple of stories.
Misadventures in Agile Discovery: Top Ten Common Mistakes
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.