Opportunities and Threats: Seven Q1 2017 Trends Changing Video
April 6, 2017
Projects, Programme, Portfolios and other Business Transformation mechanisms
June 6, 2017
Show all

5 steps to Agile success

You’ve adopted an Agile approach to delivering your product – congratulations!

I am a HUGE fan of an Agile approach to delivery but there are some fundamental gotchas that can result in something being deemed complete and shipped even though it was really a bit of a failure (could be one or more of the following)…

  • took way too long and therefore cost too much
  • it wasn’t robust
  • not what the customer wanted

1. You NEED a product owner

Like it or not, although members of Agile teams need to be able to make decisions to be able to move forward you need to have a person that is the ultimate decision maker (not, I repeat NOT a committee that meets weekly… OK rant over). Doesn’t matter how you’ve set things up, doesn’t matter what tools you’re using, if you want success you need someone who can set direction and make decisions about the product as without this you’re looking at the fast lane to failure.

2. Break it down

Wherever possible break components down into things that are small but still make sense. It might seem odd but having more things to accomplish speeds up delivery – items can be allocated according to capability/capacity. This stops the paralysis caused by a daunting task plus it’s easier to estimate and therefore your spend will be more accurate!

3. Let the product evolve

Just because, in your Agile approach, you’ve broken things up into two week sprints doesn’t mean you’re taking an iterative approach – maybe the reason is because iteration isn’t the best way of describing what needs to really happen (in my mind it’s more EVOLUTION than ITERATION).

In a nutshell you shouldn’t try and build fully featured components in a single sprint, they should evolve over time as feedback is received

4. Know when something is complete

Quite simply, if you do not specify what conditions need to be met for a component to be considered “done” then the team are basically going to use their own judgement. As this will vary based on personal preferences or time pressures, a common outcome is the “blame game” that happens when something isn’t right. Make sure there are explicit criteria defined (it also stops components from being over engineered). From a practical perspective some level of acceptance testing must be defined so the teams can evaluate whether or not they’ve achieved their goals.

5. Let the team be a team

The one thing about people is that they are ALL different and so the way in which they behave and engage can and will differ throughout the period they’re in a team so the trick here is to build a ‘healthy’ team that is motivated and bring out the best in each other.

The best way of achieving this is to let teams be mostly autonomous; allow them to self organise and self manage – making them accountable for their contribution naturally drives teams to develop their own cadence and ways of working (just keep an eye on things, egos clashing is disruptive and toxic – treat everyone as an adult until they prove otherwise).