Best Agile Method For Your Team: Scrum Vs. Kanban

10 Productivity Tools To Help You Win At Work

These days, the decision to go Agile doesn't put a company in select company. It seems like just about every organization that's doing more than simply maintaining an existing IT platform has adopted some variety of the Agile philosophy. Once you decide to go Agile, though, you've still got to figure out precisely how you're going to put the Agile discipline into practice.

There are two main methods used to put Agile into practice: scrum and kanban. One comes from software development, while the other was born of just-in-time manufacturing needs. Before we look at each of them, there are a couple of things that you should know. The first is that both scrum and kanban are sets of principles and prescriptions rather than strict recipes. They are, in that respect, much more barbecue than baking. The second thing to know is that each of these methodologies is a response to an older methodology.

From the Ashes of a Waterfall

The waterfall methodology ruled enterprise development from the 1950s until relatively recent times. It is, in most respects, the process for developing software that we learned at university. It's a linear, rigid, methodology that lends itself to strict rules and deadlines. It has been thoroughly documented and automated. On the other hand, the rigid nature means that changes to the specs are difficult after they've been established, and the opportunities to involve shareholders in the development process are few.

Agile is a response to the rigid nature of the waterfall model. Scrum and kanban provide options for putting Agile into place that differ depending on precisely what you hope adopting Agile will help your organization accomplish. Let's take a quick look at the strengths and challenges of each, and how each can help an organization solve development problems.

Scrum's Organized Uncertainty

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. During the sprint, the precise details of the features expected can change multiple times. It's rare for the delivered set of features and functions to be unchanged from those at the beginning of the sprint.

The specifics of features can change because scrum development allows lots of chances for "stakeholders" (read: users, customers, and management) to review what has been done, provide feedback, and offer suggestions on changes in the path. These people also offer input on priorities among the features and functions, because in scrums the end of the sprint is sacrosanct. If things get tight, the question is: Which features and updates must be moved into the next sprint?

Scrum methodology is based around the sprint.

There is always a next sprint. Agile methodology is one of constant change and improvement. One of the most strident complaints made by waterfall stalwarts against agile methods is that air of constant change. Backend systems that must be rock-solid on the reliability front are seen by those stalwarts as poor candidates for constant improvement. Of course, there are options for those who want the agile philosophy without the rapid-fire baggage of scrums.

Just-In-Time Development

Toyota is famous for its "just-in-time" manufacturing, in which parts are delivered to the factory as they're needed, rather than stored at the factory in anticipation of need. Half a decade ago, Corey Ladas and David Anderson began applying the principles of just-in-time to software development in methods they called scrumban and kanban, respectively.

[See 10 Tools to Keep Your Agile Dev Projects on Track.]

Both of these methods have several key principles: Each is based on visual management tools that let everyone on the team know the status of each project component; each uses the visual tool to show where bottlenecks or obstacles have formed; and each places great emphasis on not overloading any single member of the team. Scrumban is seen as a method that can allow teams to transition from scrums to kanban, while kanban is a no-apologies just-in-time methodology.

Kanban is a visual management process for agile and other philosophies.

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.

Agile is a philosophy that tends to take over and transform the organizations that embrace it. The method you choose to bring Agile to life will go a long way toward determining whether that embrace is warm or at arm's length.

Rising stars wanted. Are you an IT professional under age 30 who's making a major contribution to the field? Do you know someone who fits that description? Submit your entry now for InformationWeek's Pearl Award. Full details and a submission form can be found here.