I’ve just finished sorting out feedback from today’s team retreat. In my case it was more of a management retreat, as it would be pretty difficult to organize a retreat with all 140 people from my team. Anyway, we ended up having a retreat with all managers from my team, which means we’re down to less than 20 people. Still, kind a crowd, wasn’t it?

What do I mean by a retreat? In terms of a format it was an all day long meeting which was held off-site. Sort of. I mean we went to another office, the one no one works in. We did that, because it is crucial that no one is tempted to go back to their own desk. As one of my colleagues said it: “when we’re meeting in our office my thoughts are always floating around my desk.” For the sake of this meeting I wanted to break this connection. I wanted to have all of us concentrated and focused on subjects we were discussing.

Before I move to subjects we covered a quick disclaimer: it’s been first such meeting since I’m working with my current team. I treat it as an experiment. I know retreats should last at least two days, so we have enough time to chew through things we’ve just heard and come back to them tomorrow, once we have more insight on the subject. Hopefully we’ll come to this point, but first, let’s just make them work in a lighter format.

OK, so this was an experiment and something which was expected to be the first event of the series if people like it. We had a theme – everyone had 20 minutes to prepare a session in a form of their choice on something they’re doing in their team, which is valuable and worth sharing and copying. We ended up discussing stuff from alternatives of meetings (no-meeting culture, anyone?), through engineering practices, to cool coding tools which improve developers’ lives. We had PowerPoint presentations, no-slide sessions and discussions. We had some fun as well.

We run typical round-the-table to share our opinions on what had just happened, but we also had the feedback door.

Although it would be an abuse to say that feedback was purely positive, I’d say that, in terms of feedback, supportive messages just outnumbered critical ones. Now, it doesn’t mean we got it perfect the first time. No, we have hell a lot of work to do. However, we definitely are on a right track.

Why did it work so well then? There are a few reasons.

First, knowledge exchange. We work in an organization big enough that we have these silos, both formal and informal ones. We know each other, but not necessarily know what each of us is doing at the moment, let alone practices we use. It was a great occasion to share some information on that.

Second, focus. We do meet (almost) every week. Yeah, that’s true, but it’s always in the middle of something. This time we were isolated from our errands so we were paying attention to whatever was happening around.

Third, a kick in the butt. When we are in the middle of something important, which means pretty much all the time, it’s easy just to pop up and switch into passive mode. Yup, I will hear anything you have to share, but make it quick. And please, don’t make me do anything – I have important stuff to deal with. This time everyone actually had to prepare something. Not necessarily a big thing – anything between 10 and 20 minutes worked fine.

Fourth, integration. We spent the whole day with each other. Well, if you hate me, or any other of us, that’s not good news for you. However, if you consider us a team, a bit of integration definitely helps.

Now, you can easily scale this format up, and you get top management off-site, which in some companies is kinda popular.

But you can also perfectly scale this idea down to a team-level. Get your team out of their desks and discuss things which are important to them. You won’t be pushing your project further to its success at that very moment but think of it in terms of sharpening the saw. If you don’t let the event slide toward chaotic discussion on pretty much nothing important this investment will pay off pretty quickly.

Try it. You (probably) won’t regret it.

A couple of days ago I had a chance to speak at a local meetup. It probably won’t come as a surprise that I was speaking on Kanban. In fact, it was a test run of one of my presentations I was preparing for one of big events. The point is, only few people shown up.

Don’t get me wrong, I don’t complain. Actually, such events are always win-win. Speaker gets some valuable feedback and an audience attends a session for free, which they would have to pay for otherwise. My end of the deal worked fine – I’ve already improved the session basing on feedback I received. However, I was somehow surprised, and in a negative way, that only few people popped up.

Well, maybe “surprise” isn’t the right word. If you asked me I would say that most people didn’t really care to exploit chances to learn, so they wouldn’t use this one either. People, in general, don’t want to learn. They don’t, even if they state otherwise. People, again, in general, are lazy. They are, even if they deny.

So no, I didn’t expect wild crowds even though I believe the message about the meetup reached quite a bunch of people. I see the same pattern whenever me, or my friends, are involved in organization of a local community events.

However, since I always consider a glass half-full I see a good side of the situation too. If you happen to be the part of this small bunch of people and you actually care to exploit any occasions to learn, not only do you unwind yourself but you also become a demanded employee on a job market.

I was discussing with one of my friends how does he see himself as an engineer. His point was that he wasn’t a rock star developer. My point was sort of similar. He wasn’t a rock star developer… yet.

What I consider as one of his biggest strengths is his urge to learn. He doesn’t have a problem to invest a couple of hours of evening or weekend to attend local community event. He does this as A, it is a chance to learn and B, it is an occasion to meet interesting people and exchange experience with them.

What he basically does is he’s consciously working on becoming a better professional than he is right now. So if you asked me about his value on job market I wouldn’t answer talking about what he knows at the moment, but what kind of potential the guy has and how he is using it. Give me the choice among him and another developer who is very skilled but have a regular “I don’t give a damn” approach and it would be a no-brainer for me when it comes to choose who I want to work with.

Sometimes I hear complaints about different trainings or presentations people attend. It wasn’t that stunningly mind-blowing, or the trainer could have been better, or two third of content wasn’t new at all or whatever else. Now, let me stress it, in my whole life I’ve never been on a training, conference or meetup where I wasn’t able to learn anything at all. Yes, it is true that sometimes you learn by negative examples, meaning the only thing you get is knowledge how not to do things. But it is still a lesson, and a valuable one!

So even though I expect people don’t give a damn I’m still surprised why it is so. If I asked all these people whether they want their career to be just a bit better they would agree in a second. And yet they do nothing to improve the situation they’re in.

If I counted all the hours I voluntarily spent on learning, including all the ramblings I share on this blog it would be hell lot of time. And believe me; I don’t regret any minute spent on this, even though I learned many things I don’t use at the moment. And no, no one paid me for that. It was just an investment on my side. The investment, which pays off, as I’m better professional today than I was yesterday. Or so I hope.

This basically means that if you happen to hire me you don’t just buy what I am today, but you also get all the potential I’m striving to exploit. The same I look for when I hire. I look at who you can become in a couple of years, not only what you’re worth now.

Why am I writing all that? I do, to make you move your butt, look for occasions to learn and exploit them! Yes, I have selfish motivation as well. Next time I do something in local community I want to see more faces popping up. I want to see more people who strive to learn since it means there are more people I want to hire. And now that you asked, yes, I consider it win-win.

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.