Why Scrum Is No Longer My First Choice

I’ve been using Scrum for 4 to 5 years now and it’s great. I have delivered quality software with Scrum, and had delighted customers. It almost always led to a better product than Waterfall allowed me to deliver, at least in the same time frame. When I started it was fairly uncommon, and hard to convince customers that it was a good idea. Now it’s commonplace and most customers expect it. So it obviously works, and it has gained a good following.

Scrum allowed me to deliver software following agile principles, which allows the software to evolve to meet the clients changing requirements as they see and explore the product. It was a great leap forward. But things could be better, and new methodologies have been adopted by various companies. Kanban is one of these. I have gradually begun to prefer using Kanban over Scrum, and in this article I’ll explain where I think Kanban solves the various issues I experience with Scrum.

Agility

Scrum is agile, that I am not debating. However, how well it implements agile I will debate. Scrum is an easy transition from waterfall to agile, as it is not too dissimilar from many short waterfall projects combined together as “sprints”. It allows change, but at regular intervals, and change in between must wait.

This only seems semi-agile to me. Why shouldn’t we be able to deal with change as soon as we need to? The solutions to allow this in scrum seem sub-optimal. “Add a change task that sets aside some time to allow change in the sprint” is an answer I have received from scrum-masters. To simplify, bend the rules and avoid the defined process in scrum to handle change. Or by the strict letter of Scrum, stop the sprint and plan again. This doesn’t seem very agile, and is very disruptive.

Kanban handles this far better in my opinion. Any change is prioritised when it is raised. If it’s the next most important item in our backlog, I will do it next. Seems simple, and it is simple. As we aren’t committing to a 2 week body of work, I’m not restricted in when I can begin the work. Because of Kanban’s simpler approach to backlogs and delivery, handling change is simple, and agile.

Estimation and Planning

Scrum has a well defined planning process. We have a planning meeting at the start of every sprint where we decide what we will deliver in the sprint. We assign stories to individual people, and then those people break all their stories up into tasks, assign time to the tasks, and confirm that they have the right amount of work for the sprint.

Where this fails is in the estimation of individual tasks. This is just waterfall planning over again, and teams often execute this with little to no information to support their estimations. The usual result of this I see is poor estimations that match the time the person had available that sprint, rather than accurate, well thought out estimations of time.

In addition to this, the amount of user stories a team member is estimating in this time is usually a fair amount, which means a lot of context switching from thinking about one problem to the next. This almost always leads to sub quality estimations as a team member cannot provide the appropriate amount of time and thought for accurate estimations.

I almost always see teams in Scrum working longer hours than they were meant to, making up for this flaw. But it rarely gets picked up. We delivered what we committed to in the sprint, so we must have picked up the right amount of work, quickly forgetting the additional effort they put in to achieve this. I have seen teams work long hours sprint after sprint to deliver what they committed. Teams are not very good at recognising poor planning. Whilst this isn’t a flaw of Scrum per se, Scrum helps encourage this behaviour.

Kanban on the other hand again makes this a lot easier for those planning. Plan your user story when you pick it up. This allows an individual to think in detail about one particular task. I find this means they put a lot more detailed thought into how they need to deliver it, and leads more accurate estimates. If a key user isn’t available to discuss the work item, they can put it on hold, schedule a time, and move onto something else they can plan and deliver. Overall, Kanban tends to lead to fewer changes from the original estimations, and teams staying fresh and focused without the need for long hours.

Quality

One negative of Waterfall projects is “the crunch”. The end of the project, where the deadline suddenly approaches and we have a huge amount of work to do in a short space of time. Scrum helps negate this. By having lots of smaller deadlines, we don’t get one big crunch at the end of the project.

However, we do get many smaller crunches. Every two weeks the team are pulling together for a demo, bug fixing, testing, making sure everything works for the demo. What does a crunch mean? Stress, potentially long hours, and rushing to hit deadlines. This inevitably leads to drop in quality. There just isn’t always the time to test as we like, bugs appear late on in a sprint, where we are doing the final testing, and we just can’t spend all the time we would like to hit the high levels of quality we would want.

Kanban eliminates the crunch entirely, and switches the focus to delivering quality. Each item follows a flow from proposal through to delivery and we can put in all the quality checks we like before an item is integrated into our application. We separate delivery from demos, and only demo what is ready and meets our quality expectations. Unexpected bugs mean we just consider that item not ready, and integrate/demo it at a later date.

It’s a different way of thinking, but many teams are switching to ‘feature based delivery’ and Kanban supports this very well, along with continuous delivery tools. By delivering a feature as soon as it is ready, we bring benefit to the end user as soon as possible. Kanban allows us to ensure each feature goes through the same rigorous quality checks and is ready for release as soon as it is complete, rather than waiting for an artificial sprint deadline.

Focus

In Scrum, an individual team member may be working on a number of work items in a sprint. It’s rarely smooth delivering a work item, and you are likely to hit issues, whether that’s learning you need to do to figure out a solution to a problem, or something you need from a third party that causes a delay. It’s fine, you usually hop onto another work item, and work on that instead until you can work on the first again.

However, I find this often leads to team members completing multiple work items to 90%, and suddenly the end of the sprint is a lot of context switching and chasing blockers. Deadlines are put at risk, and quality may drop.

Kanban says you can only do one thing at once. You also want to minimise work in progress and put a focus on delivery. I have found simply by switching to Kanban, those same team members that would complete multiple work items to 90%, were suddenly delivering one work item as soon as they could and prioritising removing blockers wherever possible. The way this information is presented in Kanban, and the conversations we have puts the focus on where it needs to be, progressing the in progress work before starting new work.

Why aren’t we all using Kanban?

There is often resistance to implementing Kanban. The common arguments against Kanban are the following:

1. We don’t commit to any delivery within a certain timescale
2. Without the pressures of deadlines, team members will take longer to finish work items, leading to longer delivery times
3. Lack of knowledge of Kanban processes

The above are all valid concerns, however I think they can all be addressed fairly simply. Firstly, isn’t the no commitment to delivery just an extension of the argument we had against Scrum initially. People feared the flexible scope, fixed cost and we argued it would lead to a better quality product that better matched the clients ultimate requirements. The same applies to Kanban. Kanban is extremely open, with a lot of information, and full opportunity to guide the product at any stage, more so than in Scrum, so give your customer full access to your Kanban boards, and let them reap the benefit.

Longer delivery times, and team members slacking are always a potential issue, but setting deadlines is not the best way to resolve this. Trust is key. A team member that will not work hard enough to deliver work items when empowered is not a team member we want, and we should handle that with the individual rather than compromise our delivery methodology. In my experience, give team members the freedom of Kanban and they usually shine, picking the tasks they can best deliver, and delivering a high quality of work. The team pull together and there is a real sense of collaboration to deliver the best product at the end of the day.

Finally, lack of knowledge is a challenge, but one we also faced when we started Scrum. That knowledge does not go to waste when we move to Kanban, it’s still agile at the end of the day and most processes translate over. We have a daily stand-up still, that is simpler and more focussed on what we need to know right now. We still have regular meetings with the client, though these can be more flexible as we don’t have to have fixed length sprints. We also get a wealth of information from Kanban, and this really helps the retrospectives. Anything you don’t know, you can learn. There are a wealth of resources out there, and more and more training courses are being created for software delivery with Kanban.

Making the switch

So if you are wondering if Kanban is right for your project, how do you make the switch? It’s not hard. It’s still agile, so the same principals apply. You can start using Kanban at the start of your next sprint. Keep the same sprint meetings, same daily standups, and just change your planning.

Many tools support this switch nicely. If you’re on VSTS, you have a Kanban Board ready to use in your project. If you are on github, you can add one to your project. Many other Kanban projects provide good integrations into existing development tools.

So try it out, see how your development team responds. It’s safe to do and I have switched from Scrum, to Kanban, and then back again, so you aren’t committing to anything you can’t undo if it proves to be wrong for your team. With the right team, you’ll find yourself more agile, and delivering higher quality software in no time.