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]

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.

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

  1. 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.

  2. Pingback: The Path to Product Success is Not a Straight Line | Agile | Syngu

Leave a Reply