Back in January 2005 I had been married for a month and was looking forward to taking a belated honeymoon in March. As you would expect, these were significant life events, however little did I realise that something of a similar magnitude was also looming on the horizon of my work life here at Caplin. After five and a half years following a waterfall methodology our then development manager (now CTO), Patrick Myles, introduced us to our first agile software development methodology, Scrum.
Over the last five years we have learnt that an agile process is agile itself, and the process that we follow now is different in many ways from that which we initially adopted. This doesn’t mean that the process we first had was wrong, although there were certainly some issues. Over time things that were crucial parts of the process have become defunct and have been removed, whilst new ideas and refinements are added into the process to address fresh issues that have arisen.
Straight from the Book: The First Iteration
The first iteration started in February 2005. Being new to the process we followed one pretty much straight out of the book. We were desperate to adopt Scrum successfully and wanted to follow all the best practices:
- The sprints were exactly 4 weeks long
- Our development team of 7 or 8 developers were organised into a single Scrum
- The stakeholders provided a prioritised list of the work items they wanted us to undertake
- A sprint backlog spreadsheet was created and maintained
- Another spreadsheet was created that calculated the theoretical number of ideal hours we had available for the sprint, allowing for developer holidays and other commitments
- The highest priority work item was broken down into tasks which were then estimated in ideal hours
- If the total number of ideal hours of estimated work was less than the theoretical number of ideal hours we could undertake, then we estimated the next work item, and so on, until we had used up the theoretical hours (we always left ourselves a little slack as previous experience told us that things tended to overrun)
- The team then assessed the provisional list of work items for the sprint and decided whether they could commit to delivering them; if not then the lowest priority work item would be removed and the team would decide if they could commit again
- Every morning we held a stand up so that each member of the team could report on their progress and the sprint backlog and associated burn down chart could be updated
- At the end of the sprint a demo of the new software was held to show the progress that had been made to the stakeholders
- A retrospective was also held to identify things that were working well and things that weren’t, so that we could address them as part of the next sprint
A Need for Evolution
Five years on and, for me, the analogy of marriage and an agile software development is an apt one. In order to be healthy they need to be dynamic and able to adapt to change in circumstances. Within a marriage there are mundane decisions and changes to routines such as who is responsible for washing up or ironing this week, through to major changes, like after the birth of a child (particularly after a son who refuses to sleep). In software development there are small changes to the process such as a decision to restrict the number of actions to take from a retrospective, through to larger changes like the adoption of XP practices within your Scrum process.
In the second post of this series “Agile Software Development – One Size Doesn’t Fit All” – I’ll give details on exactly how we evolved the process at Caplin and provide examples of our problems and our solutions from both our Halls of Fame and Shame.