I have always been a waterfall kind of guy. I was trained in the way of the waterfall back in by university days. (It partly goes to show how irrelevant the bulk of university content is: I started my Computer Science degree only 10 years ago, and the only remotely agile methodology that was taught was eXtreme Programming, and that was only a 4th year elective… but that’s another issue.) Since then it has just so happened that the companies and projects that I have been involved in have all followed the “traditional” Software Development Lifecycle that I was taught in Uni, and that I am pretty sure has been used since the birth of the computer.
The company I am working for now has opened my mind up to the concepts and possibilities of agile methodologies, and in particular, Scrum. I was naturally a complete skeptic at first, which I hear is quite normal, but since I joined I have been starting to learn more about Scrum so that I can at least build an informed opinion.
Here is the start of what I’ve learned.
How do I define Scrum
Scrum is an agile development approach that empowers the development team to produce potentially shippable functionality periodically over the development lifecycle, instead of the “everything at the end” approach from the waterfall method. It defines a set of processes and roles that work together to provide a framework to allow the development team to identify the right things to work on at the right time, and create a product iteratively in such a way that at any time, there is a potentially shippable product.
Why Agile?
Agile methodologies were introduced as a response to the failures of traditional “waterfall” software project management methodologies. The high cost overruns, schedule overruns and overall project failures of so many software projects led some practitioners to search for a more adaptable and flexible development approach. Agile methods are methods which aim to accept the true reality of software projects: change happens. Requirements change, priorities change, constraints change, people change – and they all change in ways that you can’t expect, predict or budget for. Agile methods aim to be able to absorb these constant project changes in a way that will allow the project not only to continue, but to adapt and respond quickly to the changing project environment.
How does it work?
Scrum splits the development lifecycle into fixed-length development periods, called “sprints”. The core rule of Scrum is that at the end of a development sprint, the team will have produced a piece of potentially shippable functionality. “Potentially shippable” here means that the functionality is complete, tested, and that it works. This is the core principle of Scrum, and it is the reason that a Scrum method is so able to cope with changing requirements.
At the start of a sprint, the development team will sit with the Product owner in a meeting called “Sprint Planning”. In this meeting, the team and Product Owner will decide together which features the team will work on in that sprint. The features (called Stories) come from a Product Backlog, which is a list of all the required features of the product and their relative size/complexity, prioritised by relative business value. The team will basically choose the stories that are the highest priority, which are possible in this sprint (considering external dependencies), and they will choose only as many stories as they can have completed within the one sprint. This list forms the sprint backlog.
After sprint planning, the sprint begins. A sprint can be 2 weeks, 3 weeks or any number really, as long is it is fixed and consistent. During the sprint, the team will work together on each sprint backlog item in priority order. Once an item is completed, it is marked off the list, and the team moves on to the next item on the list.
Each day during the sprint, the team will have a “daily scrum” or “daily standup” meeting. This is a 15 minute timeboxed meeting whose purpose is to cover a) what everyone has achieved the previous day, 2) what everyone is planning to work on today, and 3) what impediments have been identified in the past 24 hours.
At the end of the sprint, the team should have completed all the items on the sprint backlog. The progress of the team over the course of the sprint can be tracked using the task board and the burn-down chart.
At the end of the sprint, there are two key meetings scheduled: 1) Sprint Review, and 2) Sprint Retrospective. The Sprint Review meeting is where the team will demonstrate each completed feature from the sprint backlog. Starting with the first story, the team will demo the completed functionality in a live environment. After each story demonstration, the Product Owner can either “accept” or “reject” the feature as completed to standard, or not. If the feature is rejected, it gets put back on the product backlog to be done again in another sprint.
The sprint retrospective meeting is something like a post project review meeting, where the team will discuss the last sprint from a process and execution point of view, and aim to identify points to improve to make future sprints easier or more productive.
The end of each sprint cycle, if executed correctly, will produce a piece of potentially deliverable code. When the project budget runs out half way through the project, for example, the result is a set of functioning features. Compare this to a traditional waterfall approach: when the budget runs out half way through the project, the result is nothing. This also makes Scrum extremely adaptive: when requirements change during the project, the only potentially affected areas is what is already built. The features that are still in the backlog have not been fully designed, fully specified etc, so you are not opening the project up to the endless rounds of re-work that goes along with continual project change.
So there’s the summary of what I’ve picked up so far. Over the next few weeks I’ll start to dig a bit deeper into each of the different phases of the cycle.
