In my last post, I discussed how much of a product’s success is the customers’ emotional response to the product.  Understanding that this response and feedback is critical for a successful launch, these teams would benefit greatly from leveraging a core agile principal to deliver early and adapt based on response.  In this article I’ll talk about another core Agile principal delivering early and often for the customer.

In my opinion, I’ve save the most important Agile principal for last.  From the twelve core principals of Agile; it’s retrospection.  In my experience I’ve seen even the most Agile knowledgeable coaches fail to get teams to understand what it means to truly inspect and adapt at regular intervals.  I see too many teams in software and in more traditional new product development (NPD) get paralyzed by a fear of failure or being wrong.  They get so afraid of making a mistake the best they can ever hope for is status quo.  The most critical fundamental of leading the transition to Agile in any organization is to build a cultural environment where failing because we tried to do the right thing is nothing more than a learning environment.  No matter what market you serve, or products you build, you need the teams to “go for it” in order to be truly innovative.

My recommendation is to take heart in what you’ve seen in the previous posts on leveraging Agile within your NPD teams and start with this most fundamental concept.  By starting with the learning culture and building an organization that’s constantly trying to be the best it possibly can, you will only win over time.  You will build enough confidence to just start small, learn from it and get better.  Maybe early prototyping and frequent deliveries are just too much.  That’s OK, start with a transparent decision making process where the measures of success for the team.  Show patience and facilitative qualities to learn from the teams introspective abilities to identify where you need to go next.  Listen to your customers and make that transparent to the team.  Not so that you can show them what we missed, but so that they can understand what success looks like.  If you find yourself asking “who did it” take a coffee break or a jog around the block.  Come back and ask “what did we learn from it.”

Over the last few months as this series has come together I’ve heard more and more grumblings that this only works for software and that it’s not practical in real product development.  I hope that on closer inspection of this and my previous posts you’ll be able to find and leverage the real examples from those articles to drive your NPD teams to larger success through Agile methods. To do so, you will have to be open to trial and error and acknowledge that it’s OK to make mistakes because we’re getting better from each experiment. Check out WikiSpeed to see a real example of a company running all product development in a truly Agile manner.  Someday we can all hope to have development teams this passionate about what we do and behaving “Agiley” to bring great things to market.

Print Friendly, PDF & Email