What are the differences/similarities between Kanban and Scrum?

Scrum and Kanban are not necessarily that much different, provided that Kanban usually builds on the top of an existing framework, which is generally Scrum. If, however,  we really want to compare the two methodologies, the final conclusion is: Kanban is less prescriptive, Scrum is more prescriptive.

Kanban, according to the inventor, David Andersson (http://www.djaa.com/principles-kanban-method-0), defines five principles:

  1. Visualize workflow: usually, a Kanban board is a physical one, with index cards attached on it, where a card represents a task to do. This has to be visible to everyone so nobody will forget about updating the board, and it is generally easy to see the snapshot of the progress.
  2. Limit WIP: every single column has to be limited, so the burden is less. Limited WIP will makes sure the team is focused on a small number of tasks. It also makes sure the tasks will be pulled through the board as soon as possible, otherwise leftover cards can block the whole system.
  3. Manage flow: index cards travel one direction only: from left to right. Tasks are never moved backward, as that would be considered wasted work, which is a thing to be eliminated in Kanban.
  4. Make rules explicit: All the team rules have to be attached somewhere on the board, so nobody breaks them, and it is clear to everyone.
  5. Improve collaboratively: come together and improve the process as a team.

Scrum is more prescriptive than this: it prescribes roles, meetings, and artifacts. As can be seen from the list above, Kanban does not have any roles or meetings defined. It does not prohibit roles, meetings or artifacts, it allows everything that makes productivity greater. Kanban focuses on small numbers of tasks pulled through the board as soon as possible, without any kind of ceremony (in a very pure Kanban system).

Scum dictates the presence of a burn down chart in order to measure velocity. Kanban does not prescribe any such means of measurement, but it usually measures lead time (medium time for tasks to travel through the system) and cumulative flow diagrams (one diagram that captures the sequence of system snapshots until the current day).

Scrum prescribes meetings such daily scrum, retrospective meeting, demos, sprint plannings, etc. In Kanban, there are no compulsory meetings, but since Kanban usually is built atop Scrum, it may borrow most or all of these meetings.

Scrum believes in the presence of sprints, which is considered the unit of time. Kanban can be seen as holding mini-sprints of one day. Because of that, Kanban is more flexible and can adapt better, as such teams can focus on the most important items all the time. Scrum teams have to wait two weeks to change direction, which, at times can be too long – for example in the case of fixing critical bugs.

Scrum boards usually are erased and reset at the end of each iteration, while Kanban board is a continuous entity, which rarely needs erasures.


How does Scrum fit with the concept of Agile ?

In order to see how Scrum fits the Agile model, let’s take a look at the Agile Manifesto and Scrum’s view on those values:
Individuals and interactions over processes and tools: Scrum does not believe in over-engineering the process. Although it has some prescriptions when it comes to roles (Scrum Master, Product Owner, team), meetings (daily scrum, retrospectives, demos, etc.) and artifacts (e.g. burndown charts), there is no detailed documentation, no project plans, no incredibly detailed processes to follow, no extensive description of project roles. Scrum does not need detailed descriptions like RUP or Prince2, it is kept extremely simple. Scrum is a rather minimalistic approach, the absolute basics are given, anything still needed can be added later.

Working software over comprehensive documentation: Scrum targets this principle with the combination of sprints and demonstrations. Sprints are small size iterations, which are still long enough to deliver features, customer value. These features are then later demonstrated during a meeting at the end of the sprint. The audience of this session always contains the product owner, and possibly end users too. The reason behind these sessions is that the product owner to accept the delivery, or suggest changes to be incorporated. Every two weeks (the usual length of a sprint) some working software is delivered, so customers can start using the product right away. Documentation is usually ad-hoc in real life Scrum implementations, and entails a number of wiki pages most of the time.

Customer collaboration over contract negotiation: As mentioned earlier, in an ideal Scrum setup, the customer attends the demos so they can see for themselves what the next release of the software contains. Also, the product backlog represents a list of customer requirements. Such a way, Scrum delivers value based on customer requirements with the approval of the client at the end of the sprint.

Responding to change over following a plan: Scrum leaves room for team improvement with the retrospectives. Retrospectives are meant for teams to come together, revise their process and experiment with new things. Scrum is flexible: sprint lengths are not set in stone, project roles can be added if the situation requires it, meetings can be organized for better performance. With the retrospective, the team is able to adapt to the current situation and respond to changes in customer requirements, competitors’ movements, product success, etc.

Based on the four values of the Agile Manifesto, Scrum is fully qualified as an Agile process. All the principles in the manifesto are addressed, the primary goal is to deliver customer value and not to stick to a plan created upfront.

Is Prince2 an Agile or Traditional PM framework?

I think that Prince2 is definitely a traditional, sequential project management framework. It believes in lots of documentation, very rigid boundaries between project phases, really formal procedures in handing over work, managing the developers closely and monitoring and controlling.

I really see no flexibility or adaptability in the process once the project starts. Before any work is done, there is a way to tailor the Prince2 ways of working to suit the project’s need, but in my opinion, that’s a too early stage to know what is going to work for a particular project.

Although Prince2 has a notion of iterative development through the concepts of “Next Stage,” this is not flexible enough to be considered agile. At the boundary of a stage, project plans are updated, end stage report and next stage plans have to be created, which entails a lot of documentation. This is very far away from Agile’s “barely enough” view on creating documents and plans.

Instead of adaptation, the Prince2 way believes in monitoring and controlling. The execution of the plan has to be carefully monitored, and once deviations are experienced, they have to be addressed using corrective measures. In an Agile view, in such situations adaptation is needed, flexibility in the process and not blindly trying to stick to a plan created up front.

Again, like in traditional project management methods, customers, end users are not addressed. The goal is to stick to the plan, deliver what was expected within time and budget. Values, as such are not mentioned, and it is outside of the scope of this method to measure how useful the product is.

If we contrast Prince2 to the Agile Manifesto, we can see that most of the Agile values are not addressed in Prince2:

  • Individuals and interactions over processes and tools: Prince2 is a comprehensive process, where interactions usually happen in a very ceremonial way, e.g. request to initiate or deliver a project.
  • Working software over comprehensive documentation: lots of documentation at every phase of the project lifecycle
  • Customer collaboration over contract negotiation: not exactly addressed
  • Responding to change over following a plan: stick to the plan, monitor progress and apply corrective measures if necessary

Because of these features, I really think Prince2 does not qualify as an Agile project management process.

How to transform Waterfall into a modern development model

I think it is very hard (nearly impossible) to transform Waterfall, so it meets nowadays’ software development requirements. However, as a quick thing, the excessive documentations should be removed. As Royce mentioned in describing the Waterfall model, he’d expect 1500 pages of documentation for a 5 million dollar project. WhatsApp was a 20 billion dollars project, so I’m pretty sure nobody would have read the 6 million pages long documentation. So step 1, limit the documentation to a reasonable level.

Coding and testing should never be separated in two different steps. That would partially imply that developers are not writing any unit tests, and all the bugs ranging from trivial to blocker are discovered once the full coding part is done. This implies going back to coding and then testing again, which can be a waste of time. Coding and testing shall be kept together, so as the project progresses, parts getting done are validated in one go.

Today’s market is so volatile that the full project just cannot be designed up front. Smaller units, like features, maybe could be designed very well before starting the coding phase, so the process could be broken down into delivering features (we are getting closer and closer to what we call Agile software development). At most one feature would be analyzed , designed and built at a time, and the whole project would entail several mini waterfall cycles, packed back to back.

These new features, however, would still not make the waterfall process capable of handling all kinds of software development efforts. I am pretty sure that for Facebook or Amazon these continuous waterfall cycles would not be flexible enough to roll out new features to an extreme number of customers. This new, improved waterfall would still only be suited for short to medium timescale projects. Due to breaking the software down into distinct features, more projects could benefit from the waterfall model, but larger projects still don’t qualify.