There’s a lot of buzz around agile methodologies these days. It’s certainly talked about a lot within Jisc, and a good number of projects here have adopted agile.
Probably the most common agile methodology is scrum, but there are others which might suit your project better. Having recently completed agile fundamentals training but having been working with agile for some time, it made me realise that many projects claim to be agile and adopt scrum principles, but some fail to fully adhere to the rules.
So what are the principles and what are the differences between them? The three main ones are scrum, Kanban and extreme programming (XP). They all share the same overall principle of breaking down a bigger task (often referred to as an epic) into smaller, more manageable tasks. They also share the principle of working in dedicated teams with time dedicated to the project, away from other distractions. Let’s take a look at each one in more detail:
Scrum is the methodology which has the most rules, and clearly defined roles. Projects are run in development cycles known as sprints. These are dedicated time slots (such as a day) where all team members are expected to commit to the project (many people often prefer to work away from their usual office space to avoid distractions). Teams are made up of a Product Owner, who is usually the biggest stakeholder, there is also a Scrum Master whose role is to facilitate the team’s work, removing any impediments which might come up. The rest of the team is made up of team members. There is no team leader—teams are self managing and responsibility for delivery is everyone’s. Scrum teams work best with no more than about 9 people.
Once the scrum team is formed, the first task is to come up with user stories. These typically start off large and are broken down into smaller, more manageable stories. User stories usually are put together in the form:
As a…
I want to…
So I can…
An important principle of scrum is being able to assess user stories for size, to estimate how much development time will be needed. These don’t have to be exact—methods used to estimate include T-Shirt Sizes so size stories as small, medium or large. Another method is Planning Poker which uses a non-linear Fibonnaci Sequence (0, 1, 2, 3, 5, 8, 13, and 21)—stories are read out and team members vote on numbers.
Stories then form product backlog items a list of tasks which need to develop a minimal viable product, with no additional unnecessary work included. These are prioritised, and any dependencies taken into account. Scrum teams then meet for sprints (often weekly for a defined period, often 3 months)—at the start of the sprint teams decide on which backlog items to work on, and at the end of the sprint teams reconvene to review progress. Progress on product backlog items is made visible to all team members, who are collectively responsible for their completion—this could be a paper-based approach with product backlog items as post it notes which move from the backlog through to in development through to complete. There are also online tools such as Trello which can be used, and Microsoft Planner, part of Office 365, can also be used to keep a product backlog.
A big benefit of scrum is that testing takes place at a product backlog item level. Problems and faults are identified early on (often referred to as failing fast), and can be rectified early on in the development cycle rather than at the end as part of a larger user testing phase. Lessons are also learned early on and can be acted on which improves the performance of teams as time goes on.
When all backlog items are complete, the sprint is complete and the product is ready for delivery to the customer. Shortly after the sprint all team members attend a sprint retrospective to review how things went, and identify and lessons learned.
Kanban is a much less prescriptive methodology, and can be better suited than scrum to non-software development situations. The basic principle of breaking a larger task into smaller tasks remains, but roles and rules on how teams work are fewer. It has origins from Japanese lean and just-in-time manufacturing going back to the 1940a. Kanban is Japanese for “visual signal” or “card”, with the emphasis on managing the flow of work. As with scrum, backlog items move a across a Kanban Board, but the fundamental difference is that Kanban allows for the imposition of limits on how many items can be at a particular stage. At it’s most simple, a Kanban Board could just have three stages (to do, doing, done), but can be adapted to include stages of development (such as analysis, development, testing). Imposing limits ensures that tasks move efficiently through the development cycle and the risk of blockages is reduced.
Finally, Extreme Programming (XP) is the methodology which is most closely aligned with software development projects as the name suggests. As with scrum, it is based on having short development cycles with frequent releases, this again allows teams to fail fast and allows new and changing user requirements to be taken into account early in the development cycle. Principles of Extreme Programming include Programming in Pairs where someone writes the code while the other reviews the code picking up any issues (switching roles frequently). Frequent code reviews are an important part of XP—by getting frequent feedback, quality of software is improved.
Which method to use really depends on the nature of your project. The rules of scrum are the most complex but many opt to adopt a scrum light approach, taking the principles that suit a particular development cycle. It is important to make sure that you don’t dilute the principles down so much that you’re no longer being agile.
