Agile project management methodologies, for me, still seem to be a new thing – mainly because I was out of the game for so long. Looking back pre-2000 at what we used to do with Microsoft Project, GANTT charts and all that, Agile methodologies seem to be a natural progression in the way of doing things. Another 30 years and we’ll have something else? A new new way of managing things.
I think at the start the Agile thing was all about just trying to get away from a GANTTy way of managing projects to trying something new, or at least looking at what was working and trying to model that better in project management processes rather than trying to keep fitting the irregular shaped object into the symmetrical hole of traditional project management.
But I am in a state of digression. This Scrum book. Executive summary: it’s for cooks, not chefs. Scrum seems to be a well defined set of rules for how to do something, that have evolved through trial and error, and yet don’t seem to have a solid academic background to the reasoning behind them. Although, that could be because I’ve only read this book on Scrum, and this is a book of case studies of software development projects. And again, there’s something: it’s about software development. I’m sure Scrum could be used for other projects, something intellectual such as a business process or documentation – but that isn’t documented in this book.
Something that I do like about Scrum, is the idea of having a Sprint review and retrospective meetings at the end of each Sprint. I think these are quite often left until the end of each project, if they get done at all. Navel gazing is an important part of any process, so it’s nice to see it at stages through the project life cycle.
So, the downsides of Scrum. Those of the unbridled enthusiasm set would argue that there aren’t any – and that there is the fallacy. Everything has its downside, it’s a natural part of having an upside. So, one of the things that I don’t like is the implied inflexibility of the process. Sure, it’ll work if it’s a large project with more than 8 or so developers who don’t have other competing tasks or projects, but it doesn’t work for small business (a very small team over multiple locations, multiple projects running at the same time, etc., etc., etc.)
By enforcing the terminology of ScrumMaster, Sprint, etc. and having no flexibility with Daily Scrum meetings, it can belittle the process and reduce it to nothing more that mere spectacle. I mean really, a $1 fine for missing the Daily Scrum meeting – aren’t we adults?
Scrum also suffers from the assumption that the client will be available to make decisions quickly at the end of each Sprint. This might seem a strange assumption. If the project is that important to the client you’d think that they’d want to be involved with the project. My experience is that either the client is too involved, or not involved enough, or worse still, they vacillate between the two. Managing expectation and access is quite difficult at the best of times, it doesn’t help if the project grinds to a halt waiting for the client to approve what has been done so far and help decide what comes next.
In retrospect as well, the idea of co-located work teams can be both a blessing and a curse. If your work requires a period of concentration, then not having management interrupt you can be great. However, being co-located with your work colleagues can serve as a substitution for those interruptions. Sure, having the stimulation of co-workers around you can help you when you need it, but sometimes you don’t need it. This does come down to working out what kind of office space really works for you … maybe a mix of individual hot-pluggable offices and shared café like workspace.
So, to conclude, Scrum seems to me to be the most basic implementation of an Agile process, and that for me isn’t enough. And a book of case studies doesn’t sell me any more on the idea. We’ll take what we need from Scrum, just like any of the other processes out there, and put them into the blender and see what we get.