Scrum and Kanban are two major planning methodologies that took over the software development world.
They both share the same goal. They will force you to split a project into individual tasks then assign these tasks to developers week over week, until the project is complete.
Scrum originated from north America, from a pair of professors in Harvard, seeking to improve software development speed. Kanban comes from an engineer in Toyota, Tokyo, seeking to improve manufacturing efficiency, later adapted to software.
Actually, the Harvard professors were Japanese, so both methods are originating from Japan, more or less.
Let’s take a closer look at them and how they are applied to software projects.
We’ll start with Kanban, it’s a bit easier.
Kanban literally stands for “billboard”. It is a to-do list put on a board and split in multiple columns “to do” + “doing” + “done”.
The picture speaks for itself. It is fairly simple methodology, yet very effective.
If you have ever written a list and used a sticky notes, you are qualified to use Kanban. Chances are that you already used it without knowing you did.
Don’t be surprised by the simplicity. The hard work is figuring out what needs to be done and which to do first. To determine that, you will have to discuss with your coworkers and managers from time to time.
The board can be customized a bit. Software projects will typically adopt a variation like “to do” + “this month” + “doing” + “done” + “cancelled”.
The “this month” helps to keep track of medium term goals, beyond what you are already doing. The “cancelled” archives tasks that didn’t go anywhere.
As always, the Japanese delivered something lean and practical.
Why am I writing text for so long indeed? If I gave just the picture to an intern, he’d have figured it out 10 minutes ago already. You sure did.
A bit of practice and you’ll be perfect. Remember, you will have to update the board from time to time, inserting new tasks and moving existing ones.
Next, let’s take a look at scrum.
There are entire books, month-long trainings and expensive certifications about Scrum. It might be difficult to cover all of it in a blog post.
Scrum in short. Developers and managers/clients meet every week to decide what needs to be done. Except the lead developer is called a scrum master, the manager/client is called a product owner and the development team is not important enough to gets its own name.
Time is not counted in weeks, that would be way too straightforward. It’s counted in sprints, a sprint being 1 or 2 weeks.
Let me rephrase that then. In scrum, the product owner, the scrum master and the development team meet every sprint to decide what should be scrummed in the next sprint. Note that the word “scrum” has its origin in rugby so expect a lot of running around and fights.
Features are called user stories. Features not done constitutes the backlog. Backlog is a real word present in the dictionary.
The scrum methodology can get quite fancy, I won’t cover everything. You could end up playing poker as a form of project management. Or you could be forced to stand up in circle every morning and dance to explain what you completed yesterday. (Dancing was added in a later revision to make the daily meetings shorter).
At the end, Scrum produces a scrum board. Typically displayed as a whiteboard with sticky notes.
Scrum can also be customized to fit your needs. If we change “in progress” to “doing” and delete the “story” column that’s redundant with todo and… holy shit, that’s a Kanban board!
This was all the same from the start. Turns out Scrum is Kanban but with weird names for everything.
Effective Software Development
There is a third method for to do lists. We’ll refer it as “effective software development”.
Effective software development is when you lead projects and they are delivered well and on time, but you don’t use special naming for your methodologies.
Of course, the main features are identified and the project is split in separate tasks. They can be displayed as a list or a board or both. The format and the naming are not really important as long as the employees can understand it.
On the one hand, we have Kanban, typical of the Japanese style. It’s lean, effective and to the point.
On the other hand, we have Scrum, typical of the American style. It grew from the base principles into a successful cash machine, irrelevant of what it was intended to be at the start.
Let’s conclude on a good news. If you have ever written a todo list as part of a successful project, it means you have real world experience with both Scrum and Kanban. You can claim both on your resume and that’s well deserved.
To conclude. Let’s promote a book about project management. Cracking the PM interview. If anything scrum taught us, it’s not so much about getting the job done than about getting the job.