When I started coaching Agile methodologies, I didn’t know how much I didn’t know.
I had come from Thoughtworks, a company whose tools and processes are mostly driven by Extreme Programming, aka XP. In that respect, most of what I learnt and coached was very similar to Scrum, albeit with different words. We called them iterations instead of sprints, and had stand-ups instead of daily scrums. We had planning meetings, but we didn’t make commitments – just estimates. We had collaborative code ownership and a focus on delivery instead of a cross-functional team, which meant that we ended up with flexible and blurred roles anyway. We had the same problems – getting people co-located, helping business stakeholders become more comfortable with the risk and uncertainty of software delivery, and changing the culture and the infrastructure of the organisations in which we worked. We also had a number of technical practices like unit testing and continuous delivery that aren’t really prescribed by either Scrum or Kanban, but which both put forward as a Really Good Idea.
In the last few years, I’ve been privileged to be part of the Kanban community. I don’t consider myself part of the Scrum community as such, but I’m part of the larger Agile movement and strongly aligned through my background in XP.
In this post, I’d like to cover some of the differences I’ve seen between Scrum and Kanban, and add in some insights from the Cognitive Edge training I’ve done using Cynefin and complexity thinking. This isn’t going to be a full description or comparison, but it should hopefully provide some food for thought, and allow people to see some of the different tools available from both approaches.
Disclaimer: I haven’t explained every term I’ve used, or every practice I’m referencing. I’m assuming familiarity. If you don’t have it, you can to run a search on anything I haven’t linked. I’m also using the terms “Scrum” and “Kanban” as aliases for the community and / or leadership, and I haven’t made much distinction between Scrum.org and the Scrum Alliance. This is deliberate, and I welcome feedback.
Scrum and Kanban have more similarities than differences.
Both methodologies put people and their interactions at the heart. Both have a clear focus on value, fast delivery and the continuing growth of the team and its ability to achieve those valuable deliveries. Both contain mechanisms for feedback and improvement, allowing processes to change according to context. Scrum used to have a very prescriptive format – not dissimilar to XP – but this has been flexed in recent editions of the Scrum Guide, as alternatives to some of the practices have emerged. It’s not even beyond the realms of possibility that some of the alternatives have emerged from the Kanban movement!
Also recently, Scrum has started to evolve from being a set of processes to being a very loose framework in which processes can themselves evolve. Used this way, it joins Kanban as a meta-process, from which the real process emerges and continues to emerge.
IMO, both are infinitely better than that broken model called Waterfall, and both are better than having no process at all.
Scrum isn’t about the Scrum Meetings, and Kanban isn’t about the Kanban Signal.
Both methodologies are named after just one small aspect of their whole. In Scrum, the scrum meetings allow the team to share learning and information about how they’re doing and to make decisions about what to work on next. In Kanban, the kanban signal – showing that someone is free to help move a piece of work closer to delivery – provides a similar focus point. Scrum teams frequently use a card wall that’s similar to that of a Kanban team. Kanban teams frequently have daily meetings like Scrum. To an outside observer, the differences could seem so small as to be irrelevant.
Kanban measures lead and cycle time, Scrum measures velocity.
Both Kanban and Scrum have their origins in “Lean” thinking. We like to think of “Lean” as the set of principles behind the Toyota Production System – the process by which Toyota builds and churns out its cars – but both methodologies have an implicit recognition that software development holds more similarities with product development than a production line. In Toyota, kanban cards are used to help eliminate large amounts of spare parts and other inventory building up; providing a buffer which lets work flow through the system. Both Scrum and Kanban value this flow. Kanban suggests limits on the amount of work in progress, allowing constraints to be addressed. Scrum encourages collaboration, causing less work in progress. Scrum uses the proxy of velocity and estimation, which can help to prevent metrics around productivity becoming targets. Kanban uses lead and cycle time, tying its measurements to valuable targets that are hard to game.
Scrum starts with the right context; Kanban improves the existing context.
I once asked a Scrum practitioner, “What do you do if you don’t have a cross-functional team and you’re not co-located?” He told me that that’s the hardest bit of Scrum – starting from the right context. I realised that these difficulties, once overcome, also provide significant value. Just starting from the right context might be a good idea!
On the other hand, Kanban is neutral regarding context. Of course we think that being co-located is a good idea. Of course we’d love to have multi-skilled, flexible, collaborative professionals. If only this was as common in the industry as we’d like. Kanban’s focus on metrics and its measurements of lead and cycle time might make the impact of not having these apparent, so it’s a good place to start. (I used to think it was only suitable for highly skilled, disciplined, advanced teams, but experience and experimentation has taught me otherwise).
Kanban visualises what’s happening; Scrum visualises an ideal.
This is one of the biggest differences for me. The extent to which Kanban visualises reality is extreme enough that the board might not even have linear flow. Whatever the process policies are – whether helpful or otherwise – Kanban focuses on making them explicit, so that they can be addressed and improved. If the team happen to work with five different phases, this is reflected. If the team write technical stories, they go on the board.
In contrast, Scrum teams tend to set up a visualisation of an ideal process, helping teams to adopt that process. Done prescriptively, Scrum provides a “big bang” starting point. Because it consists of step-by-step practices, it’s easier for beginners to adopt. That could be Scrum’s blessing – but it’s also its curse.
Certification and early adoption.
Scrum has certification. Kanban doesn’t.
Yet.
In the early days of Scrum, there were few enough trainers and experienced Agilists that no matter who taught Scrum, it was done pragmatically. Early adopters tend to experiment, and those experiments led to a better understanding; to a focus on people and interaction, rather than process. Unfortunately the “Scrum Master” certificates are easy to get, compared to any other discipline that asserts a quality of mastery or independence. The training provides simple practices that are relatively easy for teams to adopt. Scrum is taught by a wider group of people, and the quality control over that teaching has become harder to maintain.
As a result, Scrum has been widely adopted and is considered pretty mainstream – the default Agile methodology – but the certificates associated with it provide a level of confidence that the training generally doesn’t support. I’ve met a couple of excellent Scrum trainers, but I’ve also seen “masters”, armed with their certificates, instituting mini-waterfall and silo’d teams as they replace those parts of Scrum that aren’t prescriptive, or that they don’t understand, or that they can’t achieve within a context that they can’t change.
Any examination or certification body suffers from a paradox: while the people who rely on those qualifications need them to be rigorous, the people teaching and taking those qualifications would much rather they were easy. The Scrum Alliance and Scrum.org between them have both helped to set up and reinforce the desirability of their certifications, and I can only imagine the difficulty that their leaders face in balancing the financial incentives involved against the good of the IT community and industry.
In contrast, Kanban is still in an early adopter phase. We’re still working out, as a community, what’s possible. Most Kanban practitioners and coaches are bright, experienced, willing to experiment, desiring of feedback and able to share and learn from each other in a relatively small community. Scrum no longer has that luxury. We don’t know what will happen if and when the Kanban community treads the same path, but we do have the advantage of being able to learn from what’s happened with Scrum.
You can also bet that the leaders are being watched carefully by the rest of the community to see how they meet this challenge. So far I think they’re doing an excellent job. So far there are no certificates available. So far.
Some thoughts spurred by Cynefin.
The Cynefin model of complexity thinking teaches us that in a complex environment – one in which cause and effect can only be understood in retrospect, and which includes most systems with people in, as far as I can tell – we should increase the opportunities and incentives for interaction, so that the practices best suited to the context can emerge.
Waterfall treated software development as complicated, using Cynefin’s domain definition; as though each project was a thing that could be taken apart into many pieces, analyzed, then put back together as a whole. Unfortunately the ability of human beings to make mistakes, combined with our inability to either effectively communicate our intent or see into the future, has meant that this was always doomed to fail. (Most successful Waterfall teams, who complain to me that I label it unfairly, have not practiced it in a pure form, and have included elements of iteration, feedback and common sense. When these are lacking, any methodology is doomed to failure, but Waterfall above all others doesn’t mandate or even leave much room for them.)
When we look at applying Scrum prescriptively to a Waterfall team, we’re looking at pushing forward increasing levels of interaction in a context in which interaction is easy – where teams are co-located, have all relevant skills, are willing to collaborate and can share learning. Scrum’s acts of estimation and breaking stories into tasks force team members to talk to each other. The act of commitment which Scrum recommends in planning meetings causes a team to discuss their concerns frankly. The cycle of feedback and retrospection allows the team to discuss whether they’re delivering value and how to do it more effectively.
But Waterfall is no longer the context from which we always come. Many Agile adoptions aren’t taken up by teams doing Waterfall; they’re taken by teams who have abandoned their process altogether, and are talking and sharing their learning in order to work out what to do next, while having no metrics against which they can improve or track their progress and risk.
The context in which Scrum starts is not often possible. We’re not always co-located – many start-ups and companies now allow developers to work from home, and the industry still seems to suffer from a delusion that offshore work is cheap to obtain. We may not have multi-skilled people – it takes some time to learn skills. In both the environments which are already more collaborative than Scrum, and the ones which are a long way from being able to do it successfully, Kanban can be useful.
I fear that this may include the majority of environments and the IT industry, and that’s why I choose to hold myself closer to the Kanban community than the Scrum one. IMO, Kanban works in a larger set of contexts than Scrum does, even though for a subset Scrum might achieve results faster.
They’re still more similar than they are different… and I still like XP too.
Before I write anything about this, I’d like to clarify what I mean by a task and a story.
A feature is something tangible that works and which we could potentially deliver, if it was enough to provide business benefit. Usually a bit of a screen or page, together with all the logic and validation associated with it, is a feature. A feature is the highest-level thing which a developer could work on without doing significant bits of analysis. It’s a part of an idea made at least concrete enough to imagine.
A story is a part of a feature on which we can get feedback from relevant stakeholders. For instance, we might code the UI, then the validation and messages, then an aspect or two of the behaviour behind the UI. Each of these would be a possible story. The only real reason for splitting features into stories is to get faster feedback and a better idea of progress.
A task is a part of a story which doesn’t allow us to get feedback from relevant stakeholders. If you can get feedback, it’s probably a story rather than a task, because it affects the UI in some way, or at least gives something that can be visibly verified and critiqued and which stakeholders care about. There are lots of UIs and lots of stakeholders and users, so “put logging in to help maintenance debug the situation where the elephant appears on the screen” might be a perfectly good story. Anything that’s just a part of a story is a task.
A task can’t really be tested either, even by a developer. You have no idea if a database has the right tables or data until you connect it to something. You have no idea if an interface to another system will work until it’s actually talking to that system. You might unit-test it, or run some queries, but it’s a level below the feedback and user testing available for features and stories. (There are higher levels of testing too, in which we can look for user capabilities and business outcomes, stakeholder goals, profit / loss, etc. – so you can’t really tell if *anything* works until you put it into production – but that’s a blog post for another day).
Why do some teams split stories into tasks?
A lot of Scrum teams particularly do this, because it’s traditionally taught as part of the Certified Scrum Master course. Hopefully good CSTs, and their CSMs, are teaching the benefits along with the practices.
It can lead to more accurate estimates. Splitting stories into tasks can help developers to think about the amount of work involved in a story, and find any pieces they missed.
It can help with collaboration. By splitting a story into tasks, developers can each take that task – usually a different horizontal slice – and work with minimal merge conflicts and just a bit of adjustment to get their piece working with other people’s. Splitting a story into tasks is useful for swarming, and a lot of swarming teams do this instinctively, even if they haven’t written the tasks down.
It can help senior developers mentor junior developers and verify that they’re taking a good approach towards a story. Some mistakes are worth avoiding.
They can be used as a measure of progress to someone tracking the team, like a PM or Scrum Master.
Why don’t other teams do this?
Some teams prefer to focus on delivering something on which they can get feedback, and find the tasks distracting.
There are also other ways of getting accurate estimates. Talking through scenarios can help with this. A lot of teams don’t use estimates anyway, preferring to stick to SLAs or their own instinctive understanding of how much work they can get done and whether they’re going to release on time. Anther purpose of estimation is usually so that the business stakeholders can have trust and confidence in the team, and there are different ways of getting the trust of stakeholders, too.
What bad things might happen if we split our stories into tasks?
Splitting stories into tasks might indeed distract from delivering something on which the team can get feedback. When a developer sees a list of tasks in front of him, he tends to work through those tasks methodically. He might not notice that, for instance, the team isn’t going to deliver *any* stories this week.
Using tasks to estimate team progress can also be misleading. If all the developers end up working on their own stories, the PM might see lots of tasks being done. If none of those stories are ready for the showcase, though, the team won’t be able to get feedback from their stakeholders – and might end up building the wrong things altogether! Also, the Pareto Principle suggests that 20% of the causes are responsible for 80% of the effects – or that the last 20% of the story might take 80% of the time. Often developers will start with the easy bits and leave the hard things until last.
People seeing the tasks can use them to micro-manage the team, asking who’s working on which task, or even assigning particular tasks ahead of time! But anyone with a manager or Scrum Master who does this has bigger problems than the task-splitting, I think.
Why do you absolutely hate people splitting tasks then putting hourly estimates on them?
First and foremost, this harks back to the old myth that time = work done. Even if developers are only held to be productive 50 or 60% of their “ideal” working day, the focus is still on the number of hours spent, rather than useful software being produced. It’s perfectly possible to spend hours on something that doesn’t work. A team which signs off all its tasks is subtly encouraged to say that they’re “done” without checking that the software they’re producing is useful.
What about the developer who plays with something else while turning over a problem in the back of his mind, then delivers an ingenious solution in 2 hours? Or the developer who wants to try out another way of solving the problem which might involve a steep learning curve, but which would benefit the project in the long run? By pinning these developers down to their hourly estimates, insisting on a certain timescale of productivity, we encourage them to tread the path they had in mind when they made the estimate, even if a different idea occurs to them at the time. Since human beings get a kick out of being right – suffering horribly from confirmation bias and the preference for validation – just the act of estimating the hours will pin them down subconsciously. They may not even think about the problem or have the new idea! Hourly estimates can stifle innovation, and the less wriggle room there is, the more innovation will be stifled.
Finally, it encourages micro-management. A project manager who sees a developer working on some tasks that should have taken 8 hours, but have taken all week, might wonder why that developer is taking so long. However, uncomfortable enquiries will only cause the developer to pad their estimates next time – and work expands to fill the time available, so the team will eventually slow down.
Should we do it or not?
If you think splitting stories into tasks might be helpful, try it. If it doesn’t help, stop. However, please resist the urge to put hourly estimates on them – or to ask that your team does so.
If you’re not familiar with the concept of Chickens and Pigs, it’s based on an old joke in which a chicken and a pig set up a restaurant. The chicken wants to call it “Ham’n'Eggs”. The pig says, “No thanks. I’d be committed, but you’d only be involved.”
The story is used in Scrum and other methodologies to suggest that only “pigs” – the people whose bacon is on the line – should have the right to speak in stand-ups. This deliberately excludes management.
Yesterday, Dean Leffingwell spoke on the subject at Agile 2011. He pointed out that the practice calls out the chickens as the “bad guys”. “Wrong!” he says. “These are the people who run the company.” Quite aside from some cultural implications of calling people “pigs” – it doesn’t go down well in countries which consider pigs to be unclean, for instance – excluding management from stand-ups can be disrespectful at best, and damaging at worst.
I finally decided to be done with the Chicken and Pigs analogy and practice after a roleplay organised by Derek Wade, in which the manager had something very important to share – something that would have reduced the stress the team was experiencing, as well as the workload, the weekend’s overtime, and the risk to delivery that was approaching our fictitious team.
The manager started to speak. “I…”
“You’re a chicken,” the Scrum Master announced. “Next!”
Let’s not.
Scrum: Hm, you’re rather small. Are you sure you want to do this?
Kanban: Bring it.
Scrum: Right. I represent a fundamental mindshift in the way that people do projects.
Kanban: So do I. My mindshift is different to yours; it feels subtler.
Scrum: I doubt that. I help teams collaborate and deliver working software iteratively.
Kanban: As do I. Unlike you, I don’t tie people down to fixed iterations; I let them find their own cadence.
Scrum: You say that like it’s a good thing! What if people aren’t even used to delivering iteratively? How can you possibly stop novices from taking weeks over their increments of code?
Kanban: Well, maybe I don’t work so well with novice teams. A high-discipline team, though, who can keep their flow consistent, will find themselves more responsive with me than they will with you.
Scrum: I help new teams get started. I give them easy, simple approaches that they can follow. You’re all about the maths.
Kanban: Actually, I’m all about the theory of constraints. By limiting work in progress, I make the bottlenecks obvious.
Scrum: I do that by focusing on getting the work through to production. What’s more, I was designed for software. You’re just the bastard offspring of manufacturing; you have no relevance!
Kanban: If I have no relevance, then why do so many people believe that I’m valuable, and fight to defend me?
Scrum: They’re in it for the money…
Kanban: Says the world’s fastest-growing pyramid scheme…
Scrum: I resent that! There are plenty of successful Scrum projects out there. We’re good people; we just want to change the world.
Kanban: I’ll settle for continuous improvement, thanks.
Scrum: We’ve got that too, except we call them Retrospectives.
Kanban: You don’t need to batch up your improvements if everyone is focused on it.
Scrum: There’s nothing to prevent us from continually improving.
Kanban: There’s nothing to prevent us from having retrospectives, if we need them, or in fact from taking on any of your valuable practices. I’m just like you, except that I have sensible limits.
Scrum: You’re not just like me. You don’t even worry about estimates half the time.
Kanban: We estimate in time to deliver, not story points. The business understand this.
Scrum: The business don’t trust my teams; they haven’t delivered successfully for a while. My planning enables them to regain that trust. You can’t even work without it.
Kanban: That’s true. Once we have the trust, though, we don’t need to waste as much time on planning and estimating as you do.
Scrum: How can you call a practice that establishes trust wasteful?
Kanban: You’re right. We value people too, you know – we work well with the Lean principles, and “Respect for People” is one of the pillars.
Scrum: Well, that’s good to know. People are the most important part of the process.
Kanban: We seem to have quite a lot in common. Thinking about it, you’d probably make quite a good stepping-stone for people learning to deliver software iteratively for the first time. I guess they could turn to me later, once the discipline is there.
Scrum: That might work. I know some people have used you in odd ways, and found value. Maybe we should just be friends?
Kanban: Let’s call it a draw.
XP: Let’s not. You may have the planning and estimation sewn up; you may be shifting your constraints and delivering responsively. Neither of you can survive without my technical practices. Get over here!
FATALITY!
Winner: XP
A phrase frequently used in the Scrum teams I’ve been involved in – as well as a few of the XP teams – is “Pigs and Chickens”.
Googling the origin, I found out where it came from. Like many terms and practices in Agile Software Development, it’s surrounded by controversy.
I have come to love the phrase, mostly because it causes people who are unfamiliar with Agile and Scrum practices to ask, “What are pigs and chickens?”
When the Agile team members smile and happily explain the joke, the people asking the questions often remember that they have other questions they wanted to ask, too. Then they find out that most Agile teams are full of real human beings who love to talk about what they’re doing and share good practices. This in turn invites more conversation, which spreads the goodness.
That leads to requests like, “Liz, I’d love to see what the team are doing with <xyz>. Can I turn up at your meeting, please, just as a chicken?”
Anything which facilitates better communication – even by being an obscure hook that invites curiosity – has got to be good.
Comments