Placeholders for conversations are outdated

‘Placeholders for conversations’ are an outdated idea that bear no relevance to a great many developers. And anyway, not every developer wants constant conversations throughout a sprint.

Probably, those who disagree are either 1). developers lucky enough to regularly speak with their users, or 2). agile coaches who embody gold standard best practice. Both are equally fine.

But what about all the developers in silver/bronze/cardboard quality teams? Being told what to do by their manager, working off tickets and documents, and just trying to get along without making too much of a fuss.

There’s no harm in striving for better, but equally, knowing the broad constraints of the system you are working in offers realistic expectations.

Why beat yourself up in retrospectives because you work off tickets, user stories or business requirements? Honestly, if that’s where your employer or line manager is at, then don’t feel bad about it. Do you really want to speak out like an agitator or change agent? Instead, you might be better off focusing on the here and now.

Pay close attention to what regularly causes work to become blocked, for work to take longer than expected, for users to complain about newly shipped features. Really dig into what’s going on here, and then assess whether you are well-placed to do something about it. Being more agile might not be the solution.

If nothing else, take the time to review the requirements ahead of picking them up for development, and don’t hesitate to kick them back for clarification and more analysis if they really aren’t good enough. This one simple thing will drastically improve the quality of software being written.

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

Get in touch if you need our help

Woking, Surrey, GU22, United Kingdom