Kanban vs Scrum

I recently came across a great free book written by Henrik Kniberg and Mattias Skarin called, "Kanban and Scrum - making the most of both". It includes the most concise description of each development process that I've seen.

For Scrum, your overall concern is with timeboxing everything, making sure that there are short cycles and short meetings that are strictly adhered to. With Kanban, your main concern is with limiting the amount of work in progress. By limiting how many items are in each phase of development, your aim is to establish an on-going flow. It seems to me that Scrum is better geared for new product development and Kanban is better for existing products that need maintenance and new features. There is obviously much more to each and I recommend you read their book.

Business Value is Always the Goal

When you are creating software for a business, the creation of business value is always the goal. In general there are only two ways that business value is created. Either you are saving money because you make a process more efficient or you create new revenue with a new process, product, or feature.


As the goal of software development, it means that we are not even considering the qualities of systems that software developers are generally concerned with. So it makes absolutely no sense to create a system that is really easy to maintain if that increases the cost of the system so that it doesn't provide business value. These qualities have to be understood as constraints and they are understood in terms of trade-offs. If you are absolute about them, then you will have a hard time creating a successful system. This seems completely reasonable and obvious, but it happens all the time. Always remember: the cost of the system has to be less than the business value created.

The Daily Scrum or Morning Meeting

A scrum or morning meeting is the best way to get control of a development process. Having it in the morning seems like the most natural part of the day for everyone to synchronize, obviously, before everyone has started working. Not first thing in the morning because everyone needs time to have some breakfast, review new email, read the news, and get settled in. About a half-hour should do it. The other good thing about having it in the morning is to ensure that everyone gets to work on time, which gets to the essence of how a scrum works - peer pressure. When someone is late to the meeting, it is not just clear to their manager, but to the whole team. So they are not letting their manager down, they are letting the team down.

During the meeting, each member of the team goes over what they have accomplished since the day before and what they are working on. According to strict principles, the meeting is not supposed to become a status meeting run by the project manager (technically the role is supposed to be called a scrum master, but I don't like that name). Personally I like having the project manager run the meeting. I prefer the direction that it gives. And you still end up with the peer pressure because everyone is listening.

Using Humans in Your System Design

A mistake that a lot of people make when creating software is to try to automate everything. When you are making software for a business, you are generally automating a process and there is often a desire or drive that people have to make software that automates the whole process. They get into an all-or-nothing frame of mind that, unfortunately, usually ends up with nothing getting deployed, or, even worse, software that gets deployed which tries to do it all and fails, disrupting the business and wasting a lot more money.

There are many different strategies and methodologies to deal with this situation. Agile is probably the most popular and successful. One of the main tenets of Agile is to deliver business value as soon as possible. And in most situations in order to deliver that value quickly, you obviously can't program everything. And if you can't program everything, you are going to have to learn how to design humans into your system. This is something that a lot of software people seem uncomfortable with because they view the system they are building purely as a piece of software and think that automation is the ideal. But full automation is not necessarily the goal, creating business value is. (I'll have more to say on this in a later post.)