When faced with a development team that has gotten off to a bad start with agile, I often regress the team to a rigid and mechanistic implementation of Scrum.
A schedule of reoccurring ceremonies is rolled out, and anything bespoke or particularly ‘fruity’ that doesn’t absolutely need to remain 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 prescriptive implementation specifications 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 ensure we all head off in the right direction together. The benefits of getting a few early home runs should not be underestimated.
Once things start to go well and the team becomes confident, we start examining aspects of the process to improve, aiming to transfer personal empowerment to team members along the way.
In the early stages of making good, I have no shame in resorting to overly prescriptive requirements with implementation details, 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.
If you are unhappy with your development team, they may need more detailed guidance.
Better software requirements can help with this.
|
Frank Ray Consulting. Software requirements for agile development teams, particularly remote, outsourced and offshore development teams working in financial services. |