This article was originally published on the DZone Agile Spotlight blog as part of the DZone Bounty competition.
Scrum and Kanban are but two out of many Agile methods currently in practice. They are both completely different in implementation but have fundamental similarities. Here we explore the differences, the similarities, and how they relate to other Agile Methods.
Scrum
Scrum, developed by both Ken Schwaber and Jeff Sutherland was introduced to the world in 1996. The inspiration of which was Jeff’s time as a fighter pilot in Vietnam, an article in the Harvard business review, and basic observations on how people actually work to get things done. Not the processes that are enforced that tend to both manage how the work is done and actually slow down progress.
Scrum got its name from a rugby scrum where teams huddle together to try to get the ball.
Given that Scrum was introduced in 1996, and in development much sooner than that, it predates the Agile Manifesto by at least 5 years. This means that Scrum helped influence the Agile Manifesto. Not the other way around. In fact, Jeff and Ken were one of the original founders.
Scrum is a cyclic framework that tries to solve problems and accomplish goals through experimentation. The Scrum “process” starts with a planning session, where the Scrum team plans the experiment. The Scrum team consists of the Scrum Master, who makes sure that the Scrum process is followed; he role is required to prevent reversion to old habits. There’s also a product owner, the person who holds the vision of what the team tries to accomplish. And, finally, the development team. Not developers in the software development sense, but developers in the product sense. In other words, the software developers, testers, architects, etc.
Then, during an iteration, i.e. a period of work, of between 1 week and 1 month – usually 2 weeks – known as a “Sprint,” the development progresses. Teams hold a daily, 15 minute meeting between to plan each day’s activities. The experiment is to try a better way of working, it is executed by, well, doing the work. At the end of the iteration, the stakeholders review the work done to make sure it meets what they require, and the team then reviews how the actual experiment did and then determine the next experiment. Whether it is a modification of the current experiment or a new experiment.
I’ve highly simplified and modified the description of Scrum here, but I wanted to show that there is a process to how Scrum works.
Kanban
Kanban was created by David Anderson and was released to the world through David’s book “Kanban: Successful Evolutionary Change for Your Technology Business” in 2010.
Kanban is a Japanese word that means signboard. The system has its roots in the Kanban cards used by Toyota to indicate when components on the assembly line of car manufacturing need to be replenished.
When an assembly line worker runs out of bolts on the line, for example, a Kanban card attached to the bin is taken and brought back to the factory store, where it triggers the replenishment to the assembly line worker. Another Kanban card which was attached to the replenishment triggers an order from the supplier, who then replenishes the factory store. The system is designed so that only when parts are used are they replenished. The system is a pull system where the use of a component triggers the pull of additional resources for replenishment.
The Kanban system works in a similar way. The Kanban cards here represent the work being done as opposed to components. The cards are then pulled from one process to another. The other component of Kanban is the visualization of the work being done. This usually takes the form of a board with the columns labeled: to-do, in process, done.
Kanban, unlike Scrum, is not process driven. Also, the starting point of Kanban is actually to start with the way you work at the moment, whereas Scrum completely changes the way you work.
So with Kanban, you visualize how you work and the different stages the work goes through, via the Kanban board. You have your Kanban cards that represent the work and then move the cards as the work progresses through each stage.
Very simple, but this is the easy bit. This is also the point where many implementations of Kanban stop.
The hard bit of Kanban is to track and monitor the progress of cards across the board. This includes the determination of bottlenecks – where cards bunch up – and determining the overall time a single card needs to progress across the board, recording both the time the card is actively worked on and the time it is idle.
Then, using various techniques and experimentation, you continuously try to improve the flow of cards.
As you can see, Scrum and Kanban, although completely different, do have some fundamental similarities. These being that, through experimentation, you continuously try to improve how you work.
The strange thing is that practices from one method start leaking into the other. You would be hard pressed to see a Scrum implementation that doesn’t have a Kanban board (either physical or virtual) to see how work flows through their team.
With Kanban implementations, you may see teams do regular reviews every couple of weeks. They may do daily stand up meetings to plan the day’s work. Some even have a single person who is in charge of the backlog of work. They may even be called the “Product Owner.”
These methods are different to Waterfall, which is very process driven. Follow the process ad infinitum to do the work. Everything is determined up front, there is no change during the process, and no review, at least not until the end of the project.
Everything Else
The similarities between agile methods are not just common to Scrum and Kanban but are actually fundamental to most Agile implementations (of which there are many). Craig Smith has a great presentation on 40 Agile Methods in 40 minutes – and this is still only a small portion of the number of Agile methods out there! Many of these methods vary on the degree of process, for example, XP has practices including Test Driven Development and Pair Programming, among others. While others such as DevOps and SAFe (Scaled Agile Framework) have a basis in other Agile methodologies, but expand on them.
Just like between Scrum and Kanban, practices in Agile methods bleed into one another. Test Driven Development, User Stories, Continuous Integration, and even pair programming from XP are pretty standard practices regardless of which Agile method has been adopted.
Lean software deals with the elimination of both wasted effort and time and is resource based. DevOps deals with automation. These are both ways of improvement adopted by agile development teams.
Those methods that do not have these fundamentals tend to have no benefits other than making the company “feel” like they are doing Agile.
Now, it doesn’t matter which methodology you choose, or if you make your own. What is important is that you have the fundamentals of Continuous Improvement through experimentation and actually reviewing the experiments. This is known as the Agile Mindset.
The Agile Mindset requires that you actively try to continuously improve and that you verify that improvement.
The various methods, be it Scrum, Kanban, or something else, are but methods to help implement the Agile Mindset. Without the Agile Mindset, no matter what method you choose, you are most likely to fail in the long term.
For more information on the Agile Mindset, I suggest searching for “Linda Rising Agile Mindset.” Linda has done a number of lectures on the Agile Mindset which is heavily based on Carol Dweck’s book “Mindset,” which looks at the difference between the “Growth” mindset and the “Fixed” mindset.