I like presenting. I just love the fact that every time I deliver the presentation I find something new in there. It’s like having tiny epiphanies while you’re talking to a crowd. And I’m sure I wouldn’t have them if I didn’t overcome my fears and didn’t start speaking publicly.
A thing which hit me last time I was delivering my Kanban Story presentation was how fragile agile is in terms of people who don’t give a damn. In the summary of presentation I make a point that Kanban may not be for your team if you work with undisciplined engineers.
But what I realized while I was talking it is not only about lack of discipline. It’s about care. In Kanban people have to care about Kanban board. They have to move cards as they progress with features. They can’t abuse limits unless it is agreed among the team and team rules allow to. They should think how they could improve the board. They should keep the board up to date.
Why it is so important? Because the board is single most important information radiator in Kanban teams. If contents of Kanban board are random you spread random information about project among the team and outside the team. You pretty much misinform everyone around. And now the important thing:
In Kanban teams anyone can easily abuse Kanban board.
It’s enough someone doesn’t care. He doesn’t care to move cards through the board or put his marker on task he’s working on at the moment or ignore transition criteria or whatever. Suddenly you have random Kanban board and no systemic tools to deal with the issue. People versus Kanban 1:0 at halftime. If you want to know how the match ends, well, you’ll have to read the blog in future since it is a subject for another post.
It’s already half of A4 page and I haven’t really mentioned agile in general. Only Kanban. Kanban this and Kanban that. Don’t I have something else to say? Well, I do, thanks for bearing with me so far.
One of reasons why Kanban is so easily abused by people who don’t give a damn is the fact that Kanban prescribes close to nothing. But enough of K-word. Scrum is more formal. Actually Scrum is pretty formal approach if you ask me. How it deals with the problem?
A bit better. Stand-ups, time-boxing and planning meetings are all practices which help to deal with undisciplined team members. (I wanted to write “engineers” instead of “team members” but I’ve just recalled there are no roles in Scrum besides Scrum Master, Product Owner and Team Member and I prefer not to be killed by some Scrum extremist.) With these practices it is easier to make someone stick to convert folks who don’t care. If you work with Scrum you can’t work without time-boxing while the rest of the team has 2-week long sprints. You are asked the same questions as everyone else during stand-ups. There is more of a stick in Scrum than in Kanban. (Have I just said K-word?)
XP goes even further. Rules are surrounding you everywhere, my poor engineer. It almost tells you how to pee. Not in pairs. fortunately If you work with XP and you don’t give a damn you’re probably already fired.
But let’s face it – how many teams out there use eXtreme Programming religiously? Few. More of them follow just a couple of engineering techniques choosing Scrum as their process base. And even then we have whole variety of Scrumbuts, Scrumbans and Scrumwhatevers.
Average agile approach in real world, if there happen to be something like that, would cover a very limited number of rules. I’d say that there would be less of them than Scrum proposes. And even then rules are often softened or teams choose those which are less painful to adapt.
So we come back to the first point. The fewer constraints (aka enforced practices) we have in place the more easily our process can be abused by people who don’t give a damn. If your method base on a lot of common understanding instead of tons of process documentations and a number of strict rules buying all people in becomes crucial. Having few rules means that you give people power to create and adjust your software development/project management approach.
It also means you give them power to destroy and harm it.
If you like this post you should thank Michal who took the discussion up on Twitter.
Subscribe RSS feed
Follow on Twitter
Subscribe by email
8 comments… add one
Great article thanks Pawel.
I have long believed that there is a reason why SCRUM has achieved the level of penetration that it has (anyone seen an actual measurement on this?). It has a good balance of structure and freedom. The reality is that most engineers need a bit of both in order to deliver maximum value.
I once worked with an engineer who claimed to be 28x faster than the average engineer (at least when he was younger). I have no idea if he had a formal method of measurement, but I would tend to believe him after watching him work; best as a lone wolf, no systems or structure to tie him down, and no team to hold him back. Pure natural talent, skill, and experience propelled him forward in way that was seldom matched. Of course, it was virtually impossible to get transparency into how he was doing or how he did it, but when he said it would be done, it was.
It is pretty tough to scale a business based on the 28x’ers. The bulk of us range from mediocre to above average. Implementations of agile as “kanban” tend to strip away many of the things that make the bulk of engineers produce predictable speed and quality of code. If you strip the structure away, expect most teams to drift into a bad place over time.
Russ,
Yes, Kanban doesn’t enforce much of structure on team. But on the other hand it doesn’t forbids you to build the structure nevertheless. You can’t look at Kanban only through things which Kanban prescribes. It doesn’t say a word about software development practices. But so does Scrum.
Consider this example: you work with a bunch of crappy but disciplined engineers. I mean they produce low quality code but they don’t tend to ignore the rules. Now, take this team and implement there Scrum by the book. What you’re going to get is structured way of delivering crap.
Yes, you can do more, invite good engineering practices etc. But Scrum doesn’t prescribe it. The same is with Kanban. Kanban alone is not enough so you basically have to base on other techniques practices as well.
But coming back to the point – your 28x engineer could blow the agile process up if he didn’t follow a few rules which are agreed among the team. It doesn’t really matter if he ignored Kanban board, time-boxing or planning meetings. As long as his work was completely unpredictable and no one else could say what is he doing right now without getting the guy out of his flow it wouldn’t work well.
On the other hand the guy should work better in less structured approaches, so for example as long as he would keep the Kanban board up to date he shouldn’t be much of trouble in Kanban team. And he would definitely appreciate huge freedom he would get.
It works as general rule by the way. If you don’t break the rules but you use as much freedom as you have no one should complain. If you break rules by default you’re considered as prima donna and treated like a black sheep.
Good article!
A note on your “I wanted to write engineer”-comment:
I’ve actually seen Kanban (and partly Scrum) crash and burn more often because project managers have broken the WIP limits and impeded the flow, in their search for squeezing out the last drops of imagined effectivity by parallelizing the team – thus destroying the actual effectivity by paralyzing the team.
Christian,
If one’s goal is to organize the process in a way which squeezes most out of the team it just can’t succeed. It doesn’t really matter if we discuss Scrum, Kanban or one of more structured approach. Limits in Kanban are not for making people run faster. And cutting them beyond reasonable level results in decreased productivity.
By the way if limits become a pain in the neck and you face bottlenecks every week or so it’s likely that limits are broken, not the team.
“…I prefer not to be killed by some Scrum extremist…” so Pawel isn’t immune to people who care too much also ;-)
Now to your post… exactly, so staying in K-Wold with the few rules, there should also be one added: “thou shalt be caring” or not be part of the team
K-World :-)
Vicky,
I think “thou shalt care” should be the rule in every great team, no matter which approach you choose to deal with software development or project management.
But the truth is the more authority you deal among team the more you’re fragile to those who don’t care. It looks like I choose very flexible approaches and tend to work people who care for the same reasons.