Becoming less agile to be agile

Often when I’m faced with a development team that has gotten off to a bad start with Agile, I regress the team to a pretty rigid and mechanistic implementation of Scrum.

A fairly rigid schedule of reoccurring ceremonies is rolled out, and anything bespoke or particularly ‘fruity’ that doesn’t absolutely need to be kept is forsaken for a while. The benefit of Scrum is that it is very prescriptive.

I particularly consider this approach when the development team is junior, inexperienced, or non-native English speakers.

What I’m about to say next may not be very conventional, but I also regress to ‘user stories’ that are not much more than locked-down implementation specifications, in order to give a good level of guidance and direction to the team.

I’m not trying to sacrifice agility or embed a feature factory delivery model forever, but rather ensure we all head off in a specific direction together. And the benefits that come from getting a few early home runs on the board should not be underestimated.

Once things start to be well built and the team becomes confident in the process, we begin to examine and dismantle/replace aspects that could be improved, hopefully transferring a level of personal empowerment to team members along the way.

In the early stages of making good, I have no shame in dressing up low-level requirements and implementation details as ‘user stories’, as long as everyone knows this is a temporary measure whilst we head out on a much bigger journey.

Natural limits to continuous improvement will show themselves in time, and the team should settle into a more relaxed and sustainable way of working.

Frank Ray Consulting. Software requirements for agile development teams, particularly distributed, remote and offshore development teams working in financial services.

Get in touch if you need our help