Kanban vs. Scrum vs. Agile- Part 2: How to bring agile to your team?


In our previous post we described the difference and similarities between Kanban and Scrum, and addressed Kanban versus Agile.

Today we want to identify the best way to bring Agile to your team? (yes, Agile!)

And the answer really depends on the answer to another question - what do you want to transform within your organization?

There are many agile methods available these days. Yet, there are two main methods used to put agile into practice: Scrum and Kanban. One comes from product development, while the other was born of just-in-time manufacturing needs.

There are a few important considerations before we dive into this discussion. Both Scrum and Kanban are sets of principles and prescriptions rather than strict recipes. I agree with his definition that I recently came across: they are much more barbecue than baking.

Also, note that each of these methodologies is a response to an older methodology which no longer works with the current demands in the software industry. Referred to as the waterfall methodology, it ruled enterprise development from the 1950s until relatively recent times.

It's a linear, inflexible, methodology that lends itself to strict rules and deadlines. On the other hand, the inelastic nature means that changes to the requirements and specifications are difficult to accommodate once initial requirements have been established. It also creates a big disconnect between developers and other stakeholders during project delivery lifecycle.


Waterfall model

(Image: Peter Kemp / Paul Smith via Wikimedia Commons)



Agile is a response to the rigid nature of the waterfall model with scrum being one of the agile methodologies to achieve this. Scrum is an iterative and incremental agile software development framework for managing product development. Scrum was first defined as "a flexible, holistic product development strategy where a development team works as a unit to reach a common goal" as opposed to a "traditional, sequential approach" in 1986.

A key principle of Scrum is its recognition during production processes. Customers can change their minds about what they want and need, espcially in the event of unpredicted challenges which are otherwise difficult to address. As such, Scrum adopts an empirical approach—accepting that the problem cannot be fully understood or defined, focusing instead on maximizing the team's ability to deliver quickly, respond to emerging requirements, and adapt to evolving technologies and changes in market conditions.

The central principles of Scrum development are rapid iteration and constant communication within a relatively small time box. The time box is called a sprint, and a sprint rarely extends beyond 30 days and usually is two to three weeks in duration. During the sprint, the details of the features can change multiple times because Scrum development allows lots of chances from and for different "stakeholders" (read: users, customers, and management). These groups do a frequent review to what has been done, provide feedback, and offer suggestions on changes.  

Also, team members can now offer input on priorities versus the list of features to implement (a.k.a. backlog). It's rare to see that the delivered set of features and functions to be the same comparing to those at the beginning of the sprint.


The Scrum Process

There is always a next sprint. It’s vital to understand that any Agile methodology is about of constant change and improvement. One of the most vociferous complaints made by waterfall proponents against agile methods is about that constant and “endless” process of “changes”.


Kanban, which is another popular nowadays agile methodology, is based on the “Just-in-time” concept from Toyota. Just-in-time (JIT) manufacturing, also known as just-in-time production or the Toyota production system (TPS), is a methodology aimed primarily at reducing flow times within production as well as response times from suppliers and to customers. Following its origin and development in Japan, largely in the 1960s and 1970s and particularly at Toyota, JIT migrated to Western industry in the 1980s.

Kan-ban in Japanese literally means “signal card”. In a manufacturing this card is used as a signal to tell an upstream step in a process to produce more. The workers at each step in the process are not allowed to do work unless they are signaled with Kanban from downstream step.

The tool used to operate the Toyota Production System (or “Lean manufacturing”) is Kanban. Kanban is fundamental to kaizen (continuous improvement) process used at Toyota.

About a decade ago, Corey Ladas and David Anderson began applying the principles of just-in-time to software development in methods they called scrum-ban (“Lean”) and Kanban, respectively.

Visualization of the workflow is one of the main requirements of a Kanban implementation. Here's what Wikipedia says about it:

“The simplest Kanban system implementation consist of a "three-bin system" for the supplied parts, where there is no in-house manufacturing. … The bins usually have a removable card containing the product details and other relevant information—the classic kanban card.

When the bin on the factory floor is empty (because the parts in it were used up in a manufacturing process), the empty bin and its kanban card are returned to the factory store. The factory store replaces the empty bin on the factory floor with the full bin from the factory store, which also contains a kanban card. The factory store sends the empty bin with its kanban card to the supplier. The supplier's full product bin, with its kanban card, is delivered to the factory store; the supplier keeps the empty bin. This is the final step in the process. Thus, the process never runs out of product—and could be described as a closed loop, in that it provides the exact amount required, with only one spare bin so there is never oversupply. … A good kanban system calculates just enough kanban cards for each product. Most factories that use kanban use the coloured board system (heijunka box).”

The software development Kanban implementation usually also consists of three bins – “To do”, “In-Progress” and “Done”.

Interesting enough that the similar visual board is also used while practicing Scrum as well (JIRA boards as an example)


(Image: Kanban via Wikimedia Commons)

So, when do you use Scrum and when do you turn to Kanban? Is there a difference? As once been summarized by the Curtis Franklin Jr. who is an executive editor for technical content at InformationWeek -

“One of the key differences between Scrum and Kanban is that Kanban places the project and its needs at the heart of the process. In Scrum, the sprint and its time box is at the core. Kanban radically changes the way that projects are managed within the non-project environment of the organization, while Scrum is more appropriate for organizations in which development is constant rather than episodic.

So which is right for your team or company? It really depends on what problem you're trying to solve. Kanban is more linear. Scrums are intensely multi-threaded. Kanban looks at agile from the project perspective. Scrum assumes that work on products and systems never ends. The question in Scrum is what will be accomplished within the next sprint. Kanban fits easily within the traditional processes that already exist in most organizations. Scrum forces a different relationship between deadlines and tasks.”

Still puzzled with which one to choose and when? We will continue this discussion in our next blog.


Contact us

Topics: Tech Leadership