David Joyce shared a short story on Twitter how a team was told by a coach to switch from Kanban to Scrum and they eventually got back to what they’d had initially. It seemed to that the team had been operating pretty well in the first place so I was curious why they were told to change.
It seems that coach’s argument was that they weren’t agile.
Ouch.
I think I should start with a few disclaimers. Yes, you can officially consider me a Kanban proponent. No, I don’t think that Kanban, in general, is superior to Scrum (or any other specific approach). Yes, I like Scrum and witnessed it working very well for some teams. No, I don’t think that Scrum, in general, is superior to Kanban (or any other specific approach).
I do however have problem with people selling agile, or any other approach, as it was the one and the only revealed truth. I do have problem with people selling agile as the way of life. I do have a general problem with any orthodox folks out there selling their snake oil.
The problem is there are more and more such people. Agile is already a business. Scrum is a business as well. Soon Kanban will be business too. This means there is plenty of people who are selling ready-to-apply solutions without even thinking how they might be used in a given environment. Or whether they are applicable at all.
You should avoid these people. The problem isn’t that they aren’t helping. It’s even worse. They are actively harming your team.
One theme which often comes to me whenever I’m working with different teams or preaching agile or lean is that not only should you learn the method of your choice, but also understand why it works. “Whys” are crucial here.
If you understand why a specific practice or rule is there you can fine-tune it in a way that doesn’t harm the team, or substitute it with other technique which covers with the same gap. Otherwise it’s just following the book.
Now, it’s perfectly fair to follow the book if you and your team aren’t experienced with different methods and don’t have answers for all the whys at hand. However, if we take coaches, people who earn money teaching us, it is their freaking duty to understand how, why and where tools they sell happen to work.
Otherwise they are like the coach from David’s story. Selling his snake oil with bullshit arguments like “it isn’t agile.” Well, I’m not agile, so what? Would my customers pay me even a buck for being so? I thought they were paying me for software I build and using this or that method is reasonable if and only if it can help me to be more effective.
When I see snake oil salesmen I’m sad. I’m even sadder when I see people buying their snake oil. If we can do anything about this, we can try to reach as wide audience as possible with our message. Avoid orthodoxy. Avoid people who have the same answer for every problem. Avoid those who can’t answer your whys. And don’t be afraid to call bullshit.
Subscribe RSS feed
Follow on Twitter
Subscribe by email
9 comments… add one
Awesome. Thank you:-)
Seen that so many times… And it’s especially sad that these people tend to not realise the harm they’re doing…
Take care
Olaf
You could have written this article and not included any of the Scrum vs Kanban rhetoric. Sadly, by trying to go out of your way to explain the processes and your neutrality, you probably made half the readers ignore an other wise valid and well written article.
We have to stop sabotaging ourself as a community. The best way to do that is stop talking process and keep it focused on principles, values, people and the interactions between them. Again the second half of this article did that well.
@Derek – Thanks for your feedback. I started with Scrum vs Kanban rhetoric as such story was inspiration for me to write the post. But it was just that: a starting point. I do consider problem broadly and not limit it to this method versus that method issue only.
At the same time I can’t deny that agile methods are my context and I don’t want to avoid this context at all cost. After all this is what I know, this what I feel knowledgeable about. If you asked me whether we face the same issue with, say, project management in construction industry I would guess that it’s exactly the same there, but it would only be a guess. I wouldn’t be so definite.
Either way I will remember your advice. Thanks for that.
Focus breeds narrow-mindedness?
This reminded me of various psychological schools from the past – claiming, in turn, to have a better understanding of the human mind. We are likely to spend a big deal of our energy striving to find applications and proofs of whatever concept we contributed to developing (or believe in, for that matter).
So… once you decide to stop writing about Kanban, what will that be, Pawel?
@Lech – I’d say that’s a pretty damn good question to answer. And the one everyone who is writing about any concept or idea should ask themselves.
In my case, I believe I do have a decent answer. Or a couple of them. One thing which is true for this blog all the time, since its very beginning back in 2006 is that I write about whatever is happening around me in my professional life. There was time when I was more into formalized methods, now I am one of Kanban loudmouths. What will be next? We’ll see, but it will be happening all around me, that’s for sure.
Another answer is that I actually do control “what is happening around me in my professional life” and usually make decisions in this area in rather conscious way. I think I couldn’t be called Scrum proponent ever in my career. For some reasons, even when Scrum was The Next Big Thing, the method didn’t appeal to me to the point where I start evangelizing it.
It happened with Kanban and I’m pretty aware of reasons why it was so. Kanban addressed the problem I had with many methods – it allowed me to fine tune itself to my current environment and not the other way around.
So what will be the next thing to write about when I grow weary with Kanban? I don’t know but you can safely assume it will be flexible and it will be about improving the way we work. After all it is the goal I pursue since I first learned that you can’t apply one treatment to cure all the diseases.
We completely agree. Our view is that one always has to be pragmatic: throwing a textbook at something never works, as coaches we need to figure out the actual context we’re working in and adjust principles and paradigm to fit that context.
Great post. I have written much along the same lines.
Ultimately if people know what they are doing, they won’t need a scripted process, and if they don’t, such process won’t help them.
Meantime, the Agile Movement has become and still is a massive profiteering machine. We need more people to speak out against it.
Jordan
@Jordan – I would put it in other words: instead of taking care of this or that movement we should promote healthy, down to earth approach. This way we are actively helping or at least give teams a chance to get helped. They can refuse of course, but that’s a completely different story.
Btw: It seems that understanding the methods you’re using has become sort of leitmotif here recently.
I’ve explained several times that I use a basic incremental approach… Are there links to this discussion on this site? I’d be curious…
I don’t particularly want to tell people what MY approach is, because it doesn’t matter. I’m not trying to get people to adopt MY approach. I’m trying to get people to think for themselves.
Me spoonfeeding people MY approach is contrary to my goal of getting people to think for themselves. Most of the people who ask don’t really care what my approach is, they just try to use that as a club to prevent me of being critical of agile. (Yet another antipattern)
Jordan