When talking about software development, you’re bound to hear the word ‘Agile’ at some point.
Many organisations claim to develop software in an Agile way, but it is important to remember that Agile is not a methodology; it’s a set of principles that guide software development practices. It can perhaps be best conceived as a value system by which decisions are made, work is approached and tasks are completed. In short, it’s:
- Individuals and Interactions over processes and tools
- Working Software over comprehensive documentation
- Customer Collaboration over contract negotiation
- Responding to Change over following a plan
That’s all well and good, but what does this look like in reality? Many Agile frameworks have been designed to give shape to these principles, the two most popular of which are Scrum and Kanban. Each of these frameworks aims to break down complex software development tasks into smaller, valuable increments of work. They both value efficiency, optimisation of processes and continual improvement. It’s these values that underpin life at TAB.
Scrum is perhaps the most popular Agile framework and many people, though incorrectly, use the two interchangeably. The name Scrum comes from the rugby scrum, and is used to symbolise the interlocking, cross-functional nature of the Scrum team, who are all focused on achieving their shared goal. Scrum derives much of its theory from Agile and articulates this in its approach to roles and workflow. It is prescriptive in its nature, providing a structured environment in which Agile can live. In Scrum, there are timeboxed iterations of work called Sprints, and within these four key ceremonies that provide the team with a structured, predictable way to work. These are:
- Sprint planning - this is when the Scrum team comes together to estimate and plan the work for the upcoming sprint. The team’s commitment to delivering the work is a central part of Scrum, though of course there are safeguards in place if the team does not complete all stories prioritised for the sprint.
- The Daily Scrum - usually in the morning, this time is for the team to update each other on progress and blockers. In Scrum, each member of the team will give an update on what they completed yesterday, what they are working on today and if there are any blockers.
- Sprint review - at the end of each iteration, the Scrum team and stakeholders will come together to demo, review and discuss the work completed in the sprint. This is frequently used as a time to gather stakeholder feedback, which can be prioritised for upcoming sprints.
- Retrospective - at the end of the sprint, the Scrum team will come together to reflect on what went well and what didn’t. This is essential to continual improvement, to ensure the team is always optimising their ways of working.
- Backlog refinement - though not officially one of the Scrum ceremonies, most sprints will include a dedicated time to review the backlog and ensure each story includes enough detail to be sized and started on. It typically will happen in advance of Sprint Planning.
Scrum’s popularity can be attributed to its predictability. This can be particularly beneficial when it comes to working with inexperienced teams or stakeholders, when the project is short or when the backlog is defined. For longer running projects with established teams, where the focus has shifted from ‘what to build efficiently’ to ‘how to build it more efficiently’, Kanban may be a more suitable option.
Key things to note about Scrum...
Best for: teams with stable priorities and a relatively defined backlog. Also good for new teams that require structure or have a desperate need for increased efficiency.
Key roles: the Scrum team comprises of the Scrum Master, Product Owner and Development Team. They focus on the when, what and how of what to build respectively
Focus: moving all stories planned for the sprint across the board within the timebox
Key metrics & estimation: velocity; story points
Limits & parameters: time (the sprint)
Change agent: team commitment
Originating from Toyota’s car manufacturing, Kanban is all about driving efficiency through visualised workflows. Far less structured than Scrum, Kanban works best for teams with varying or fluctuating priorities, or those with existing processes who are looking to increase efficiency through gradual and continuous improvement. If Scrum centres around its four ceremonies, then Kanban focuses on its four principles:
- Visualise work - the Kanban board is where the workflow is made visible to the entire team. It should be simple as consists of three primary states: to do, in progress, done. This is a good starting point for those adopting the Kanban framework, and it can then be adapted to suit the team’s needs.
- Limit WIP - the amount of work in progress should be kept within an agreed limit. The general rule in Kanban is little and often, which in turn prevents a build up of work (bottlenecks that can be seen on the board) and waste from context switching.
- Focus on flow - like a car production line, this should move through to a state of ‘done’ in a continuous, steady flow. A build up of work in progress is likely to cause problems, especially if the team needs to go back and fix things. Keeping work small, manageable and bite-sized makes the process more efficient.
- Continuous improvement - Kanban acknowledges that no process will ever be perfect and that nothing remains still forever. There is always room for improvement and it is a vital part of Kanban to acknowledge and act upon this. Efficiency is about learning from experience to move things forward.
Kanban takes much of its inspiration from Lean software development. Like Agile, Lean is a set of principles or an approach by which to develop software, though it is now more commonly viewed as an Agile subculture rather than a standalone philosophy. Lean focuses on the reduction of waste in the process as a means of increasing efficiency. It also emphasises learning, team empowerment and improving the quality of the whole system rather than its component parts.
Key things to note about Kanban...
Best for: teams with fluctuating priorities who want to focus on continually improving the efficiency of their process and workflows
Key roles: roles are more fluid and the responsibility of getting value across the board to ‘done’ is shared by the whole team
Focus: moving individual stories across the board as efficiently as possible
Key metrics & estimation: cycle time; estimation optional
Limits & parameters: work in progress (WIP)
Change agent: WIP limits.
HOW WE WORK AT TAB
The simple answer is both! There is no correct way to build software and each team and project is unique. At TAB, we are firm believers that processes should suit teams and the products they’re building, not the other way around (remember: individuals and interactions over processes and tools). We’ve found that many teams will adopt practices from both the Scrum and Kanban frameworks, or what is widely known as Scrumban.
From Scrum, daily stand ups, retrospectives and sprint reviews provide a valuable forum for team discussion, increased visibility and stakeholder alignment. Kanban, and Lean more broadly, is popular at TAB, as efficiency is at the core of what we do. Implementing WIP limits, reducing cycle time and eliminating waste are standard practices in our product teams. As we work with businesses for long periods of time, often over the course of several years, Kanban helps us to focus on continuous delivery and improvement.
Does this sound like something you’d like to get involved in? Check out our openings for Agile/Delivery and Product roles.