“A significant proportion of the ‘big players’ in Fraud Prevention are now offering machine-learning based tooling to their clients”
Comparing two agile methodologies
I’ve been a fan and practitioner of Agile for over 6 years, and the two formats I’ve used are Scrum and Kanban. But I’ve always viewed Kanban as something for BAU teams — development teams that are assigned to fix bugs or deliver regular small releases, whilst Scrum is the go-to methodology for Agile projects.
It’s always good to challenge your prescribed ways of thinking, and recently I’ve seen and read things about how Kanban is actually a good Project Management methodology, and could be regarded as a ‘step up’ from Scrum to be taken by experienced teams. Really?
So this post is about putting the two methodologies side-by-side. How are they similar? How are they different? And ultimately, which one is better?
How are they similar?
- Both use a ‘board’ (physical or digital) which displays the workflow of the team, and offers an easy way for stakeholders to see what the team is working on, what they’ve finished and what they’ll work on next.
- A prioritised backlog used to decide the order that work is taken up by the team.
- Work items on the board exist in different ‘states’ such as Analysis, In Development, etc, so it’s easy to see what stage a piece of work is at and helps make a digital, nebulous process like software development analogous to a more tangible one like manufacturing, and this brings its own benefits too (such as making it easier to spot bottlenecks in the process).
- The daily stand up — a meeting where team members inform the rest of the team what they will be working on that day (the format of each team member’s update can differ slightly between Scrum and Kanban however).
- Scheduling and estimation for a higher level project plan are done using past performance metrics for the team.
How are they different?
- Kanban practitioners suggest having sub-states for tickets on the Kanban board , with different states (‘In Development) being broken down into ‘active’ / ‘blocked’ / ‘done’
- Kanban has no concept of ‘Sprints’ (a timeboxed iteration of development with a defined start and end). It is continuous.
- Aside from the daily standup, Kanban has no other prescribed meetings, whilst Scrum has several other meetings that should be done during each sprint — sprint planning, a demo and the retrospective.
- Work in Progress (WIP) is an important feature for the Kanban board. It restricts how many items can be worked on in parallel in the same state (eg: the team can only have 3 tickets ‘In Development’ at any time).
- ‘Continuous delivery of value’ — as Kanban is not time-boxed, work is delivered constantly and can be deployed when required, rather than at the end of a sprint.
Which is better?
Having worked with teams at various stages of scrum maturity, now what I see when I compare these 2 methodologies is not two distinct ways of working but a sliding scale where the scrum master and team can choose how far to one side they go. This will depend on the team, your stakeholders and your deployment schedule.
Got a big feature to implement? Why not put in a few key Scrum ceremonies (demo, retrospective) so your team and project stakeholders have regular milestones at which to catch up on and review project progress.
Working mainly on small enhancements, bug fixes, or have a dedicated team of business testers available? Maybe you can move more towards Kanban, with fewer prescribed ‘meetings’ and a continuous drip-feed of done stories for business users to test.
This comparison also highlights what the most important agile elements are because they’re needed in both scenarios — a prioritised backlog, a board, a daily stand up meeting, items tracked as individual tickets. This is the stuff newer agile teams should focus on first.
If you were hoping for a definitive ‘this is the best Agile methodology’ conclusion — sorry! Maybe you’ll be happy with my mini-epiphany instead?
The big realisation for me was that both methods were complementary rather than competitors. It introduces some exciting possibilities for the various Scrum teams I work with, and I have a list of the most important items to focus on if I start working with a team that’s new to agile in general.