I’ve read a couple of great posts about ‘agile’ in the last week or so – it is like 2008 all over again!
First Paul Downey strayed from the topic of lists & registers to contemplate ‘scope creep’ and then Nik Silver wrote about ‘getting partial value from partial delivery‘. Both posts eloquently cover the issue of bringing an agile approach and mindset into organisations or teams who remain uncomfortable without the security blanket(s) of a 50 page functional requirements document and a folder full of Gantt charts.
I’m a big exponent of agile working – like so many in the public sector I am a convert from the world of Prince2 and MoSCoW so in the past I have had that been pretty militant about it. There is no evangelist like the born again after all. Over the years I hope I take a more even handed approach and I have certainly become more inspired by the original Agile Manifesto than any particular methodology.
Organisationally we are making real efforts to move to a more ‘agile’ way of working but I think a lot of people are still uncomfortable with it and see it as a somewhat lazy approach – while in fact I often find I’m working harder than I ever did as a project manager back in the day (admittedly I was a HORRIBLE project manager). I find working in an agile way incredibly helpful and useful but it is not always straightforward and is certainly not an easy option.
I see the rituals and artefacts of the Agile methodologies as a ‘pick ‘n’ mix’ although over time our bag of tricks has become pretty Scrum-like/lite.
Things that really work for us:
– Daily stand-ups
– Show & tells
– Kanban walls
– Visualising everything, everywhere
– User stories*
– Sprint planning/prioritising
– Short sprints
– Regular deployments
– Fast feedback (from real users)
– Pair programming
Things we have struggled with or don’t do:
– Estimating user stories
– Burn down charts
– Release planning
Our greatest challenge from the earliest days of the Alpha has been pitching our user stories at the right level of granularity – this has been a constant battle and while we got much better around very UX focused stories elsewhere it is often still pretty painful. We have tried a number of approaches and techniques (taking an agile approach!) and at the moment (a year in) we seem to be in a good place – but we’ve been here before and then a complex set of stories in a sprint messed that up.
This problem getting the level of our stories correct has regularly made estimating in any kind of traditional Scrum like manner a nightmare so we gave up on that and have been taking a much more holistic approach with everyone having their say and the taking the temperature of the room as to what is doable. It is far from scientific but it is showing results.
I’ve always hated ‘Burndown charts’ – something about them always felt like piece-work to me – so I have always fought against their use in this project. As it happens because of the problems I mentioned above it would have been a disaster for us to try given our estimation issues. One of the original principles underpinning the Agile Manifesto was;
Working software is the primary measure of progress.
If it was good enough for those guys it is good enough for me.
I can see the appeal of ‘release planning/management/trains’ and maybe it is something that works better for software products but I never really felt it fitted our needs for what has been a pretty traditional website build really. I do wonder though – it is something that I return to on occasion.
So to reiterate – agile is not an easy way out. There are a lot of moving parts and in my experience there is a lot of thinking and contemplating how to find ways to make the processes better for the team – to make sure we meet the first principle of agile;
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
*User stories have been invaluable in keeping us focused on real user needs – we are all about ‘user driven development’ – we just haven’t cracked what level to pitch those stories at all the time 🙂