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.
Kanban
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.
Scrum
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.
Conclusion
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.
If you are curious, there are other methodologies worth reading about. Namely eXtreme Programming for day to day development and Unified Process for the complete project cycle from start to finish.
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.
The HFT Guy 
I’ve not been following Scrum much, but I think you’re right about the issues with it. When I first heard about Scrum in the early 2000s I’d already been doing XP for a while and Scrum looked to me like XP with the technical practices removed, leaving just the planning practices.
The XP planning practices and Scrum can indeed be done pretty simply by anyone with reasonable intelligence, technical or not. However, we have non-technical “project management” jobs in software development that need to be justified by those in them, and thus simple things they do are likely to have complexity and decoration added to them to make them look more difficult than they really need to be. (The fear of these people, of course, is that the developers could do all the project management as well and they’d be out of a job. This is an entirely justified fear.)
That said, the core of XP planning (and, to at least some degree, Scrum) includes some things that go beyond “to-do lists on boards.” A major goal of the planning process, which you completely left out, is the ability to estimate accurately and reasonably far into the future (certainly more than one iteration) what you can do. There are two things in XP planning practices that let you develop this ability. (Scrum may or may not do something similar.)
First is the rule that only developers can estimate time for a story. (Time may be expressed in ‘points’ for technical reasons I won’t get into here, but it’s still effectively time in the end. In XP there are two roles, “customer” and “developer,” with different responsibilities and privileges and there are certain areas where they are not allowed to intrude on each other. (This doesn’t mean one person can’t perform both roles at different times, so long as he keeps clear the roles and what’s allowed to them.) The primary areas of non-intrusion are that only customers get to decide in what order stories are done and, as above, only developers get to estimate them. This is critical because to get accurate estimates you need to reduce as much as possible any bias or incentive towards lowering estimates and customers have a lot of bias in that direction.
Second is the use of iterations, in particular tracking the total amount of work that gets done in an iteration and updating the estimated work you can do in future iterations based on that. This involves being pretty realistic and harsh with failures on the estimation side, be it because a story was mis-estimated or the amount of work that could be done in an iteration was mis-estimated. You need to sit down at the end of every iteration and decide if you really got everything done or if you have to go back and both fix your estimates and do some work on the process that led to those incorrect estimates.
When you can accurately estimate how many units of work each story takes and how many units of work you get done in each iteration you can now make good decisions about what features you’re likely to have to drop to hit a release date (or, less often, what extra features you could add). And I’ve seen this work very successfully; I’ve had projects in the past where there was no issue with starting critical tasks “just in time” rather than having to start them early because we could be absolutely sure how long they would take.
A lot of projects I’ve seen don’t do project management at this level, even if they say they’re using Scrum or something similar. And, from the looks of it, the guy using that Scrum board in your illustration isn’t, either, since I don’t see there anything indicating that they’re actually estimating, checking their estimates against reality, and updating estimates based on that.
LikeLike
Scrum and Kanban have a backlog of tasks to do. They will take longer than one iteration to complete. That doesn’t make them long term planning methodologies, they really have nothing about long term planning.
XP never had planning. I recall the original manifesto was 12 itemized points that were all about development practices. Keep the software always runnable, write tests, fix bugs…
What you describe is the burndown chart in Scrum. Have a a time estimate in every tasks, then theoretically you can chart at any point how much work was done and is left to be done. It has one major drawback though. It’s utterly misleading until one third of the project, where the project is scoped and well understood, it’s hard to identify and estimate the tasks well before that.
We both agree on one thing. Decide week over week what tasks should be prioritized, so you’re always using your resources and times effectively. That’s really what keep a project on track.
I’ve only seen two things with long term consideration. There is unified process (in various simple or commercial implementations) and there are custom methodologies that don’t have a name.
LikeLike
I’m not totally convinced you’re right on Scrum, but I’ll take your word for it for the moment.
However, XP has had planning from the start. The first book on it (at least that I know of) was Kent Beck’s 1999 Extreme Programming Explained which went into detail about it. The planning portion of XP were considered important enough that only a year later Kent Beck released a second book devoted entirely to that, Planning Extreme Programming.
If you have a look at the XP practices (which are the same as those from the original book) you’ll note that one of them (and the one that takes the most explanation) is called “the planning game.”
This is not just short-term planning, either. I no longer have my first edition of XP Explained, but the second edition has Quarterly Cycle as one of the “Primary Practices”.
A lot of people may not understand that XP is designed to help long-term (on the order of months) as well as short-term planning or, even if they do, may not use the facilities XP gives them to do this kind of long-term planning, but that doesn’t mean it’s not there. I’ve used it in projects and it works.
Perhaps part of the issue is that it’s not available from the start of a project or the start of your use of this style of planning. Every project is different and you have to both build up a history of estimation and have the wit and social ability to use that history for realistic assessments rather than trying to make things look good.
LikeLike
Never red the book, you surely know more details than me. I personally recall XP for pushing the development practices like testing and tooling that were almost non existent decades ago.
I have helped a lot of projects with planning. There was a time in a consulting shop where we specialized in selling groups of 2-4 people to 6 months projects. Then later in government projects where the guy next to me was doing the proposals for 1-10M€ projects in the order of years.
It looks like we are in solid agreement. The lists of tasks will only get as far as a quarterly cycle. That’s not long term planning.
Long term planning (beyond a few months) is a different beast than 2 months planning. If you plan 6 months ahead like you plan 2, you gonna realize on the last month that everyone had one month of holiday to take and they’re all away. Talk in years and people who finish the projects will not the same as who started it.
LikeLike
Well, XP does have long-term planning in the sense that you do always have in mind your (current) general goals for one, two, five years down the road. But it also strongly suggests that you should not be creating specific stories for a developer to spend a week working on at this time next year. That’s generally wasted planning in most projects because by the time you get even half way there the story will have changed and your estimate will certainly have changed.
I’ve never seen any methodology that can schedule a year in advance tasks on the order of 1-programmer-week. Software (unlike, say, building buildings or bridges) just doesn’t work that way for most business applications. XP just admits that and says, “don’t try to do too much planning with too little information.” But it doesn’t say, “don’t plan that at all.” Just plan it at a much higher level.
LikeLike