Why Agile Methodologies don’t quite work in small software businesses
A few years ago this thing called “Agile” started to be mentioned. At the time I was working on part of a large distributed communications system as part of a small team that had managed to eek out a way of working that involved genuine analysis, design and test driven development loosely encapsulated using the Rational’s Unified Process . It was almost like you read in the textbooks at university. At the time, although I didn’t know what Agile development was, I remember my colleague proudly announcing that we were very much on our way to being Agile, which given his enthusiasm, meant that there was something fundamentally right about the way we were working.
Roll forward a couple of years, another job and Agile suddenly became the buzzword everyone wanted to be a part of. A new director from Sweden complete with an important sounding job title and very fashionable glasses gave an inspirational introduction speech advocating the brilliance of the Agile methodology and how it would turn around our company’s fortunes. A very nice trainer with a big hat and guitar was hired to mentor us and in due course, I was convinced that Agile was the way forward. It is was so simple. So elegant, So easy to follow. How could it possibly fail?
I then joined the team at Macrium, full of enthusiasm for all things Agile. There was quite a bit of enthusiasm for working in an agile way so I set about setting up a sprint framework. There was already a backlog on which to work and given that we had an existing product, I was convinced that the “agile way” would allow us to easily add small nuggets of new functionality. I thought to myself “What could go wrong?”
Well the simple answer, is that nothing has really gone wrong, but to say that we work using the text book agile methodology would be a bit much. The problem for us is that there are too many external inputs that can not be controlled, specifically customer support. Since the developers deal with customer support (if you think this a bit odd, see our justification here) and you never know what sort of support load you are going to get during sprint planning, there is not a lot you can do if one of your developers ends up spending a couple of days each sprint working “off-sprint”. It may be the case that a customer encounters a bug which really just has to be fixed at which point any future development gets canned immediately until the bug has been sorted out. It is easy to say that the bug should be put on the backlog and prioritized at the next sprint planning meeting, but that could be almost 2 weeks away and here at Macrium we pride ourselves for the customer support we offer issuing regular updates and fixes. However, the demoralising aspect to all of these distractions is that by the end of the sprint there is usually a long list of things still in the “To be done” and “Doing” columns of our sprint board on Trello.
What do we do well and what could we do better?
I think the bottom line of all this is that for us, the key is to take the Agile Method with a pinch of salt and pay more attention to being agile rather than doing Agile. We do wonder if reducing our 2 week sprints to a week might improve things but the argument against is that the bureaucracy of having a sprint planning meeting every week would eat into the development time available. There is no doubt that having a two week development cycle is a motivator and we try to get a patch out more or less every two weeks.
We have a scrum meeting every morning which is hugely beneficial for the team to find out where we are all up to and share any immediate problems. A recent retrospective found that we focus too much on what has been done rather than what is to be done, so we plan to focus more on the end of the sprint hopefully motivating us to move all those “To do” cards into the “Done” column. We also need to be a little more realistic about the amount of work we plan for each sprint and take into account the support we will have to deal with and other external distractions.
We do have retrospectives but not necessarily at the end of each sprint since the size and informality of our team is such that we don’t feel the need to wait to the end of a sprint to improve the way we work.
Agile is a great methodology. I truly believe it can work well for self contained teams with a clear and well identified task in hand, but for small independent software companies where there is a more all-hands-on-deck approach to running the business, external influences mean that to be truly agile, you need to take Agile with a pinch of salt.
11th March 2013 — Since this post was written
We have actually moved to a one week sprint with the emphasis being more on refocusing rather than replanning. Items are added to a “current sprint” board whenever they are required and developers are at liberty to work on individual tasks for as long as it takes to get them finished. This solves the demoralising “You did not finish your sprint task so it goes back onto the backlog” situation that haunts any poor developer who underestimated their workload for that sprint. We have also done away with hard deadlines and they also serve only to demoralise stressed developers who get into a knot half way through a task. We do aim to try and release every couple of weeks but again, this is not a hard deadline. The basis of development now is a weekly business oriented refocus on what is being done and what should be done followed by daily meetings to check everyone is making progress.
