NPD Tales

Ideas Thoughts and Comments on Product Development

‘Agile’ Enters the Mainstream

An intriguing article in The Guardian at the weekend.

From it’s humble beginnings as a revolutionary reaction to the ever increasing complexity of software development processes – through (ironically) to a ever more rigid way of working – and ultimately having a more general impact on product development in a world where flexibility is a key requirement – agile has now been developed (or misappropriated depending on your view point) to provide a solution for an even wider range of business problems.

Of course there’s a mix of inaccuracy and cherry picking running through the article but isn’t that how ideas develop?..


If you look back on my previous posts you’ll find many examples of methods and tools that I’ve found to be either useful, interesting or intriguing (Enterprise Wikis, Planning Poker, Atlassian – FedEx Days and even Boys Keep Swinging and a whole lot more).

There’s a fundamental problem with the introduction of any new ideas into a product development process (or indeed completely re-engineering a process) – and it’s all about how the ideas are introduced to the engineers and how the methods are adopted.

Unfortunately many of these new ideas are introduced superficially and imposed upon the product development team, sometimes with a fervour that verges upon the religious (with the associated need for faith).  Not surprisingly there is resistance which by itself is a problem, but far more damaging is the rigid way in which the ideas are expected to be applied.

Far greater value can be gained by understanding the ideas, methods and tools then adapting and adopting them to suit the organisation, business environment and technology in which the team operates.

I’ve been hearing a lot of horror stories about Agile Software Development that remind me of previous reports of Six Sigma, PRINCE2 and Stage Gate…

Shu Ha Ri

The concept of Shu Ha Ri is rooted in Eastern philosophy and martial arts.  It describes the stages that a student practitioner must follow to learn and apply a technique.

Shu (’keep’, ‘protect’) – the stage where you follow the defined methodology precisely and comprehensively.

Ha (’detach’, digress) – the stage where you start adapting the techniques to suit particular circumstances.

Ri (’leave’, ‘transcend’) – the stage where your knowledge and skills allow you to blend and develop the techniques in a creative and unique way.

When exploring a new methodology for product development it is easy to fall into the trap of having only a limited knowledge and experience of a particular concept (like Stage Gate or Agile or Lean) and leaping straight to the ‘Ha’ or ‘Ri’ stage without having really explored or understood the basics by passing through the ‘Shu’ stage.  This can often have disastrous results…

Of course the key is to find ways of accelerating your progress through the ‘Shu’ stage.

Planning Poker

The world of Agile Software Development has thrown up a bunch of interesting ideas which are equally applicable in other development environments.  Planning Poker is one of the more interesting ones.

It’s more like a fun version of Wideband Delphi (even the name is more interesting), and is used to generate more accurate estimates of effort to complete tasks.

A group of people are assembled and each participant is given a set of cards with numbers on them.  Sometimes a Fibonacci series is used (0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89), or some other progression (one set uses the sequence 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100 and includes a ‘?’ card and an ‘I need a break’ card in the form of a picture of a cup of coffee).

Each task is discussed (avoiding the expression of opinions regarding the effort required to complete the task to avoid ‘anchoring’).  Then each participant selects the card (in secret) that reflects their view of how long it will take to do the task.  All the cards are revealed – major discrepancies are discussed and the process of selecting cards is repeated until a consensus value for the estimated effort is reached.

The tool needs careful facilitation and a commitment to adhere to the process, but offers a speedy and interesting solution to the task of project planning and task estimation.

Agile Product Development

Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and helping others do it.  Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas

© 2001, the above authors
this declaration may be freely copied in any form,
but only in its entirety through this notice.

Important and ground breaking words that resulted in a huge shift in the perception of how to write software.

But if you replace the word ’software’ with ‘product’ and think about what you are doing, can it provide pointers to improve the way you carry out new product development?