The Path to Product Success is Not a Straight Line

[Guest Post: Craig Strong, MBCS CSM has been involved with software production for over 12 years and is currently  contracting as a ScrumMaster for Sky. Having been a developer Craig has experienced first hand the effects and problems when being managed by various project management techniques and frameworks. On a daily basis Craig is responsible for managing,coaching and improving cross functional teams using Agile. Follow him on Twitter @craigstrong and blogs at www.c6s.co.uk]

Although I see this often, I am always amazed when people assume they precisely know the path of a project and want to stick to it until the very end, even if that’s in the distant future. Why do so many stakeholders and project managers get so caught up in sticking to the original plan at the cost of change. Let’s get this right people, change is good! It’s so good, it even says so in the infamous manifesto :

“Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.” – Agile Manifesto

Although it’s safe to presume that everyone using Agile pretty much knows the above, is it understood and practiced well? You can carry out all the facets of Agile development and still not be “Agile” as a business. I often hear comments such as, “what about features ABC which are in the backlog, we still need those right. Thats what we agreed to in the original plan, you must deliver it!”. The answer of course may very well be yes you may need both, or maybe not. Just because it was set in the original requirements, is that enough to assure its value.

The key component of change is value!

A core concept of Agile development is the ability to change direction often and when needed with the use of discovery exercises such as the sprint review. Feedback can come from anywhere, from market analysis, the teams building the solution or customers. Such changes are made when new requirements are discovered and those changes have more value than other items remaining in the product backlog. All we need to do is order them by value, factoring the remaining time. Simple right?

It seems in many other different areas in life, change is carried out and never questioned. Anyone driving to the office each morning will know this. Whilst driving, one is constantly watching the road, other vehicles, the weather and their own vehicles performance amongst many other things, looking for changes to react to very quickly. If an obstacle occurs such as road works, the driver alters course to the destination. What the driver has done, is evaluated and concluded that there is more value in changing the path. In some cases could have even changed their path to avoid a catastrophe. Yes the finish line in this metaphor is the fixed destination being ‘the office’, but the journey to get there is not always constant as with almost everything in life. Even Barack Obama stated the risk of such in his presidential campaign :

“I don’t care whether you’re driving a hybrid or an SUV. If you’re headed for a cliff, you have to change direction.” – Barack Obama

Why isn’t this so easy in reality?

Well aside from the fact that old habits die hard, the inbred thinking of traditional linear product based projects, wrongly assume that the most efficient way to get form point A to B in projects is a straight line.

This is particularly the case within software industry.

Most projects are planned this way, an example being waterfall projects which are straight lines that are staggered through Gantt charts. In reality point B is in fact value and as soon as you start your journey from point A, the value could have changed from point B to point C. Therefore fixing the path to a products destination through a straight line will devalue to the result or in extreme cases kill projects. Don’t assume that the original product specification is fixed. Expecting to deal with change often, will ensure that value is the focus, not the original plan itself. If businesses stick to their business plans to the letter in favour over responding to the market, customers and competitors, that is a plan to fail. Being Agile is having the ability and knowledge to change and using it when necessary.

FacebookTwitterLinkedInShare

5 Responses to “The Path to Product Success is Not a Straight Line”

  1. Robb
    August 17, 2011 at 11:03 am #

    The image of the road sign is perfect. At some point you are going to have to change directions. full speed ahead on the path embedded in some stakeholders minds only leads to a dead end and could potentially cause casualties.

    • peter
      August 17, 2011 at 11:17 am #

      Fair enough, good points Robb!

Trackbacks/Pingbacks

  1. The Path to Product Success is Not a Straight Line | Agile | Syngu - August 18, 2011

    […] experienced first hand the effects and problems when being managed by various project management… Read more… Categories: Agile     Share | Related […]

  2. Tambores da Selva» Percussões » A longa e sinuosa estrada - August 18, 2011

    […] é obviamente sinônimo de curva. Interessante encontrar no Agilescout um artigo de ontem sobre as mudanças de rumo em projetos e como é infrutífero se agarrar à certeza de que é viável saber a priori exatamente todo o […]

  3. » What’s a Product Marketer Doing with the Roadmap? (Series 2 of 4) » Agile Scout - April 24, 2012

    […] new product features often and incrementally, which is important in a changing marketplace. Marketers don’t want Agile Teams to slow down, lose the rhythm, or delay incremental improvements but we urgently need to know where you’re […]

Leave a Reply