My session at GOTO Copenhagen was on Kanban improvements. My goal was to show the mechanics of improvements in teams adopting Kanban and you probably know me enough to know I wanted to build the session over real-life examples. Here is what I ended up with.

The result was a bunch of stories following similar pattern: we introduced Kanban, then some existing behaviors became visible and finally we started improving doing it either consciously or not. That was basically the point I thought about when I started building the presentation.

However when you think about it longer you notice that it’s not that simple. I mean the pattern itself is simple, but that’s not all. It’s just the tip of the iceberg.

Let’s take collective code ownership – one of my favorite examples. Consider you start with a typical situation where code ownership isn’t collective at all. You deal with bus factor of one and your life is miserable. Given that you adopt Kanban, your developers should start pulling different features to work on, not necessarily features which deal with the code written by themselves. They want it or not they have to start learning code written by others and knowledge is slowly spread among the team members. Eventually, after some time, the code is owned much more collectively than it used to be.

It’s a nice example. If we stop here it is still a nice story of improvement. But if you look a bit closer there’s much more than just that.

Let’s go back to developers pulling features from codebase they aren’t familiar with. A question: what do you think a decent developer will do in such situation? Probably they’re going to start with learning what a feature is all about. Then, and it now becomes interesting, they will start learning the code they will be changing and updating. This activity has even a name – code review. You may argue, but it actually is code review. It probably isn’t very formal but last time I checked you weren’t getting point for making code reviews as formal as possible.

It starts looking better, isn’t it? Let’s move to the next step then.

We have the situation where a decent developer is reviewing someone else’s code. I bet they spot some bad code out there. It’s kind of safe bet – we aren’t machines so we do make errors on occasions. What’s next? Well, one of ideas is to find the one who wrote that crap and make them fix it. Except it doesn’t work, because the author is either busy, already working on different project or left the company 3 months ago. It’s much more likely that the developer would improve the code by themselves. And you already have guessed – this one also has a name: refactoring.

It looks like it’s not only collective code ownership but we also get code reviews and more refactoring in the package.

That’s not all.

Look at the situation focusing on how it changes people. You teach them good practices and you do it by example. You don’t just try to convince the team that code reviews are good. You kind of trick people to actually start doing it. You give them a precious gem – real experience instead of just an opinion. You push people to learn.

Quite much of that already, but if you think I can’t draw another connection you’re wrong. This is the last one, I promise. At least for now.

Probably the best thing which happens here isn’t really about engineering practices. It isn’t about learning either – after all you shouldn’t need to push people to learn anyway. The best thing is you draw people out of their comfort zones on so many levels. They start working on unfamiliar code, they start using new practices, and they start learning new things. In terms of everyone’s personal development you couldn’t do them a better favor.

OK, now remind me where we have started. I believe it’s been drawing a connection between introducing Kanban and collective code ownership. How come we’ve gone that far?

This is exactly the surprising truth about Kanban improvements. There is no detailed plan of adopting specific practices or improving specific things. You just set the proper framework and let people figure out the rest.

I really like the metaphor David Anderson shared: it’s like organizing a good party. You bring food and beverages, you have music, you organize enough room to chat, eat, dance, etc. And most importantly you invite the right people. In details you don’t know what will happen. Your goal isn’t to plan everything to the last possible bit. You just create a framework for people to have fun.

Same applies to Kanban. It’s just a framework for people to improve. You bring your board and a bunch of simple rules. You show them the idea, but then it’s up to them where they’re going to take to whole thing.

You end up observing interesting connections between Kanban, collective code ownership, code reviews, refactoring, learning, moving people out of their comfort zones, etc. Continuous improvement in Kanban is rather a complex mechanism inside, yet it doesn’t mean it is hard to operate it. It kind of operates itself. And this is exactly the reason why it is so great.

It’s been some time from the previous chapter of the Kanban Story but it doesn’t mean we’ve stalled. There’s an interesting concept which I keep referring to but only recently realized I’d never really written about it.

The concept is called standard-sized features.

If you read about Kanban you just have to be familiar with the term Minimal Marketable Feature, which is a piece of functionality which is as small as possible, yet sellable to a potential customer. It is a very nice concept and that was exactly what we started with when we were adopting Kanban.

However, after some time we realized that we sacrificed marketability of our features in order to get them similar in size. This change wasn’t really planned. It just seemed more convenient on occasions to split the work that way.

It might be easier for us since we were never orthodox with MMFs. After all how could you possibly marked some architectural changes or rewriting one of integration interfaces from scratch? Anyway that wasn’t a reason to come up with standard-sized features (should I call them SSFs?)

SSFs were born because we needed to prepare some estimates for fixed price projects even though for most of these projects preparing estimates was the only activity we were performing. It is a kind of situation when you don’t really want to invest lots of time yet you still want to come up with some reasonable numbers in case you actually get the project and are expected to deliver it.

In such environment MMFs can be tricky. I can perfectly market a feature which consists like a couple dozen lines of code if it is the right code in the right place. On the other hand for some other features you may need tons of code until finally there is something which can possibly be sold to anyone, assuming that they’re partially crazy and would buy some half-baked functionality.

So yes, MMF can differ vastly in size. And this renders your average measures, like average cycle time, pretty much useless. If variation of cycle time is big so you may deliver it in 2 days but you can also deliver it in 2 months, depending on what kind of MMF it is, you can’t base on average or median. This way if you’re out of luck and get a bunch of huge MMFs you’re also totally screwed.

The answer can be SSF. With standard-sized features you don’t really care what you can market. Actually that’s probably not the case for majority of teams since we rarely directly sell our crap… I mean products. SSFs however allow you to deal neatly with estimation. You can use some simple methods to come up with a number which would go into a formal agreement like instantly, no matter how hard you try to explain a salesman what coarse-grained estimate really means.

Another nice trait of SSF is it helps make flow smoother. If feature’s size differs much you tend to have those big tasks hanging there for a longer time. It makes the team less flexible, as part of the team is dedicated to work on this specific task, and it consumes part of the limit for a longer time which may yield some blockers.

One of arguments against SSFs I heard is it’s pretty hard to learn how to get features standard-sized. Probably if you want to make them all delivered in 9 days sharp it is hard indeed. However you don’t aim for such accuracy. Variation between 6 and 12 days is completely enough. Anyway the surprising thing, at least for me, was we quickly became pretty good in splitting the work into standard-sized chunks of work. It looked like we didn’t even try and got it right, so we just kept doing the good job.

Standard-sized features proved to be valuable so you might consider them as one of options when deciding what exactly you want to have on your sticky notes you put on the Kanban board.

If you liked this story make sure you check the whole Kanban Story series.

Recently I came across a very interesting question on Project Management Stack Overflow. The question is how to organize project management in tiny projects, where everything is done by a single person or just a couple of them.

The interesting thing here is that when we think about the point where organization introduce formal PM role we usually see at least a few dozen people. So how about startups, where just a few people are working in the whole organization?

Let’s consider one-man project. I leave aside all tasks directly related with software development, so for the sake of this article I don’t care about version control or bug tracking. Which leaves us with a few of basic areas.

• Scope management

You actually need to know what you’re going to do. At least on general level. Actually in startups it’s not a good idea to have detailed plans of development since, well, what you start with is wrong and you’re going to change the course along the way. However if you don’t know, even roughly, where you’re going and you can hardly tell what is your goal then you might look for another project or another job instead because you’re not succeeding. So yes, a bit of scope management is crucial – you have to know that you’re building a tower and not, say, space ship.

• Task management

You already know where you generally are going. Good. Now you have to figure out the next step. Or the next feature you’re going to build. Then you build it. And you repeat the process. I mean from the point when you figure out the next step, not from setting the general direction. Of course you don’t have to be so short-sighted to plan only a feature ahead but you do need to break the scope down to smaller tasks and start building your tower brick after brick. And of course you need to know which brick goes first and which goes next.

• Product management

This is kind of tricky. Actually if you know the scope and you dealing well with tasks you pretty much have this one covered. Given that you’re building the right thing that is. Product management in such small project is all about making sure that you’re building the right thing. It’s not on brick level but you need something more than just a picture of tower pinned over your desk. You actually have to know that you want to keep bad people in hostage there so you need cells, torture chambers and such. Then you need to figure out how these things should work so clients… I mean hostages are served… I mean tortured well.

• Communication with users and/or clients

Finally, you need to verify whether your dream about best of the breed torture tower is something people actually want. You need to regularly confront your ideas with clients or users or both (depending on your target group) to make a sanity check: are we still going into the right direction. Yes, you need to talk with those tortured poor souls to learn whether they’re happy with the service. You might also check your butchers – they do use your product as well. If the tower isn’t ready, go find potential customers and potential users and get their feedback. Since you’re running one-man project you don’t have clearly defined requirements so this part is even more important than in typical projects.

Now, I’m well aware these areas aren’t strictly connected with project management as some corporate PMs out there know. In big teams PM can be isolated from product management and from end users, scope can be thrown at the project team in huge specification before the project starts, but well, we don’t discuss big teams working on boring BDUF project here, do we?

By the way PMSE (Project Management Stack Exchange) site is awesome not only in terms of inspiring blog posts. You will find there a lot of great stuff so what are you waiting for? Go check the site.

As you already know I’ve recently attended ACE Conference. By the way, if you missed the message the event was great. Anyway, the interesting thing about industry conferences is you can clearly see some cool phrases, buzzwords or examples. I was once on a conference where like every second presentation cited CHAOS Report to share the news: two third of features aren’t used.

Um, after third time it’s not much of a news anymore.

Anyway, one of few buzzwords I caught in Krakow was limiting Work In Progress. To be honest, I’m confused. Wasn’t it me, who told you to limit WIP in my Kanban presentation? Yup, it’s hard to deny. Am I on this damned limit-WIP-bandwagon then? Yup, it seems so. But why, oh why limiting WIP became a buzzword?

For some reasons we need them. I think we keep attaching those buzzwords to our messages for a very simple reason – they sell. They sell whatever we have for sale. So yes, we’ll be hearing a lot about limiting WIP these days. By the way, another such thing is system thinking which follows exactly the same pattern – every cool kid on the block will tell you about system thinking.

Despite the fact I hate one of my genuine messages became a buzzword, which makes it easier to be depreciated, there are some good points as well. No, I don’t think about being right a couple of years earlier than the rest of crowd. It definitely scratches my ego on the back but, well, my ego feels pretty comfortable anyway.

A good thing of some good concept becoming sort of buzzword is it reaches some ears much easier. There are people who won’t adopt good things unless they’re well-known. There are organizations which hate to experiment. I have a good news for you: now, you have an excuse guys. Everyone tells you that you should limit WIP. Hard to ignore that now, ah?

Unfortunately I know what happens then. The concept is being misused and abused and finally under the buzzword there’s hardly anything coherent. It’s like with agile. What does it mean when someone states they do agile (or are agile, for that matter)?

Basically nothing.

Unless you see how people work you can’t really say whether we discuss hard-core agile team which could serve as Scrum+XP implementation in Sevres or just the good old do-whatever kind of team which just wanted to get agile badge.

It will be the same with limiting WIP at some point of the time. But until then I’m going to enjoy being the part of buzz proponents.

So go, limit your WIP! Use Kanban! It is a goddamn silver bullet! It will make your team hyper-productive and will bring the peace to the world! And of course, in the meantime, it will remove poverty as well!

And if you really think it might be a good idea, let’s talk seriously. Because I know it works, when applied in a reasonable way. Yes, your guess is right “reasonable way” is a key phrase here.

Roy Osherove in response to my last post on the art of saying no linked to his short (but very good) article on coaching, pointing it is better to use a chance to help people grow instead of simply turning their requests down.

Yes Roy, you’re right. To some point at least. I mean I love the “What are you going to do about that?” story. But I also know a different flavor of it. It goes like that.

– Pawel, I have a problem with my project here…
– Um, what are you going to do about that?
– I need more people so please assign them to the project.
– Well, that might be a bit difficult. Do we have other options?
– No, this is the only one.
– Are you sure? Can’t you juggle with tasks in the schedule, haggle with the client so we can do something later or something less, incur some technical debt or just be late with this task?
– No, we need more people. There’s no other choice. If you don’t give me them the world will burn in hell of flames and our poor souls will be lost.
– I have no free people, sorry. Now, deal with that.

I know – the last line should go like that:

– I have no free people. What are you going to do about that? Ha! Check, mate! I have just used magic Roy Osherove’s formula so you lose and I win, sucker!

The problem I see here is taught helplessness. People choose the only solution they believe would work, no matter how unlikely it is to happen, and don’t even try to look for any other idea. It’s my way or highway kind of situation. And well, it’s usually my way when we are at that.

Usually in such cases unless you start with the art of saying no you can’t move to what are you going to do about that. You can hardly turn active search for reasonable solution on unless you turn down the one which is imprinted deep in the mind of a person who ask the question.

Taught helplessness basically makes people immune for coaching. If you’re going to help them grow, you better have a good no at hand.

Kanban is a funny animal. I started my journey with Kanban treating is as a tool. Then I realized it is more of a vehicle which improves things around. Now, I extract some ideas standing behind the method and use them independently in different situations.

Since Kanban is as easy as possible – I use to describe it as “three rules, one tool and simple mechanics” – there aren’t many ideas you could exploit, but there’s one which is especially appealing. A contest: which one am I thinking about?

Yes, I know. I ruined everything with the title. What a dumbass I am. Anyway yes, visualization is the concept I like so much. Generally I’m known to be attracted by every whiteboard or flipchart around. If you see me sitting peacefully in a room with a completely clean whiteboard and set of markers you can bet I suffer. I’d love to write, draw, scribble and note on the board, so we all can see some reference to what we are talking about or how others may understand what we’re talking about.

Feel free to laugh at me because of this. It doesn’t happen without a reason. I learned how much value simple visualization can bring. I’m sure there’s some psychological gibberish which shows how our brains deal better when we can refer to a huge visual brutally presenting the core of the issue, but I don’t really care.

I use visualization because I know it helps me. It helps to me to organize presentation, like the one I’m preparing for ACE Conference. It helps me understand the problem, like learning how many quality engineers we do need at the moment. It helps me to express my thoughts, like when we’re discussing performance appraisals.

Next time, when you have some problem, try to draw it on the whiteboard or flipchart. I mean really. No matter what the problem is or how you choose to visualize it. It would help you to understand and chances are good you’ll find a clue how to solve it.

If you wondered why I brought two whiteboards with me to my new room, now you know.

I hear that one from time to time: “people are our most valuable resource.”

Well, they are not.

People aren’t your most valuable resource. People aren’t goddamn resource at all. People are, well, people. Individuals. Folks who somehow like to be treated as real persons and not precious pieces of junk otherwise known as servers and such.

Every time I hear this cliché about people being most valuable resource I wonder: how the heck can you say people are most valuable when you treat them as resource? As commodity. As something which can be replaced with another identical um… resource. If you say that, you basically deny that people in your organization are important.

And it doesn’t really matter how hard you try to avoid calling people with that name. If you believe they are (put here “most valuable” or whatever bullshit you like) resources you won’t trick them. They won’t feel respected and they won’t trust you. Why should they after all? Do servers trust project leaders? And no, that won’t make people motivated whatsoever.

I know, this is a rant. But this makes me crazy. I mean, how could we learn such humiliating behavior? I’m just waiting until I hear “Hi resource” instead of “Hi Jane” when Mr. I’m-So-Damn-Important-Project-Manager meets one of his project team members.

Then, I’m going to hurt somebody. And I guess it won’t be Jane.

These days every blog discussing agile topics should have a big hairy article on Scrum versus Kanban, so here it is. Well, just joking. Actually many people, way wiser than me, approached that subject some time ago already presenting different arguments. If you want to hear some of the strongest opinions out there check Ken Schwaber’s post on how Scrum is good and Kanban sucks. If you look for more weighted opinion David Anderson shared one. Just recently Mike Cohn also added very reasonable two cents to the discussion even though he actually doesn’t agree with David.

Also there’s been a lot written about Scrumbut and Scrumban. I don’t see the point in repeating once again that if something works for your team – go for it, no matter if that breaks the orthodoxy of the method of your choice.

Note: I’m well aware that until now I just share what I’m not going to write about. Is this post is going to be just a set of links to some good articles though? No, not exactly, but please do check mentioned articles – they’re a piece of good reading. Anyway, to the point. There’s one thing which is often mentioned as one of main differences between Kanban and Scrum but I think this is the core of the whole this versus that thing.

The point

From pretty much every Scrum and Kanban comparison you’ll learn that introducing Scrum is a revolution while with Kanban it is rather evolution. You’ll also be pointed that both approaches foster improvement. Now, finally, after all that beating around the bush: my point here is how Scrum revolution differs from Kanban evolution in terms of introducing improvements and why it is so.

Team model and software development process

Let me start with something I was learning for quite a long time (no, I’m not that bright to catch it during the first class):

Scrum proposes pretty damn good team model and process for building software.

If you look for model team which would work in majority of situations go for a Scrum team: cross-functional, small and tightly-integrated. If you look for healthy approach to software development you can’t really go wrong with Scrum. Scrum is well-thought and well-weighted approach. No surprise it ruled the agile world.

On the other hand Kanban tells you that your team model is good for now, no matter how it is organized. And your process of building software is OK even if it’s pretty chaotic. For now.

Kanban doesn’t propose any specific team model or software development approach.

It basically means that you get no hints whatsoever how the well-organized team would look like. Nil. Nothing. Find out by yourself. No help here. Well, almost.

The difference

When organizing Scrum team you can basically turn your thinking off. Well, sort of. It’s all in the book. Someone took the effort to propose team model which I’ve just labeled “pretty damn good.” Same with the process you’re meant to follow.

Kanban chooses the other approach: we don’t know what optimal solution for your team is. Here’s some help but you’re going to learn it by yourself.

The difference? Pretty damn good doesn’t automatically mean optimal. Scrum is optimized for majority of teams, not for your unique group. Yes, of course, Scrum has improvement mechanisms, retrospective being the flagship here, but in terms of general rules it stays unchanged.

Kanban accepts that starting point may be way worse than in Scrum case but leaves you all options open. You aren’t really constrained with specific practices or models. What you’re going to end up with is totally on you and your team.

Help you get

You can put it in other words if you prefer. Scrum tells you how you should change, at least to some point. Scrum is like your mother-in-law – she always knows that you suck here and there and how exactly you should act to be um… better.

Kanban on the other hand is like your friend, close but probably not the best one you have. He’ll try to show you where you could improve but won’t state it explicitly. It’s just not that kind of relationship. It will be rather a set of hints and smoke signs – it’s you who chooses to use them to change yourself or just ignore them.

Which one is better

Neither. Despite comparisons I’ve just use I really think there’s no winner here. And yes, I’m generally considered as a Kanban guy but I also strongly believe there’s no silver bullet.

If you need a kick start Scrum may give you one even though it imposes some constraints on the way you work. On the other hand if you have in your team someone who is experienced with variety of different methods it may be a good idea to start with Kanban and check where it’s going to lead you.

After all, since I’m not an orthodox, I’ll also tell you should experiment like crazy, no matter which path you choose. Heck, that’s where all those Scrumbans started – people were changing their process, people were breaking The Holy Rules of The Method just to end up with something more optimal for them.

Final thought

If I want you to remember one thing from this post it would be: Scrum tells you explicitly how to organize work and improve things, while Kanban tells you nothing about the ideal models and helps you find out the optimal way by yourself.

After all, this post is big and hairy so I guess I succeeded with the task anyway.

As I’ve already started working on my session for ACE Conference 2011 I tinker at different improvements introduced by Kanban and the way they pop out. Actually if I had to point a single, most surprising for me, feature of Kanban I’d point exactly the way it fosters improvements.

When we were starting with Kanban I expected it to be more a very lightweight approach, which organizes the workflow and doesn’t get into way, than something which may trigger any improvements on its own. Things didn’t really work that way.

Yes, we fixed issues we’d faced at that time but that was to be expected. Then we kept finding new issues and correcting them. For a longer time I didn’t really put much thought how it worked but I had to explain somehow specific practices we introduced in my presentation on AgileEE as I wanted to talk about the subject. I realized that we didn’t plan them. They just popped out. Somehow. Magic?

No, not magic. After short investigation I found the one to blame – it was Kanban. Thanks to using Kanban, specific problems were unveiled and we were just fixing them, sometimes completely unconsciously.

One of my favorite stories is when I suddenly realized we had collective code ownership. Yes, it was totally out of the blue. “Wait,” I thought “didn’t we discuss it through? Didn’t we end up with conclusion that we wouldn’t have collective code ownership? What the hell?” Actually it appeared that it was just easier to have collective code ownership in a pull system, such as Kanban, so people stopped thinking whether this is their own or someone else’s code. After some some time we had collective code ownership implemented basically effortlessly.

That is exactly the mechanics of Kanban improvements. You introduce them because it’s just easier that way. You either see something is wrong on the board and have a quick discussion how to tackle the problem and implement a solution or people start dealing with the issue unconsciously. Either way you end up with your process slightly improved.

And you repeat this activity. Multiple times. After some time when you compare what have you started with and what you ended up with you start thinking: how the hell this whole improvement thing in Kanban works? You can’t see it but somehow it’s happening. All the time.

Well, it seems it just works that way. Don’t complain, just make use of it.