Editor's note: This is the first in a series of three blog posts.
Over the past decade and even more so in the last five years, software development and IT organizations have undergone a transformation thanks to the mainstream adoption of many Agile development principles. Quite frankly, this transition occurred because software teams had lost their way. These teams were building inwardly focused infrastructures and architectures that were unnecessary and costly and were not delivering for the business or the end users. All the while, the business suffered delays and heartache over non-user focused technology.
Whether it is Scrum, XP or Kanban, the typical success rate of truly Agile teams has skyrocketed. Agile teams are delivering working software that solves real business needs faster and with more consistency than ever. In fact, according to the 2011 CHAOS report from the Standish Group, Agile teams are three times more successful than Waterfall.
Considering that over half of new product initiatives fail to meet the expectations of the business, 1 I believe there are some lessons product development teams can learn from the Agile methodology. As I pondered this possibility, the most obvious starting point was focus on the team.
With Agile principles, the single measure of success for a team is providing business value. We break down the traditional silos of product management, design, development and QA. Then each team member does what it takes to drive value into the end product.
In thinking about today's product development organizations and processes, most are still very departmentally focused. This means that NPD team members are loaned out to do tasks on many product projects, a business case for example. Unfortunately, their only accountability is to the task, not the end result. Indeed, many contributing team members can only assume a subjective guess as to a product's final success and their role in that success.
In order to address this challenge, we must build a system to make visible the desired results as well as the realized results from the team's efforts. We must also change the way we recognize the contributions of the NPD team to focus on the end result and team engagement to drive that result instead of the tasks to get to market. I believe, as a first step, more organizations should change this simple behavioral aspect. As a result, their NPD teams would deliver far more successful launches and potentially, as we have seen with Agile in software, accomplish far shorter time to market.
Continue learning about how to leverage agile principles by reading Part Two.
1 Cooper, R. D. and Edgett, S. J. (2007) Generating Breakthrough New Product Ideas.
