As I’m writing this post, I’m in my hotel room in London after celebrating my daughter’s graduation from Cambridge this weekend. Anyone who has tried to plan a graduation celebration from another country (I live in the U.S.), with a daughter who is stressed about her finals, can understand why my mind is on the benefits of agility this morning.
What is Agile Product Management?
While agile product management has gained popularity in recent years, a well accepted, clear definition is still missing. I recently read an excellent blog post by Roman Pichler, author of Agile Product Management with Scrum, which cited some major differences between agile product management and the more traditional product management practices. In his post, Roman points out that because change is the only constant, and flux and unpredictability are dominant forces, the result is a very low probability of accurately forecasting customer behavior. Employing an empirical approach (agile product management) allows a product to evolve based on customer and user feedback. He asserts that agile product management not only saves time and money, but also increases the likelihood of delivering a great product.
At Confluence, we also view agile product management as fundamentally different from traditional product management practices, but not mutually exclusive. We’ve found that incorporating traditional analytical practices early in our process still makes sense. We believe that analytical practices (market research, business cases, etc.) are still very important, but that these practices need to be time-boxed to avoid what we fondly refer to as “analysis paralysis”. Our hybrid approach is to employ traditional analytical practices to quickly research the market, using that information to define what we will build; but then leveraging the agile practices of product backlog, single product owner and frequent releases to ensure our products are accepted by the market.
Confluence’s Agile Process
Our Experiment
In November of 2011, we set a goal to launch Unity NXT™ Expense Processing before the end of 2012. As we began our planning process, we realized that we had no chance of meeting our goal using our traditional methodology, so we decided to adopt more agile practices.
We very quickly selected a product team, arranged training for the product team on agile practices, selected a product owner, secured market members to participate in feedback sessions and started developing our MVP (Minimum Viable Product). We co-located teams where possible, used video conferencing where we couldn’t, and traveled often to bring the team together. It was a time of tremendous change at Confluence and we stumbled often; but we were able to launch Unity NXT Expense Processing AND our cloud-based Unity NXT Platform within a year!
Now that we have refined our hybrid model and practices even further, we have reduced our product delivery cycle from 18 months to 9 months! One key to the continued reduction in the product delivery cycle time has been our implementation of iteration demos. We build our software in 2 week sprints, which we refer to as iterations, and then we demo the software across Confluence and to selected market participants every 2 weeks. In December of 2012, we began work on another new product which will be launched this year. In fact, we are currently installing the MVP (I will discuss the often misunderstood MVP further in an upcoming blog) version with a customer right now!
The Answer
The answer for Confluence to the question posed as the title of this post is: YES! While it took a culture change from “predictability through control” to “learning through experimentation”, as well as tremendous focus and tenacity to achieve those results, we have shortened the lifecycle for launching new products from years to months; and we continue working diligently to shorten that cycle from months to weeks.
I’d love to hear about the success stories and/or challenges others have faced trying to accelerate their product delivery capabilities…