What the heck is up with all the rants around Scrum and Kanban (and Agile in general)? I know, it’s a fading fad, but really, is all the bias and negativity necessary?

Who fights whom?

I chose my words carefully. Not just lately, an endless fight is emerging, and people are squabbling over semantics, technicalities and bask in their own ignorance. But do the agile enthusiasts and evangelists fight the PMA/I or V-Model crowds? No, the quarrel is endlessly growing between different movements that are based on the same ideas: the agile manifesto.

With seemingly endless energy people do all but stop short of denigrating, namecalling and simple misrepresenting others or ideas that differ from their own experiences.

What’s the goal?

I actually have no idea. I just can assume that people are trying to make themselves heard in order to enable others to share their opinion. This is at least how I would like to do it. Though I fear that a lot of people who are posting do have less lofty goals in mind. Usually people ranting and raving about “the other” methods (and methodologies) seem to be consultants, trainers or somehow part of an organization that tries to generate revenue by jumping on the agile train.

So, lofty goals or just plain trying to bang up the buck? Decide for yourselves.

What’s all the fuzz about?

For me it seems that mostly lately people accuse each other of using the “wrong” methodology. TDD vs BDD, Scrum vs Kanban, the list is as endless as the discussions are. I want to dissect a few argument chains now and underline the points that aggravate me:

Scrum is bad, Kanban is better

There is nothing like that. There are situations where Scrum is more easy applied than Kanban, and vice versa. Having a tight knit team and a struggling organization can be as easily solved by either as having a dysfunctional team and a strong organization. The approach though is very different, and it depends on the individuals involved as well as the current mood and structure of team and organization as to which methodology can be applied more easily.

Some organizations need to be shocked into awareness and collaboration: Scrum can help there. Some organizations need to be eased into change: Kanban might be the better choice.

All in all, use what works better and what people can accept at the moment. Don’t be afraid of changing the decision after a while.

“We are a (Scrum|Kanban) company” is pure poison. It limits the choices as much as an “We are an (IBM|MS) shop” or “We program only in (C++|Java|Python|Ruby)”. Don’t go there. It’s much harder to come back from that later. Say “We are using whatever the people and situation demands”. Repeat it 300 times. Go to sleep. Dream well.

Kanban cannot increase productivity as Scrum can

Who says that? A few disgruntled people that have ben rubbed the wrong way? Cassandras that seemingly fight against an onslaught of ignorance emanating from the rest of the world? From my experience it’s two groups: developers which have been badly burnt by well-meaning and worse-doing consultants or Kanban enthusiasts that take the enthusiasm a bit too far. The latter usually spew lines of “Scrum is too restrictive” or “timeboxing is bad” without showing the least understanding of the “Why?”. The former are to pity - they fell into exactly the trap that the consultants laid out for their bosses (and their money). Those consultants smear honey in form of “increased productivitiy” and “diminishing costs” around the deciders’ mouths.

What then happens is pretty typical: because of the motivation of change and the promise of a better future, the team and lots of others in the organization work more. Thus the productivity increases by staggering numbers, even factors. And when the people are dropping like flies after being burnt out, the consultant has already received his money and moved on …

Note: Increased productivity is and never has been a goal of agile development, nor is it part of the agile manifesto. It is a welcome side-effect if all the issues that kept the team from performing has been removed or can be controlled by the agile method applied. Every consultant that promises increased productivity by any agile method being more than marginal from the beginning is a charlatan, a snake oil seller of the worst kind and should be tarred, feathered and flogged beyond the city limits.

Kanban is scientifically based, Scrum is not

That’s actually brilliant: a hard selling point. But if you happen to be close enough, you will see one thing: Most companies who claim to use Kanban are not using one of the proclaimed scientific methods to be able to have sustainability and measureability. At least not longer as their current Kanban consultant forces them to do it. Rarely people understand the value and gain of perpetual, scientific measurements, analysis and reporting. So they don’t do it. What’s left? Daily Standups (that are not even part of Kanban as a methodology) a board, and WIP limits (that are circumvented more often than not).

And what’s left over of Scrum after a while: Daily Standups, a board and estimates (if even). Sounds familiar, does it?

Timeboxing is bad, Kanban has no such limits

First: timeboxing, judiciously applied, can be a life saver. Timeboxing also means: partitionate your work into manageable bits which can fit into the selected timebox. Have clear goals and committments before you start to work. It does not mean that you have to cram everything remotely related to the current problem into the available timeslot.

An example? Sure: various teams use the “timebox” of a standup meeting as a means to curtail discussions and complaints. If the allotted time has run out, further input is strongly discouraged and sometimes even prohibited. For us, it was way more useful to do what Scrum (and others) suggest: our Daily Standup has the goal to keep everyone informed of progress, problems and next efforts. We are doing it standing up and keep it as short as possible and within the team.

Every other problem is discussed afterwards. Often all team members and others of the company are involved, but even if we keep it short and in the same area than the standup, it is made clear that the standup is over at that point. Abundantly so. People who can or do not want to participate will leave. And at the beginning of that improptu discussion, two things are made clear again: the goals and the allotted time. As all meetings should be.

Kanban and Scrum may not be mixed

Who the fuck said that? Either again a money grubbing conslutant or someone who has no two brain cells to interact. At the very core of both of those methodologies is the feedback loop. Which is ideally an application of the Deming cycle.

Repeat with me: 1. Plan 2. Do 3. Check 4. Act

Go back to 1. and repeat again. And again. And again. Got that now?

So, what does that mean for mixing concepts? Please do it. If you need a WIP limit on any column of a scrum board - implement it. If you want to work more pull driven on your scrum board? Do it. If you want to note worked team hours on your scrum tasks? Do it already!

Don’t be fools, use all your tools.

In the end, every methodology is a tool. It’s never wrong to use them for the right purpose. If you use the right tool in the right environment, it will work. If you use the wrong … well, you get it.

You just have to know your tools, and mostly it seems that people don’t take the time or experiment enough to know the tools well enough to use them. This is dangerous in power tools as well as in agile tools.

Some postulate that using Scrum or Kanban should be done purely - don’t mix and match, don’t let other experiences distract you.

This is true. Especially when you or the organization is new to the whole thing, it will be good to have some standard literature to read up on, and experiences within known parameters to share with others. If you start to adapt early without really checking what and why you are adapting, the experiment has a big chance to fail horribly.

Some postulate that using Scrum and Kanban purely should be refrained from - pick the best from every method, and everything will just work!

This is also true. It does not hurt to adapt the methodology judiciously after knowing what and why to adapt. But just mixing and matching because you feel uncomfortable with some detail without investigating why you feel uncomfortable about it is against common sense.

Also, the things you can change with Kanban are very few: you can select what to measure and what to adapt to, which goals and warning limits you set - but after all, this is well within what Kanban is about.

With Scrum, it’s easier to break stuff - abolish meetings that would be necessary just because people don’t feel good about it, softening up sprints and sprint goals - that just points to underlying problems, and complying with that feeling will just bring those things to a grinding halt.

In the end, it’s like software testing: a little is better than nothing, but nothing can beat to use all of it.

And what about all the others that are saying that I am wrong?

You mean, all the others that are squabbling and loudmouthing instead of pursuing the common goal of creating better work environments and sustainable paces, as well as great and working products that do just what the customer needs?

Screw them. In the middle of your brain, you know better. Trust your feelings. And just do what you do best: deliver great products with the gut feeling that you do it the right way.