Tag Archives: shippable product

Agile in name only

I see a lot of implementations of agile product development methods that seem to me to be agile in name only.  They typically have not achieved a higher rate of success than whatever method was practised previously.  As a big fan of agile methods for many years, this bothers me.  The reputation of a great approach could start to suffer from a proliferation of poor implementations, and that would be a shame.

The current problem with agile is that everyone from individuals to outsource software development companies have to claim they do it to get hired.  However, there is often little investigation initially into their true level of understanding, and little follow-up to see if what they are doing subsequently is truly agile.  Often the people doing the hiring and buying are unsure themselves of what they should be looking for,

Using Scrum as an example (other agile methods are available!) the problem seems to be that people feel that if they practice one or two of the Scrum techniques (typically chopping their workload into two week packages – ‘sprints’ – and doing a daily stand up meeting – the ‘daily scrum’) then they are ‘agile’.  Nothing could be further from the truth.  The most important principles of agile are:

  1. The focus should be entirely on the outcome, not on the process.  In Craig Larman’s terminology “focus on the baton, not the runner”.  In Scrum terms that means every sprint should deliver a ‘potentially shippable product’.
  2. Teams should be genuinely multi-functional.
  3. Everyone should commit to the sprint.  Ie everyone should do whatever it takes to fully complete the sprint and achieve the outcomes, no matter what.  If it nearly kills you this time, then you will be better at estimating next time.

When I ask people why their sprints are not producing potentially shippable products, but instead producing software to be used at a later date, they tell me that the two week sprint is not long enough, and ‘the tester’ can’t fit all the testing into the end of the sprint.  That argument is the antithesis of agile thinking.  Sprints should be as long as it takes to produce a shippable product. Anything from one week to 12 weeks would be a guide.  If a sprint would need to go over 12 weeks to deliver a product, then sacrifice the principle (for once) and split the sprint in two to reduce the chances of storing up risk in a long cycle.  The other issue with this oft-heard argument is the belief that testing is done by a specific function or person(s).  Rigid functional divides have no place in agile.  If you cannot achieve the ideal of everyone being able to do everything (though the problem is usually lack of will rather than lack of ability) then it should at least be the case that developers should choose to start helping out on testing rather than looking to optimise their own personal productivity by doing work unrelated to the current sprint.  The best implementation of Scrum I have seen is in a highly successful investment bank where team members do everything (analysis, coding and testing) and genuinely work together to achieve the outcome.

I have implemented and operated agile (Scrum, XP and DSDM) for many years.  Before that I was (and remain) a big fan of lean methods arising from the ‘Toyota Way’ of continuous improvement.  Agile and Lean share a lot in common.  I have concluded from my various travails in getting agile to work that the surest way to achieve success is through targetted assessment and selection of people and suppliers.  With individuals I find that people who score highly on the Conscientiousness dimension of ‘Big Five’ personality tests always work well in agile environments.  They are the people most likely to not sit in their own self-created functional bunker.  Also, at interview, if people focus on telling you about how they did something rather than telling you about the outcomes and business benefits of their involvement in a team, then they are probably not what you need.  With suppliers, look for give-aways such as talk of functional roles (eg ‘dedicated testers’ and ‘dedicated scrum masters’) and overhead roles designed to hold artificial functional divides together (such as project and programme managers).  Such talk and organisation is not agile.

In conclusion, agile is a behaviour not a methodology.  That is why the ‘a’ is not capitalised.  Agile is a state of mind.  People who are agile look at everything from the customer’s perspective.  Beware of ‘agile in name only’.

Cliff Moyce

ps For Scrum, I highly recommend the books and services of Craig Larman, and Ken Schwaber