When I’m speaking at different events I usually keep evangelizing Kanban. Well, it’s sort of easy when you speak to an audience which is aware of this whole Kanbanish thingamajig. They may be even wrong when it comes to answer what Kanban really is but we still have a common starting point.

The challenge starts when you try to ignite with the idea people, who not necessarily are aware of agile, lean, craftsmanship, whatsoever. Oh, maybe they even know something on the subject but they aren’t that much into it.

Let me explain myself a bit more. If you go to a conference like Lean Kanban Central Europe (and you definitely should) you can safely assume people know the basics. On the other hand, when you go to a regular software development, let’s say Java, conference where you face folks who came there to see, well, Java stuff you can’t assume they’re all crazy about software craftsmanship, agile, lean or whatever is hot these days.

So the question is: how do you reach these people with the stuff you believe in?

In my case I work in the context of Kanban, so I started thinking what a gateway drug to Kanban is. My answer for this issue is…

Visual Management

I once wrote that visualization is my favorite part of Kanban. I also confessed that I started consciously using visualization apart from Kanban as a separate tool.

And I want you to follow me on this path. I don’t set any pre-requisites. You may be a regular attendee on agile and lean conferences and know Kanban by heart. You can also be ignorant in terms of all that stuff and visual management should appeal to you as well.

This is what you’ll see me advocating on occasions. OK, what is visual management? If you go with Wikipedia definition you will learn that…

Visual control is a technique employed in many places where information is communicated by using visual signals instead of texts or other written instructions. The design is deliberate in allowing quick recognition of the information being communicated, in order to increase efficiency and clarity. These signals can be of many forms, from different colored clothing for different teams, to focusing measures upon the size of the problem and not the size of the activity, to kanban and heijunka boxes and many other diverse examples.

In other words we use simple “visual signals,” which may be sticky notes, color pins or magnets, graphics, etc to share information among a group of people. How?

I could have been describing how one can apply visual management in their team but let me do it in more visual way. Yesterday I had a session at ABB Dev Day, which was a very nice event addressed to developers. When I say “addressed to developers” I think that I have no freaking idea what I was doing there as my last code check-in is dated to 2003 or something. What more, my session was probably the only one which didn’t show or mention the code in any way. Now you understand the challenge I chose to face.

This is how I tackled the challenge

By the way: If you happened to be at ABB Dev Day please rate my session and/or leave feedback.

I owe you a few words about the event itself. First of all, kudos for hosts for organizing high-quality free event. It reminds me good old times when local branch of Microsoft was organizing such events twice a year spreading the word about their technologies.

Despite no one paid to be there the room was full until the very end. To be honest, it doesn’t come as a surprise really as sessions were interesting, even though they touched a surprisingly wide range of subjects. One thing I could complain about is networking, which didn’t work that well, but it’s always tricky on 1-day conference where there’s no evening event and everybody is in rush to come back home.

From a perspective of a speaker I can’t say anything but I’m totally happy with how I was handled by hosts. In other words, if you have a chance to speak at the next ABB Dev Day, don’t hesitate even for a minute.

And if you want to hear me speaking on visual management, and sharing my passion for putting everything on the wall in your office, and spreading my love to whiteboards and sticky notes, just let me know – we’ll work something out. As I’ve already told you there are no pre-requisites – it is a tool for both beginners and vets.

As my last slide says: Try it! You won’t regret.

When this post goes live I’m already going sailing to the seaside. It may sound very nice, but considering it is the Baltic Sea and it is already fall and a weather forecast is kind of harsh, it probably means the adventure will include being wet, cold and seasick. Sounds oh, so nice, indeed. Especially the part about throwing up.

Why do I go there then? Well, I do because sailing is one of my passions. I know these few intensive days will recharge my batteries even though I will cut significant part of my sleeping time out. It is pretty simple – do something you love and no matter how exhausting it is at the end of the day you’ll be on the cloud nine.

“That’s nice, Pawel. Actually you didn’t tell us that you switched the profile of this blog and now you’re going to share your ramblings on your private life. In this case I’m unsubscribing the feed. Good bye.”

Um, wait, please. Actually there’s a purpose of this story. Exchange sailing through Baltic Sea with whatever you do at work and seasick with your pet peeves from workplace. Now, ask yourself whether you still are happy to go there even if the forecast is harsh. In other words: are you passionate about your job?

For those of you who are managers there is following question as well. Are your people passionate about their jobs?

These questions are super-important. Passion is a differentiator between mediocre folks and those who genuinely shine and everyone wants them in their team. Passion is a differentiator between people who learn new things because it is included in yearly performance appraisals from those who just want to excel at what they do, no matter how far from perfection they are at the moment. Passion is a differentiator between these team members who you have to regularly check from those who you trust and you know they’ll do their best under all circumstances.

“OK, I may reconsider unsubscribing the blog after all. But the passion is something people have or don’t have. What’s the point, then?”

Well, sort of. It is likely that most of us work with at least a couple of people who could have become more involved. But for some reason they don’t. If I had to bet why it is so I would say it is lack of passion. So maybe we should look for a way to ignite this passion.

Yes, I know. If someone works in the same role for a few years already and you’ve never seen passion, expecting it will suddenly blossom is very optimistic version of optimism. So maybe, just maybe, looking for a new role for such person can be a game-changer? I mean we aren’t born as sailors. In some point of time someone takes us to a lake or a sea and then we discover our passion.

It isn’t that different with our jobs.

And I bet you’d prefer to work with passionate folks than with soulless specialists, even if the former were less skilled on the day one. It seems it is worth to run an extra mile to find everyone in your team a role which they’re passionate about. After all, even if you don’t succeed in each and every case at least you know you’ve tried.

Passion makes a difference.

The other day I had a discussion over a Kanban board design. A team has realized the board doesn’t reflect the way they work ideally. We started analyzing what happened. What did actually introduce a disconnection between the reality and the board? We ended up with quite an interesting conclusion. It appeared that the board showed the process as we’d like to see it. Unfortunately in reality the situation was far from optimal. The team wasn’t able to follow the “ideal” process even though they would like to do so.

A natural reaction was asking a question: should we keep the board as it is and try hard to adjust the way we work to the “right” way, or we should sort of degrade the board to sad reality.

First of all, I understand why this question pops up. We naturally want to keep the board “better” so as to help us improve our process. We expect the board to be the sign pointing toward the ideal.

Except Kanban improvements don’t happen this way.

Yes, you’ve already have my answer in the post title so you shouldn’t be surprised. The board should reflect the reality no matter how sad it is. The reason is simple: when you work with Kanban you make everyday decisions basing on what you see on Kanban board. Now, if the board lies you are likely to make wrong decisions.

We probably discuss decisions like “whether I should start building another feature or maybe help with testing the other one” or “are we ready to deploy it into production yet?” However, if such wrong decisions stack up they don’t do any good to you, your team or your project.

Not only is there hardly any improvements at all but you actively harm the project.

Kanban improvements work differently. People change their behavior or attitude basing on what they see on the board and constraints the board enforces on them and not because the board shows the ideal world. So first, there should be a change in the way the team works and only then we should adjust the board.

In other words the board should always reflect the reality.

If you liked this post you may also like the whole Kanban Story series, which is a documentary of one team’s adventure with Kanban.

I promised to share more thoughts on my Kanban presentation from AgileByExample. Actually during abe2011 there were 3 sessions which touched Kanban in one way or another. And then, well, and then there was a heated discussion, mercilessly cut off by the conference hosts. Even though we didn’t convince each other to our points (after all it isn’t the goal of discussion, is it?) I definitely learned a lot from it.

First, to set the tone, my presentation.

I shared the story how, thanks to Kanban, in one of my teams we improved our engineering practices and changed our behaviors. Kanban is such a nice improvement vehicle and I wanted to show it.

Then, Marcin Czenko shared his experience with Kanban pointing that it is a tool for more experienced teams and that, generally speaking, teams shouldn’t start with Kanban. They should start with something more structured, like Scrum, and only then evolve toward Kanban.

That’s how the beast has been awakened.

I’m a living counterexample of Marcin’s hypothesis but that’s not the point. Actually Marcin’s session was just one example of something I kind of know. I mean I remember when I treated Kanban the same way. It was a couple of years ago.

Let’s consider for a moment that Kanban is a project management of software development approach. With just a few rules Kanban can be a dangerous tool. I mean it leaves much freedom which can obviously be used in many different ways. To sanction chaotic process for example.

OK, the moment has passed: Kanban isn’t goddamn project management or software development method! Kanban doesn’t tell us how we should build our software. It doesn’t say a word about managing projects. I don’t say you can’t use Kanban to help you dealing with software projects though. You sure can. Heck, this was the initial idea, or so I believe at least. But I beg you; please don’t rely in this area on Kanban alone. And if you do, don’t complain later.

Kanban is a tool which helps to deal with changes and improvements. If used as they say in the instruction it should allow you to improve. Improve your process, your practices, your behaviors and your attitude. However, Kanban is no guarantee that you will have the best organization around. It doesn’t even give you some sort of benchmark which allows you to compare your team to others.

With Kanban you don’t go to a specific point, or a specific organization, which looks like for example Scrum by the book. With Kanban you just try to be better tomorrow than you are today. Oh yes, it means that tomorrow you totally can have crappy process, useless practices, bad behaviors and negative attitude, but at least the direction of changes would be right and they would be slightly better than they used to.

Now, if you treat Kanban as your project management or software development method you are disappointed and rightfully so. You could have done better applying one of proven methods which, when done right, sort many things out from the day one. But don’t blame the method. Blame people, in this example meaning: yourself.

Coming back to unfinished discussion with Marcin: I would advise Kanban as a good choice for many teams which aren’t experienced much. They actually might very quickly move past the point, which they would have been in if they’d chosen to start with by-the-book method. It all boils down to their attitude to Kanban. As long as they understand how it works achieving quite impressing results is that hard.

I am well aware this whole thing isn’t obvious and people treat Kanban differently. Especially when they played with it only in one specific environment. I don’t blame them. I explain, I bring examples, I discuss. It seems sometimes I even argue and write longish rants. But it is work which I really love to do. So, thank to Marcin, here it is: an overgrown explanation of one of my favorite David Anderson’s quotes:

Kanban is an approach to change management. It isn’t a software development or project management lifecycle or process.

Kanban is a pull system. Period. In Kanban everyone pulls the task from the previous stage to another. Developers pull tasks which are ready, quality engineers pull tasks which are built, release managers pull those which are tested, and so on, and so forth. Basically every operation on the board happens that way.

Well, almost.

There is one interesting thing I realized talking some time ago with Nadia Zemskova in Copenhagen. In one situation we usually have push instead of pull operation. When? Consider a typical Kanban board where a backlog is split into two columns: long-term backlog where you put everything you’re going to build and short-term ready column or to do queue where you put just a few tasks of highest priority at that moment. The board which looks like that:

Now, what is happening here is usually a part of job of product owner or product manager: they have to choose what the most important thing to be build at the moment is and push them into production process. Um, have I just used the word push?

But that’s exactly what happens. When working with backlog we don’t just pull first thing from because first we have to decide what is going to the top. When we prioritize features we look though all of them as we theoretically have to compare every possible pair of features and say which one is more important or more urgent. We actually decide what exactly will be built in the first place. We push a bunch of features into to the top of the queue or, in other words, into production process.

From this point the whole process is pull but the first stage works the other way round. There are two differences between first stage and the rest.

First, when prioritizing features we usually work on big pool of them – actually all of them which are in the backlog. Later we usually don’t have more than just few features to choose among and very often we can pretty safely assume all of them will be completed soon enough.

Second, at the beginning prioritization is crucial part of our activity – we make conscious decisions what should go first and what should go next. Later in vast majority of situations we can use simple mechanisms like first in first out and it would work well. At the beginning we can’t go with something like that as we’d be building our software in rather random manner. And that doesn’t sound like a great idea if you ask me.

That is why we retreat to the good old push to manage backlog.

If you asked me to point a single thing, which I hate most in senior management role, I wouldn’t have any problems with the answer. It would be firing people. On my personal hate scale there’s firing, then huge, huge void and only then other unpleasant things and tasks to do.

Each time I fire someone I feel like a complete jerk. It doesn’t matter that the decision is well-grounded. It doesn’t even matter when I’m proven, after some time, it was the right choice. It isn’t any easier.

And the next time you do it doesn’t become any easier either. I mean if executing such decisions is easy for you and you feel comfortable firing people there must be something seriously wrong with you.

Yet I still think firing people is extremely important part of pretty much any management job. If you’re a senior manager you likely have power and authority to make such decisions. If you’re a team manager dealing just with your team of six or something and you don’t have that much of power, you still can convince your superior to make a tough move. Sometimes the latter is even worse as you have to do all the talking as it is you, who started the whole thing.

OK, why is it so important then? Because this is one of methods of building great teams. As harsh as it sounds: sometimes you don’t have enough resources (meaning: time, patience, money) to make a person act on acceptable level and the best thing you can do is to split your ways.

Don’t get me wrong, my advice still is: do everything you reasonably can to fix an underperformer. I know way too many people who started shining when given a second chance to say otherwise. But then remember that it’s a manager who is responsible for building the high-quality team, so if you just accept the underperformer in the team you basically harm the team on many different levels.

What more, sometimes we’re out of luck and we don’t have all the time and money of the world to try virtually every possible thing one could think of. Sometimes our fixing options would be limited. Sometimes constant resistance of the underperformer will make us lose faith faster. Shit happens. We don’t live in ideal world. And then it’s time…

Well, for many managers I know then it’s time just to accept the fact someone is underperforming. And you know what? I understand them. I understand them because firing people is so damn hard and so freaking unpleasant that I can think of thousands of reasons why I shouldn’t do that. At all. So yes, I can perfectly understand them.

But I don’t agree with them. We are paid to do our jobs even when the jobs suck on occasions. When we make our developers write boring documentation which just has to be done it works similarly. The only difference is in level of responsibility. But we still expect our developers would deal with crappy tasks, don’t we?

Having balls to fire people isn’t something which makes a manager. In fact, with a bit of luck we won’t need to fire anyone for years and will be able play the role of guru manager neatly. However, when time comes you better be ready to deal with the worst management task ever. Otherwise your whole team will be constantly taking big hits on morale and you no longer will be considered a rock star manager.

If you’ve just lived through such situation for the first time I have two messages for you. First, it’s one of the most valuable experiences as a manager you can possibly have so good for you. Second, yes, I know how crappy you feel now and it’s not going to become easier next time you do this, sorry.

I was asked for an advice the other day:

“We have a problem with mapping testing stage into our Kanban board. In ideal world we would test a feature once it is developed, and deploy it on client’s testing environment if and only if every bug we find in the feature is fixed and verified. Unfortunately the reality isn’t that nice – pretty often we deploy a feature even though testing isn’t finished or some bugs aren’t fixed. Sometimes the feature passes user acceptance tests (UAT) even though there are known, sometimes even major, bugs on our side. It introduces a mess into the Kanban board as we have features shown as under testing even though they are already deployed so basing on the board it is hard to say what exactly is happening with a specific feature.”

One of answers could be: fix your damn development process and bagger off. However I don’t count it as a good answer really. I mean yes, it is broken process which generates mess so we should work on that as well although it’s a longish discussion and it’s definitely not my point here.

My point basically is: if your process doesn’t suit your Kanban board, adjust the board otherwise every time you look at the board trying to make a decision you will stare at fiction. You don’t want to make decisions basing on fiction, do you?

OK, in this case a starting point looked something like that:

The basic problem was that in reality testing was done throughout testing, deployment and UAT phases. Even worse, given that it’s a client who says the feature passed UAT, meaning the exit criteria is acceptance from the client, it was possible that testing was still ongoing while the feature formally was at the right edge of the board (UAT done).

In short: when looking at the board it was impossible to say which features have been tested, which are being tested and which are yet to be tested.

A question: how to map such situation into linear process, which we usually have on Kanban board? Well, you basically can’t do it. Fortunately, and correct me if I’m wrong, we were never told that we need to map everything into a linear process. Actually we weren’t even told we need a Kanban board. We were just told to visualize workflow.

Coming back to the point, we ended up with a conclusion that in this case testing is an ongoing activity happening concurrently during a big part of the whole process. Digging deeper we decided that basically there are only two types of bugs related to any feature: these which would block us to use the application in production and those which wouldn’t. It doesn’t really matter whether a bug is minor but the client insist on fixing it or an issue wasn’t found by the client but from our perspective it is a major problem – we just wouldn’t push the application with this feature into production.

What struck us at that point was that such information can be easily attached to a feature: we potentially could use a feature safely or not. It’s not a stage of the process – it is a status of a feature. Why shouldn’t we show it as a feature status though? Say, a small red sticky note attached to a feature when it isn’t good to go and a green one when it is.

To be perfectly compliant with Kanban rules we should make the policies explicit – what does it mean that a feature is or is not good to go? At this point, it was pretty easy. A feature isn’t good to go either when its testing wasn’t completed or we have at least one unfixed blocking bug submitted to this feature. In such situation we should have a small red sticky attached to the feature. On the other hand, a feature is good to go when its testing was completed and there are no open blocking bugs. In this case we attach a small green sticky to the feature.

One more tweak which was pretty obvious: as we want to distinguish features which we’ve started testing from those we haven’t, we attach small red sticky exactly at the moment when testing starts.

The board after changes looks like that:

Looking at the board you can tell that feature C went through internal tests and there are no known blocking bugs. On the other hand, feature D which is at the same stage of the process (UAT) isn’t good to go, for whatever reasons. We also have a situation where feature B, which passed user acceptance tests (UAT) have a red sticky attached to it, which means there is still something wrong with it – most likely a bug found internally but the one which is important enough that it has to be fixed before we consider a feature done-done.

We can also easily distinguish features which are being tested from those which aren’t. Features F and H are of the former group and features E and G are of the latter. Note that feature E is on the later stage of the process than feature H and yet is wasn’t touched by a quality engineer even though the feature H was. By the way: it may be perfectly reasonable decision when you have to make constant tradeoffs what is more important and goes first and what is less important and waits for its turn.

To summarize: what we basically did was we came back to roots. When teams start playing with Kanban one of the first things they do is mapping their current process into a Kanban board. It seems this activity isn’t exclusive for the first day only. On occasions we notice that our Kanban boards don’t precisely describe the process we follow and this is exactly the moment to review and improve the board.

Another lesson here is that you shouldn’t try to adjust your process to simple constraints the basic board sets. If your approach is: the reality should suit my board and if it doesn’t so much the worse for reality, your board will quickly become irrelevant and you will get no value from it whatsoever. If the most basic methods can’t help to map your process into the board look for methods which work, even if it takes some more effort and creativity. The board itself is as flexible as it is physically possible. Given that you use the physical board that is. Use this power.

And then, once you solved your own problem, don’t forget to improve constantly. In this case I have at least a couple of ideas for improvements but there’s no point in applying all the new ideas unless you validate the older ones. With the right mindset there will be a lot of occasions to try out new concepts with no doubt.

If you liked the article check out The Kanban Story – a documentary of discovery and implementation of Kanban in one team.

Occasionally I receive some flak because of one of decisions I make. Almost always it is one of those decisions which changes status quo.

Let’s take an example: an employee has an offer from a competitor. You care about her so you try to keep her offering different things, e.g. transition to a better project, raise, etc. However you keep your offer rather reasonable. Basically you don’t try to do more than you would if there were no offer from the competitor. Unfortunately eventually the employee leaves.

A question pops up: have you done everything you could to make her stay?

Well, basically no. You could have paid premium or let her be prima donna or whatever but you decided you want to be fair with everyone in the team and not just make her stay at all cost.

Now it’s time to receive criticism. Hey, you could have fight for keeping status quo. Forget everyone else, now she will leave and the whole world will stop. Aargh, we’re doomed!

Um no, not exactly. The sole fact that you can do something doesn’t automatically means you have to, or even should, do it. Making a fair decision, even if it is difficult, usually pays off in the long run. In this case you play fair with the whole team even if it means losing one good employee. On the plus side, you mitigate a risk of frustration among many people in the team. Besides, let’s face it: shit happens, sometimes people leave. Unless you work in damn cool startup, that is.

Anyway, every time you make such decision think about longer perspective and the whole team and not about tomorrow and a single person. It will help you to make the right choice.

Chances are good you won’t be understood in the first place. I can almost guarantee you that you won’t be considered a hero. It is way more likely you’ll be dubbed as the one who doesn’t give a damn, even though that you actually do. After all you changed status quo.

And this is why these decisions are difficult. Otherwise they would be easy and obvious.

Every time I’m on some kind of management training I have this vague feeling of disconnection. I mean I do assume a trainer is a competent person who saw way more different work environments than I ever would. They also are trained trainers meaning they know all the tricks how work with a group, what are effective learning techniques, how to make training entertaining etc. That’s what I expect after all.

And yet, I can’t help thinking their knowledge is somehow shallow.

To take the first example – for me it’s now time of performance appraisals. I spend long hours (days actually) talking with, and about, managers from my team. One of parts of such appraisals should be goal setting. Now, ask any of those trainers teaching you how to run a good performance appraisal and they would tell you that goals should be SMART.

Great. The problem is pretty few of goals I set are really SMART. Does mean I’m a crappy manager?

Well, many of those goals are hardly measurable. Let me give you an example. I, as a senior manager, care much about building trust relationships with managers in my team because I strongly believe it is a crucial factor of success for the whole organization. How should I, or my boss, set a SMART goal for me in this area? “Gain trust of n managers by the end of the year.” As if it was kind of badge or something. Darn trust isn’t measurable! And even if it was setting such goal would be just dumb. Is getting trust of more people better than getting trust of right people? And how do you define “right people,” huh?

This is exactly the problem of many trainers. They have their recipes. They know how to sell them. The question is: do they care to come down to learn a specific situation, understand a real problem and adjust their tool to a context?

Most likely they don’t.

Thus my vague feeling of disconnection and difficulties whenever I try to apply trainers’ recipes in real-life situations. Well, I don’t really do that but I like to imagine I do and I point every single hole I see in them.

It is a problem of reality. It is so painfully specific. It’s never general. It can’t be described with a set of rules which are always true. Yet I’m being told over and over again there are such rules. Rules, which just work. I would even believe in that but, unfortunately, every time I try to apply them they seem so irrelevant.

What is my lesson today? Understand a context. Many rules may sound reasonable during training but unless you apply the context you can’t judge their real value. And few people are willing to sell you a difficult truth: it’s never about recipes; it’s always about people who use them.