Back when Agile started out, the focus of many people was on getting things done. Getting things done the right way: with test driven development, continuous integration, merciless refactoring etc., and getting the right things done (with things like the planning game, the system metaphor, user stories and more).
And actually, software development became a lot better in a number of instances. Back then it was mostly eXtreme Programming for me, later things moved towards Scrum – at least in Germany, but also in a lot of other places. Still, the focus was on getting things done. Just by looking at the onmipresent "Scrum in «n» Minutes" presentations or even at David Harveys’s old but still excellent discussion of what is missing in those pictures it is easily discernible that most of the effort is put into the part where things get done.
Apart from the slightly disturbing fact that all those "agile processes" are in stark contrast with the first value pair of the agile manifesto ("Individuals and interactions over processes and tools") there is something else that is slightly underrepresented nowadays. Those pictures always start with an existing (product) backlog. Where does it come from? Of course the ScrumGuide includes the practice of backlog refinement (or grooming prior to 2011), but there is very little guidance on how to actually come up with – and refine – the requirements in the first place.
Even though there are many great tools available – Story Mapping, Impact Mapping, Buy a Feature, the Kano Model, to name just a few – they usually don‘t get too much air-time when agile practices are discussed. So let’s change that. Let’s go back to the old ideas – from eXtreme Programming times – of including the customer in the work, or let’s move forward to the Kanban way of managing work and model the whole value stream of the knowledge work and find appropriate tools for each section. Especially for those sections that lie “left of the backlog”
till next time
Michael Mahlberg
No comments:
Post a Comment