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.
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.
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.”
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.
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.
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.
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.
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.
Agile product discovery works in tandem with delivery. The best effect comes when it includes the whole team, is done deliberately and continuously. The video includes the common roles, artifacts and ceremonies involved in discovery. While this is the first of many iterations to come, I hope you enjoy! What questions do you have, or feedback you would like to provide?
How do you get started with discovery on your Scrum team? Participants learn how to improve practices like user research and interviews, persona sketching, design studio, prototyping and story mapping by actively using them in a class. At the end of the class, participants see a different way of working. Then the discussion turns to something like- While this is undoubtedly is a better way to work, it’s so different than what we do today. How can we do this stuff where we work? How do you get started?