You can hear here and there that Kanban scales up pretty well. Actually one of Scrum issues, and I believe one that isn’t addressed neatly, is what to do in projects that take more people than a single Scrum team can accommodate. Definitely one thing which is surfaced pretty soon as Scrum team grows is standup meetings.

As you go with three standard questions through growing team it naturally takes more and more time. Soon it can be a problem to fit into short time-box you have for such meetings.

When team are adopting Kanban they usually leave standup unchanged. However it means that, at some point, they face the same issue as Scrum teams do – 15 minutes is not enough anymore.

Recently Jorn Hunskaar shared such story on his blog. It prompted me to combine a bunch of ideas into a single answer that can be a guide how to improve standups organized around Kanban board. I left a lengthy comment on Jorn’s blog although I believe it is worth to share the idea here as well.

Instead of running typical round-the-table with answers about what happened yesterday, what is going to happen today and what issues are there you may try to redesign the pattern you follow on standup.

• First, go through all the blockers (if there are any). These are definitely your pain points at any given moment. It means that you definitely want to invest precious standup time on blockers. This is no-brainer.

• Second, discuss expedite or emergency items (again, if there are any). This is top priority work from the perspective of the whole team. This is something you really need to get done even at cost of delaying other work. Again, something which is worth investing scarce resource into.

• Third, go through items that hasn’t moved since last standup. These are items which may be risky. Maybe they weren’t supposed to move but in this case it would be a quickie – not much discussion needed. Otherwise it is worth to have a brief analysis what happened that prevented moving cards forward. By the way, it means that you should have some kind of mechanism to mark index cards which aren’t moving, which is usually tricky.

• Fourth, go through everything else. One more guidance you can have is discussing items of one class of service after another in order of priorities. In other words you start with highest priority class of service (bugs, critical features or what have you) and discuss all items of this class of service. Then you move to another one. Well, at least this can work considering that you can tell which class of service is more important than other.

One more rule would definitely be reasonable: within each of these groups you start from the right side of the board and go to the left. This shows that the closer an item is to being done the more you want to discuss it as you are closer to complete it, thus bring value to your users, clients and stakeholders.

Now, up to this point there is little difference – you still go through every single work item which is on the board. There is different focus on issues and you may skip discussing obvious pieces of completed work but still, a lot of stuff to go through.

However, given that you’ve just sorted topics to discuss by priority you can just use a simple trick and just finish discussion when the time of the meeting has elapsed, no matter if you were able to finish all the things. It likely means that you’ve covered all the items from first three groups, and definitely all of them from first two, and whatever leftovers you have are items which require least discussion or no discussion at all.

It also means that on a good day you can cover all things, or more things than on worse day, but that’s perfectly OK. What you basically need is to ensure that most important stuff doesn’t go unmentioned.
Going a step further means that you can skip a discussion over a specific groups or sub-groups of items, e.g. a specific class of service, when you see it doesn’t really add any value. If you aren’t sure try to cover it during standups and see what outcome you get. Then you can start experimenting with the plan of the meeting.

Ideally, after some time, you will end up discussing only important stuff, say, blockers, expedited and stalled items and maybe others which are brought by any team member for an important reason and just skip regular work which needs no more attention than a silent confirmation that everything is perfectly fine.

First edition of Lean Kanban Central Europe conference is history. I was really looking forward to be there although there’s always a bit of doubt whenever you think about the first edition of the event. Anyway lkce11 definitely lived up to my expectations.

Organization

I’ll be short here: kudos for Arne, Bernd and the rest of it-agile folks for making it happen, and doing it big time. I mean, of course there was a bunch of glitches you could have complained on but first, it’s impossible to avoid all of them and second, overall, you don’t even remember about them when you come back home.

In other words, whenever you see these guys organizing such event rest assured it will work as a good German machine. After all, they’re Germans, aren’t they?

One lesson any conference organizer should definitely take was session chairs. A group of people who were introducing speakers, gathering feedback, running with microphone when questions were asked, waving crazily when speakers were going out of time etc. We shared this responsibility among a group of people so it wasn’t that painful for me. And from a perspective of a speaker I can tell you it’s hard to overrate such help.

Content

At the beginning a disclaimer: I was a member of the board which means I feel responsible for how program looked like.

I believe we did a decent job putting the sessions together, focusing on experience reports and bringing great keynote speakers, however I got one very important lesson in terms on conference content. My expectations as a part of the audience have shifted toward advanced content while at big events, such as Lean Kanban Central Europe you need to cover more basic content as well.

It means that I need to look at the program through the eyes of the target audience, not only through mine. It looks that there already are two types of events for me: these where my focus is more set toward sharing my knowledge and those where it’ll be set more to learning.

Basing on reactions on Twitter the mixture of basic vs. advanced and theoretical vs. practical sessions was good. After all, we definitely don’t want to disconnect people who are just starting with Kanban. At the same time we want some food for thought for people who already know the basics.

All in all, even though I think in a couple of occasions we could have chosen better, it wouldn’t really be fair to complain.

A few highlights: both keynotes from guys outside of IT world (John Seddon and Stephen Bungay) were terrific. Not only were they top speakers but they also showed how much we can learn from other industries. Definitely eye-openers for big part of the audience, including me.

Interactive sessions (Kanban Konversation and Read Bead Experiment) worked great too. We need to have more of them next year. Yes, they’re sort of open-ended but most of the time results exceed expectations. By the way: if you ever land on such session, volunteer to take active part and don’t just sit silently in the audience – you will learn way more by active participation.

Networking

Because of my duties as session chair I spent many of breaks on housekeeping, but in terms of networking all the conference evenings worked miracles. Lots of exceptional conversations. Tons of food for thought. Constant challenges for my ideas and experiences. Not only did these discussions covered my hunger for more advanced content but vastly exceeded my expectations.

During presentations we sometimes sound as were dangerously close to dogma. However, whenever we we switch to two-way communication it seems that in reality we are rather reasonable folks, who are open for different ideas and opinions.

Let me just say this: if you don’t engage speakers or other attendees during conferences you’re really missing an opportunity and a big one. Networking brings such events to the next level.

And at Lean Kanban Central Europe networking kicked ass.

Wow Factors

Even though every event could live without delighters – things you don’t really expect, but when you get them they’re just great – it’s always nice have a few of them.

At lkce11 one of such things was definitely gorgeous drawings of every session of the conference, which were reminding us about important messages we heard there.

Another one, as I already told you, was inviting a couple of authorities from worlds different than IT. Definitely a great lesson for all of us who are totally focused on software industry.

Next one was chill-out area where you could recharge batteries of your laptop (power plugs) and of yours (deckchairs). And of course have great conversations. Have I already mentioned how important networking is?

My Session

Last but not least, my session. I can say that I’m really, really happy with the way it went. Actually, I was changing it almost to the very last moment basing on earlier conversations with Katherine Kirk and Bob Marshall (thanks once again for your feedback). It wasn’t recorded so if you weren’t there, you missed it, sorry.

OK, since I’m happy with the session chances are good I will deliver it again if there is occasion (hint: you can create one).

As I believe the subject of risks connected with implementing Kanban is super-important I will definitely write a separate post dedicated to the session itself. However, as always, if you’ve been there, please rate the session and leave feedback.

Final Thoughts

If you need a final recommendation for future Lean Kanban Central Europe events, first think about the content, because this was a big differentiator. Average level of sessions was way more advanced than on every agile event I took part in, and I hope it’ll stay the same. If you think about one big event you can afford every year then mark October in your calendar. Especially, that you should be able to cover basics at more local agile events which definitely are organized, wherever you live.

If you look for occasion to see your mind blown Lean Kanban Central Europe is a right place to go.

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.

There is one thing which really pisses me off. I mean really. It happens when someone has a single solution which is perfect to solve the whole domain of problems. I just organically can’t stand silver bullet salesmen. This is by the way something which made me pretty suspicious when I started learning about this whole agile stuff years ago. It wasn’t that I didn’t believe in methods. I did. The problem was I could hardly accept the “our way is the best, you lesser being” kind of attitude.

Anyway if you know me at least a bit you probably know that in basically every discussion I stand on the hill where all The Defenders of the Context stand. And I will defend it. To the last drop of blood. This means that you will never hear me saying that this or that method is universally best. By the way if you hear me saying so, don’t forget to slap me in the face because that means I betrayed The Defenders of the Context and I deserve it.

Yes, I am aware that I’m considered a strong Kanban proponent these days. I may be even considered Mr. Kanban Poland by some (yay!) And yet Kanban is not a solution for every problem and it isn’t applicable in each and every situation. Now, you have me – I’ve just admitted I don’t have panacea, sorry.

OK, I don’t try to sell you Kanban, not this time. Fine. So um… what’s the point? Well my point is that managing software projects is such a broad discipline that it takes many different approaches, attitudes, methods, tools, manifestos and movements to get the darn thing done in each possible case.

I will often promote Kanban as its beauty is that it is applicable in different situations. On the other hand Kanban with no other tools whatsoever won’t really help you. I love stories on successful implementations of Scrum, especially such down-to-earth as the one recently shared by Eric Sink. But you will also hear me saying that waterfallish approaches have their place as well, and sometimes they actually are a better choice than agile ones.

I guess I’ve proven worthy to be one of The Defenders of The Context, haven’t I? Now, where is it all going? Well, I have a bold hypothesis. I believe people from different worlds of software development and project management can learn a lot from each other. We tend to think that people still using waterfall-like approaches can learn from us agile folks. That’s true. But, and let me stress it, it works the other way around as well. And then there are other worlds which are kind of ignored in this old, beaten to death, agile versus waterfall skirmish. Earned Value, CMMI, Critical Chain and whatnot.

We can learn a ton about our methods, but also about our contexts: projects, people, organizations, clients, office politics, different stupid issues, totally strange requirements, constraints, etc. We can spend hours over beer discussing our best ideas and finding out why they might be not as good as we initially expected in a specific context. We can broaden our horizons way further than we usually do on agile conferences. Not that I have anything against agile events – they’re great. They just tend to gather only one of groups of people I’ve mentioned above.

That’s why I will support every initiative which aims at bringing people from different software development and project management worlds together in one place. I will because there aren’t many of them.

I’m strong supporter of Project Management Stack Exchange as it works exactly this way. Want to find PMPs? Here they are. Agile crowd? Sure! How about people struggling with chaotic projects? Plenty of them. Other worlds? You will get your answers as well.

I genuinely love to read questions and answers on issues which sound virtually out-of-this-world. I love because they remind me how different software projects are out there and how difficult it can be to apply our experience to solve problems in such projects. On the other hand I love to see how often common sense is sort of the best solution. Heck, if I got thousands of rep at PMSE it was basically because of promoting common sense.

On the side note: I did consider abandoning The Defenders of the Context and joining The Common Sense Proponents but the former had cooler outfits.

Another idea which fits the same scheme, although it will be interesting only for Poles, sorry, is Deadline conference. The main goal of the event is to create a common platform to exchange ideas and experience between people from different PM worlds. We have fine agile events in Poland (I even write these words during my trip to one of them – AgileByExample). We have events for PMPs and for CMMI folks, or so I hear. But we don’t try to merge those worlds in one place to learn from each other. That’s why I believe Deadline should be a must have for those project managers in Poland who want to broaden their horizons and those who care about learning.

Although I don’t know such events abroad I believe every local project management community deserves one. It does sound like an opportunity, doesn’t it?

One final thought to support this attitude. One of the most valuable thoughts I got from Kanban Leadership Retreat was a result of a chat with Jabe and Simon on applying sexy Kanban concepts in environments which are um… let’s say challenging. Where expectations of management can be to improve productivity so they can cut costs or where you fight for authority in the first place to be able to change anything at all. You’re right; it’s not really about Kanban. Yet it popped out in the context of Kanban discussion. And all that on a purely Kanban event.

Now you see what I think about – we never get away from the context and sometimes the context is kind of ugly. So the more different situations we’ve seen the better we are prepared to survive in this harsh world of building software projects.

I believe in transparency and openness. I believe a manager should share almost as much information as possible with their teams. I believe the manager should always explain their motives and drivers of decisions they make.

In short I believe in much talking.

Sometimes when a meeting is finished I don’t feel as if I convinced my interlocutor to a decision I make. That’s fair. That’s fair as long as I tried. This basically means a lot of talking.

However, I learned a lesson today about talking much. After my lengthy tirade which I wanted to explain myself with I heard a response:

“You should have said: ‘trust me’ in the first place instead of all that.”

Ouch. That hurt. I mean why haven’t I thought about that? Yes, it is a simple message but a powerful one. The message which makes or breaks the relationship. After that you either live up to expectations or there’s no chance of building trust whatsoever. Yet, as long as you actually plan to do the former, it will yield better results.

My lesson is: yes, transparency and openness are important but it doesn’t necessarily mean more words. At the end of the day it’s about communication quality, not quantity (if you can’t go with quality go with quantity though).

And this is the lesson I’m thankful for.

By the way: we often follow our emotions instead of facts. I don’t say it’s bad. It’s just something to remember when dealing with people.

If we are in Kanban world when we think visualization we see a Kanban board. We see a process mapped into columns with limits attached to them. We see sticky notes, which represent minimal marketable features. We see additional visuals which help to show priorities, blockers, people who are responsible for a task etc.

We mentally substitute visualization with the Kanban board.

To some point it works great. Well, after all it’s not without the reason that a Kanban board, or more generally a task board, became a tool of choice of so many teams.

However, it was never written that one of few Kanban rules is using Kanban board. Please point me to such advice if I’m wrong. Anyway, the rule is about visualization and Kanban board is only one of possible means to this end.

One of great lessons from Kanban Leadership Retreat was how many different approaches are possible in terms of visualizing work. Actually typical Kanban board looked kind of boring among that bunch of great folks as basically everyone had at least a couple of ideas how it can be done differently, depending on a specific situation of course.

The message is: it doesn’t really matter how you visualize your work as long as you are successful at that. Task board or Kanban board is fine, and it usually is very intuitive to use by a team, but quite often there are better ways to do it.

Consider a situation where you deal with a lot of small tasks. Do you really need to put each and every 5-minute-long tasks onto a post-it? Maybe there are more efficient ways to deal with them?

On the other hand, what about tasks which last long months? As I’m playing with project portfolio level Kanban it is a very timely question for me.

A classic form of the board, which I currently use, isn’t likely the best possible approach. I have at least a couple of ideas how to change it. And yes, now that you asked, I was totally inspired on Iceland event to improve my project portfolio Kanban board.

Probably it won’t be a Kanban board as we know it any more. I will still use stickies and whiteboard but it’s not going to look like any other board I’ve had so far. And that’s the real lesson I got on Kanban Leadership Retreat.

Don’t get attached to a specific tool. Kanban board is just a tool. Visualization is way, way more than that.

It’s kind of funny to realize how we learn to treat some things as obvious, like having Kanban board as a part of introducing Kanban. Fortunately, at some point of time we just realize it’s only a tool and we should use it as long as it is useful. If it’s not it’s better to use another one.

I use to say that you can’t lose being honest with me. There is no potential downside – only upside. I have no problems with critical opinions on me, others or the organization we’re part of. I don’t necessarily have to agree with these opinions but I want, and need, to know them. After all, if I don’t know you don’t like something odds are I won’t do anything to change it.

I know there are different managers out there and openness and honesty don’t have to work equally well in each case. However, if you have to hide your opinions and play someone else to survive in a decent health in the organization then, well, I wouldn’t like to be a part of such company in the first place.

For the sake of this argument consider you really can openly talk with your bosses about your problems and frustrations, if you have any. Will you just be honest like you’d be when describing the situation to your friend over a pint of beer?

From my experience: many people are not.

I don’t get it. Let’s say my decision pissed you off or you felt my opinion was unfair. We can sit down and discuss it through. I make mistakes. Everyone does. I change my mind when I face reasonable arguments. So please, challenge me. Challenge my opinions and my decisions.

When your only reaction is venting in front of your colleagues then you do no good to me, to the company and, most importantly, to yourself. What are you trying to achieve that way? Is that what you believe works in the long run? I mean, really?

If you choose being honest, be honest consequently. Being so only to some point is um… quite the opposite of being honest.

I have one more advice: even if you don’t trust your manager give them a try. Maybe they won’t appreciate your open and straightforward attitude. In such case your situation will suck anyway so you don’t lose much. Fortunately, there are many managers who don’t work that way and you just can’t lose being honest with them.

Like me, for example.

I’m always surprised when I meet people who moved to management roles and they pretty much expect it will be reasonably easy position. I shouldn’t be probably. We naturally expect our lives won’t be more difficult than it is absolutely needed.

However, when we’re promoted to a management role we are expected to take responsibility for the team and not only for ourselves, as it was before. And yes, it often means running an extra mile.

Of course one thing is being with the team. If, for whatever reason, they stay late you shouldn’t check out on 5 pm sharp leaving all the work stuff behind. But it’s more than that.

As a manager not only are you a leader of your people but also a representative of a company. This means that you should build best possible environment for your team, but it also means you should be an advocate of the organization whenever needed.

And this is the point where you likely have contradicting goals.

In dream work environments there are no deadlines. People can play with new technologies whenever they want. There is no maintenance work as it is boring. Also there are many additional perks of all sorts from foosball tables everywhere to medical care.

Well, I may be exaggerating a bit but hey, I haven’t made it up – this is what I hear talking with people.

Unfortunately there’s another perspective as well. A manager is a representative of a company. This means they usually should take care of costs and keep productivity possibly high. This means fewer foosball tables and more boring, but well-paid, work. On the top of that the manager should also sell company decisions to the team, even if these decisions aren’t something people would instantly love.

I can give you rather an obvious example: consider you are free to give your people as many raises as you wish and they can be as big as you want. Now the question: should you?

Yes, management job is about trying to cope with goals which are contradicting and sometimes even mutually exclusive. As long as you always choose to do what is possibly best for your people you’re probably failing as a manager. As hard as it sounds you weren’t hired to please them. Take care of them – yes, but not at all cost.

So the next time before you start criticizing a decision or complaining about the imperfect situation, think about both sides. Maybe, just maybe, it is your darn job to support the decision and explain the situation to the team.

And now, that you asked, yes I do expect from you more than from average team member. You are a manager after all, remember?

One of Kanban rules is visualization. This is one I like the most since I just can’t sit at ease next the the clear whiteboard. I have that urge to grab a marker, a bunch of sticky notes and make the board a little less white.

Anyway, visualization isn’t the concept unique for Kanban (what is after all?) and recently you probably hear about it very often. It was one of returning messages across this year’s ACE Conference and it was very similar at GOTO Copenhagen – Dave Thomas pointed it as one of key factors of successful teams. And then of course there was all-day long Kanban track which, as you may guess, was covering visualization over and over again.

So the message is: visualize it! Show what you’re doing on the board. Make it visible for everyone in the team. Make it visible so everyone knows what’s happening. Make it visible so it’s hard to ignore that, especially when things go wrong.

We are inevitably heading toward the question: what “it” is?

Well, “it” is pretty much anything. Because it’s not just “visualize it” – it’s “visualize everything.”

Stages of your process? Checked. Limits? Checked. Who does what? Checked. Blockers? Checked. Cycle time? Checked. Priority? Checked. Area or module of a project? Checked. Emergency state? Checked. And this is only the beginning. These are actually the most obvious examples. Add to your sticky notes any information a team will need. Put it on the board. Visualize it! It is a way of communication. And the one which isn’t intrusive.

It may sound a bit counterintuitive but it works miracles. My recent playground is project portfolio level Kanban and the interesting observation I’ve made already is how the board helps me every time I need to plan new projects or make a tradeoff to respond to changing situation. It even tells me when I need more people faster than our budgeting software, which we typically use for this purpose.

The reason is simple: visualization just works. So go, visualize everything!

I have screwed up. I mean really. I have.

You want the story, don’t you? So here it is. The other day I was talking with one of my team members and I kind of promised something. I told that they’d get the thing as soon as something else is done, something else being sort of pushing project to a specific stage.

Well, that’s what I thought I said.

Because the true is I said something different. I kind of forgot to add the second part, this damn prerequisite.

Well, I might have added it but it doesn’t really matter.

It doesn’t matter because it doesn’t matter what I, as a manager, am trying to communicate. What counts is how the message is received. So I could either way said it like ten times but if I wasn’t able to deliver the message successfully so the team member actually hears it and understands it I could have just omitted it and it would have meant the same.

Basically, I have screwed up.

And I feel totally bad with that. The milk is spilled. If I’m lucky I can probably limit some damages, but then limiting damages doesn’t really sound positive, does it?

So while I sit in the corner and cry over my crappy leadership, take this lesson:

If you’re a manager it’s your damn fault. If someone fails to understand you it’s your fault, not theirs. If you think you communicate perfectly clear I still don’t give a damn. It’s your fault.

It’s not about you feeling well because you believe you kept your word. It’s about people being totally disappointed with you letting them down. You may say it starts being about feelings and not facts and you’ll be pretty damn right. But it doesn’t change the rules of the game.

It’s still your fault.

Letting people understand something else then you say is equally wrong as just lying to them.

It’s your fault.

Trying to get with your message to people and failing at it is the same.

And it’s your freaking fault.

So well, there’s no explanation I want to use. I’ve screwed up. I’ve let one person down and they won’t treat my word seriously for a longer time. Considering that it’s even possible to rebuild the trust which isn’t that obvious.

For that I’m both angry at myself and sad.