Pawel Brodzinski on Leadership in Technology

Whatever it takes to lead a team, build a product, and run a business

Author: Pawel Brodzinski

  • The Project Portfolio Kanban Story: Project Portfolio Kanban? Why?

    OK, so I landed in this fine, fine job, leading a crowd (almost 150 actually) engineers who work on, well, software projects. Not a surprise, eh? With such a big team your job is mostly orchestrating things. You just have to keep the machine running and performing well.

    What you basically need is an overview of stuff. All kinds of stuff. For me personally the easiest part of catching up was people. Well, of course no matter how hard you try you won’t have the same relations with 100+ team as you had with 25 or, heaven forbid, 5 people. No surprise here, it was totally different from that neat tiny team I had previously. Anyway learning who I work with was sort of easy.

    However to make any reasonable decisions in such team you need to know, at least on the high level, who does what and how exactly you define different “whats.” I mean, you need to know all the ongoing projects their importance, relationships with clients, experience needed to successfully complete specific types of projects, and so on and so forth. In short: you need to learn hell lot of things about dozens projects.

    And you better be quick as the first person knocking to your door to ask for people for a specific project is coming next week. Early next week. Namely Monday 9 am.

    OK, first days, well, first months you spend in a fog. That’s natural. Then you start to actually know what all these teams do on a general level. Except you keep forgetting all these details: when this project starts, when another ends, how many man hours/weeks/months/years we plan for the other and which of those two are somehow connected with the other one you’ve just discussed.

    It was exactly this sort of situation I found myself in. I could have started a rugged friendship with our budgeting application but it isn’t a friendship you dream of, if you know what I mean.

    On the other hand I knew Kanban enough to play with it in completely different area and I heard there are folks applying it on portfolio level successfully. Sounded like a perfect idea for an experiment.

    To be honest I didn’t make a deep research on the subject. The basic concept is simple if you already know Kanban – you treat projects the same as you treated features and then the magic happens. Well, I might be oversimplifying a bit, but only a bit.

    After all I tackled the problem with a proper mindset: “what I start with is wrong so I will be changing my approach as I learn what works and what not.”

    My expectations were simple: visualization would help me to have control over what is happening. At the beginning I didn’t even set any goals how I wanted to adjust our project portfolio. I just wanted to start and see the early results. Knowing Kanban for a longer time I felt pretty sure there’s something good waiting for me on the way.

    Finally, I accepted the possibility that I would eventually abandon portfolio level Kanban if it doesn’t give me any value. So that’s how it all started.

    In the next post in the series you I will share what the first version of my portfolio level Kanban board was.

    Project Portfolio Kanban Story is the place where the whole series will be aggregated once further chapters are published so keep an eye on it.

  • The Project Portfolio Kanban Story

    The Kanban Story was the idea which came to my mind soon after we I started playing with Kanban with my team back then in early 2009. I thought that sort of live journal of our Kanban adventure can be an interesting thing to read. I knew that we probably got some things wrong initially but after all Kanban encourages you to have experimentation mindset and also I’m a strong believer that failure is actually a good thing.

    By the way: now that I read my story, sometimes I deeply disagree with the way we approached Kanban, yet still it was a valuable experience and hell of a lesson.

    The Kanban Story ended up as the most popular series of posts on this blog of all time and a few chapters are also high on the top 20 list. Sort of success I’d say. So when I started playing with portfolio level Kanban I decided to go the same way. I let myself a few months of experience just to have some content for the beginning and here it is: the very first post of The Project Portfolio Kanban Story.

    It will follow similar pattern as The Kanban Story which means I won’t try to address all the problems of the world but will rather focus on the specific situation and explain what we did and why. Expect much of the context and much of experimenting to find the right solution. Expect wrong decisions and changes. It’s going to be some sort of experience report. In chapters. I hope you will enjoy it as much as its predecessor.

    Here’s the list of all posts of The Project Portfolio Kanban Story:

  • Collaborative Spirit of Kanban

    Sometimes Twitter is a mine where you can dig thought-provoking gems. A couple of days ago Alan Shalloway said, as a part of a heated discussion, that:

    People who say Kanban isn’t about collaboration forget that one of the core practices is improve collaboratively (using models/scientific methods).

    I both agree and disagree.

    I mean, yes, this is true – collaborative improvements are one of Kanban principles. And yes, the word “collaboratively” is there for a reason. And triple yes, whenever you are setting up the process or improving it you work collaboratively.

    At the same time I can’t agree with boiling collaboration in Kanban down to “improve collaboratively” only.

    One of most canonical examples of improvement introduced by Kanban is on-demand swarming. When either a feature is blocked or we just have bottleneck resulting with full work-queue people swarm over it to get the flow, well, flowing again. I know Kanban doesn’t tell you that you should collaborate in such situations but actually introducing limited WIP results in many similar behaviors. People are helping each other. Last time I checked it counted as collaboration, but well, maybe we use different definition of collaboration.

    Another, pretty typical, situation I see in Kanban teams is a result of visualization – when team members see that one of their colleagues, for whatever reasons, is coping with multiple work items, they tend to help instead of just starting another feature from backlog. Sounds like collaboration, isn’t it?

    Then we have complexity of processes we try to cover with Kanban. Despite simple Kanban board we see here and there software development is usually pretty complex process. At the same time we are advised to start simple with Kanban. It means that we often come up with a board which is pretty simplified model of what we are doing. For example, usually testing/quality control stage covers both testing and bug fixing, meaning that most likely at least a couple of people work on a feature at the same time. Collaboratively. With no formal hand-offs.

    And when we are at hand-offs, with Kanban we make them visible on Kanban board. We also have incentives to optimize hand-offs, both in terms of a number of them and in terms of time features spend waiting to be picked up by the next person. Fewer hand-offs mean improved collaboration as people need to cover removed formalisms (hand-offs) somehow. And believe me, they do.

    We also work collaboratively whenever we are changing the process. I’m yet to meet a team which had this part of Kanban setup just enforced by someone. I’m sure there are such teams out there but, at least now, it is total minority. What more, usually these discussions are launched be team members, e.g. when they don’t know where to put an index card, which basically means that the process might need some improvements. This collective decision making process can be called collaboration I guess.

    I could probably go further but, by this time, you get the point. Despite Kanban doesn’t say collaboration over processes or something alike, thanks to its rules, it really fosters everyday collaboration. Usually it is all about small things: swarming over this blocked feature, quick feedback loops with that one being tested, launching a discussion about adding a column here or changing a limit there.

    Collaboration in Kanban isn’t about big words and big ideas. It is about tiny everyday actions. But please, don’t tell me that Kanban isn’t about collaboration. That’s just bullshit.

  • What Makes a Good Retrospective

    The other day I facilitated a retrospective for a fellow team. My goal, as a facilitator, was basically to help them to suck as much value out of the meeting as possible.

    Now, before we move on, a picture from a past. I recall a bunch of retrospectives which looked like this: a whole project team met for a longer time and everyone was asked what was good about the project and what needed improvements. Then, one of project leaders wrote it down in a document uploaded the document to a server and finally everyone could just happily forget about the whole thing.

    Does it sound familiar? It probably does for many of you. Does it add any value? Um… next question, please. Isn’t it a complete waste of time? Oh well… If you don’t plan to make any use out of retro, don’t even start it.

    So the question is: what makes a retrospective valuable?

    The answer is actually pretty simple.

    Value of retrospective can be measured in terms of changes sprung by it.

    It basically means that the team decided to act, to try something new, to deal with a problem. It doesn’t necessarily mean that it will be an overnight success. Most likely it won’t. But at least they gave themselves a chance. They might even totally fail with the first approach, but they kept trying.

    Note: when I say changes I think about things which are really changing, not about those we just say we’re going to change but don’t do so.

    Anyway, another problem pops up. We want changes, but how to make them happen?

    Um, that’s sort of easy. Remember about a few simple rules:

    • Don’t chase too many goals. It’s usually tempting to cover each and every issue we spotted. After all we have all the enthusiasm and we want to improve. The problem is that when we commit to too many tasks we’re going to fail at many of them. Then, we’ll get discouraged that we don’t see any results of retro and our enthusiasm won’t be that enthusiastic next time. If there’s going to be the next time, that is.
    • Assign people to tasks. Task with no individual attached to it isn’t really assigned. A decision that the team would do something means that, well, someone else can do it, not necessarily me, right? Tasks assigned to everyone most likely end up not being done by anyone.
    • Have deadlines. Ask when you’re going to be done doing this or that. Keep your deadlines possibly short, yet definitely reasonable and achievable. Stating that something will be done in 6 months is meaningless. In 6 months I can work in the other place of the planet. A couple of weeks are a time frame we understand way better than a few months. If tasks don’t suit short time frames, chop them to smaller ones.
    • Verify outcomes. When deadlines pass remember to discuss with the team what was done, what was the outcome, what else, if anything, has to be done about discussed issues. Again, I don’t assume that all the problems are solved. You may end up with a solution, which didn’t work, and will to try something different. You can also end up with solved problem but the least you should do is saying so. Starting the next retro with such a summary of outcomes from the previous one is a good practice.
    • Repeat. One retro is just a quick fix. If you need sustainable change do retrospectives regularly. I don’t believe you are so perfect that one retro is enough to solve all the issues you might possibly have.

    In short you want to end up with a short list of actionable work items assigned to people and then check how you’re dealing with them.

    Of course sometimes it just sounds that easy. Sometimes you need to work hard to avoid blame game, get focused on specific issues, cut out longish but pointless discussions, learn to accept things you can’t change etc. Sometimes you will need to try different formats to animate communication or build basic trust between team members or change their attitude to anything positive. Sometimes it may be damn hard work to do.

    But as long as you aim for the goal and your actions help in achieving it, you should do pretty well.

  • Alternative Kanban Board Design

    It started with Twitter discussion. Then I followed with a post on standard Kanban board designs. Dominica DeGrandis added her perspective as well. By the way, there’s one lesson I have to take from Dominica and from discussion on Twitter – we need to show people different Kanban board designs so they don’t get fixated on a standard and just stick with it.

    In the meantime I was selling Kanban to my wife, as we both believed it may help her in coordinating projects, which is what she does at her workplace. An interesting part is that she works in land surveying industry – something completely different than our everyday reality in software development business.

    And after the discussion she comes back home and tells me that she has to show me something. It appears that it is a picture of her very first Kanban board. Out of curiosity I’m asking her about meaning of different artifacts on her board and it strikes me that she’s done exactly what we want people adopting Kanban to do: she’s used Kanban board examples I drew as, well, just examples. And then she’s come up with her original design reflecting her own constraints, which are pretty different than in typical software projects.

    First, the board.

    Now, that you ask, no, it doesn’t seem like a “standard Kanban board” whatsoever. Where is the process? Where are the limits? If these questions are your first thoughts than you are fixated at least a bit.

    You should rather ask how the process looks like. It’s a bit tricky as for each big task there are a few stages. There are these which have to go one after another, but there also are those which can be done in parallel. In short: process isn’t linear.

    What more, depending on a task process can be built out of different stages. Imagine that for one task you do the whole production, from idea definition to deployment, for other you do only development, and for another only testing and deployment. OK, now you have an idea how it looks like. In short: process isn’t homogenous.

    So the basic idea is that process is defined per task. It can be safely assumed that project manager, or whoever coordinates the work, knows how to cope with each task. What is the role of columns then? Priorities! The old idea of classes of service. The closer the task is to the left side of the board the more important, or urgent, it is to deal with the task.

    Different colors of index cards are used to mark different clients as it is somehow important.

    Then, we have a trick, which I like the most. As process depends on a task it is defined on the fly for each task separately and represented by small stickies attached to index cards.

    Stickies show stages, subtasks, you-name-it which have to be done to complete a task. Green one means the subtask is completed, yellow marks ongoing one, while red color is used for blocked work (which is sort of typical situation). Labels on stickies say what kind of stage/subtask it refers to. In other words they define the process.

    Instead of defining complex graph of all possible states with dedicated Kanban board for each state we just add needed stages as we go. Isn’t that agile?

    Another nice thing about this board is how limiting work in progress can be handled here. We neither have old-school homogenous process where we limit number of tasks per stage nor dedicated boards assigned to different people where limiting WIP is done per board. However we can easily say which tasks/subtasks are ongoing: yellow stickies tell us that!

    We can limit WIP by limiting the number of yellow stickies which are on the board. In a given situation it is actually something which comes very handy, as a number of people involved in doing work is changing pretty rapidly and limits can be adjusted on the fly depending on the current situation.

    What I really like about this Kanban board design is that is addresses all the specifics of the situation in a neat way, yet it is perfectly aligned with all the Kanban principles.

    And this is why I love to work on Kanban with people from outside of IT industry. Since their constraints are so different than ours they come up with fresh Kanban board designs as our standard solutions just don’t work for them.

    Advertisement: Want to have such nice Kanban boards in your presentations or blog posts as well? Check InfoDiagram Kanban Toolbox. Use pawelBBlog code to get $10 discount.

     

  • Don’t Stick to Standard Kanban Board Designs

    As I’m lagging a bit with my reader I read recent Jurgen Appelo’s article on networked Kanban yesterday. An interesting reading, especially that it ignited a few thoughts (and a great discussion on Twitter with Jabe Bloom, Jim Benson and a few others).

    First, Jurgen’s experiments with Kanban boards are perfectly coherent with Kanban principles. We are told to visualize workflow, not to use a specific Kanban board design.

    Second, value stream mapping, which is used as one of the basic techniques by many Kanban proponents, is limiting and it brings you back to a standard Kanban board design. David Anderson avoided using the term in his writings and it wasn’t without a reason.

    Third, we use examples of typical board designs as it is so hard to explain the whole thing without showing these examples, yet it makes people fixated on typical boards and eventually their board designs are suboptimal.

    Finally, I sometimes feel we actively harm people showing them standard Kanban board designs. We prompt them to use one of our well-done solutions instead of looking for the one which is adjusted to their context and reflects their process well.

    Now, this is tricky, we’d like people to start with a clean whiteboard and totally open mind and to come up with something which reflects the way they work, presents important information in accessible and understandable way. It is pretty open-ended task, isn’t it? Unfortunately also the one which may make people totally confused.

    I’m not sure if I’d even be on the Kanban land now if I was starting with such task. I was more than happy to use the most common board design as a starting point. Now I don’t have problems using uncommon designs (just wait to see my portfolio level Kanban boards) but yes, it took some time to get here.

    Either way, my message is: no matter whether you’re just starting with Kanban or are rather advanced don’t stick to standard Kanban board designs. If you have no better idea, use them – that’s what they are for. But please, please, please, don’t treat them as the one and the only way to visualize workflow.

    On a side note: I find it amusing working on visualization with people from industries different than software development. They aren’t constrained with the good old process of building things, which was being hammered into our heads for years, namely: analyze, design, build, test, deploy. And they often come up with uncommon designs on the very first approach. Quite a lesson for us I would say.

  • When Kanban Fails

    In my story from Lean Kanban Central Europe 2011 I promised I will elaborate more on my session there, titled Kanban Weak Spots. The starting point to the session was analysis of a number of situations where Kanban didn’t really work, finding out a root cause and then trying to build a bunch recurring patterns from that.

    By the way I have an interesting observation. Whenever I called for Kanban failure stories I heard almost perfect silence as an answer. It seems everyone is so damn good with adopting Kanban that it virtually never fails.

    Except I’ve personally seen a bunch of failed Kanban implementations. Either I’m the most unlucky person in the world and saw all of Kanban failures out there or for some reason we, the Kanban crowd, are still sharing just success stories and not putting enough attention to our failures.

    Actually, when I was discussing the session with fellow presenters we quickly came to the point that basically every time we think about Kanban failures it can be boiled down to people. However, and it is one of recurring lessons from lkce11, we should address vast majority of ineffectiveness to the system, not to the people. In other words, yes, Kanban fails because of people, but we change the system and only this way we influence people behavior.

    This is exactly the short version of the presentation, inspired by Katherine Kirk and Bob Marshall.

    There is the long version too. Symptoms, which show you that something isn’t working, and if you do nothing about them you’re basically asking for failure. I have good news though. Most of the time you will look for these symptoms in just one place – on your Kanban board.

    Probably the most common issue I see among Kanban teams is not keeping the board up to date. In short, it means that the board doesn’t reflect the reality and your team is making their everyday project decisions basing on a lie. A very simple example: given that there is a bottleneck in testing but it isn’t shown on a Kanban board, a developer would come to the board to see what’s next and they would decide to start building a new feature instead of helping to sort bottleneck out. Instead of making things better they would make them even worse, thanks to the board which isn’t up to date.

    I face the same problem but on a different level, whenever a team tries to make a board showing the way they’d like to work, and not the way they really work. Actually this one is even worse – not only do you make your everyday decisions basing on a lie again but it’s also more difficult to get things back on the right track again. This time it’s not enough to update the sticky notes – you need to fix the design of the board too.

    Another board-related issue would be forgetting about a good old rule: KISS. When people learn all these nice tricks they can use on their boards they’re inclined to use a lot of them. Often way too many. They end up over-engineering the board, which means that they bury important information under the pile of meaningless data. Soon, people aren’t able to tell what means what and which visual represent which situation. Eventually, they stop to care to update the board because they’re basically lost, so they’re back to the square one.

    Violating limits has its own place in hell. Of course it is a matter of your policies whether you allow abusing limits at all. However it is pretty common situation that it is generally acceptable that limits are violated very often, or even all the time. Now, let me stress this: limits in Kanban are the fuel of improvements; if you don’t treat your limits seriously you don’t treat improvement seriously either. Limiting work in progress is a mechanism, which makes people act differently than they normally would. When a developer, instead of starting to build another feature, goes to help with a blocker in testing it is usually because limits told them so. Eventually they learn to predict such situations and act even earlier, before they fill up the work queue. Anyway it all starts with simple actions, which are triggered by limiting WIP.

    The interesting thing is that all these problems can be seen on a Kanban board. The reason is pretty simple: the board should reflect the reality, no matter how sad the reality is. You deal with lousy process the same way as you deal with alcoholism: the first step is admitting you have a problem. Even if your process looks like a piece of crap show it on your Kanban board. Otherwise you’re just cheating yourself and you aren’t even starting your journey with continuous evolution toward perfection.

    There is however one driver of Kanban failure, which won’t be seen on a Kanban board. It’s also my recent pet peeve. Treating Kanban as a project management or a software development approach is basically begging for failure. It is asking Kanban to deal with something which it wasn’t designed for. It’s using a banana to hammer a nail. Seems funny indeed, but if you care about a success, well, then good luck – you’re going to need a lot of it.

    Kanban can be called change management approach or process-driving tool or even improvement vehicle but it doesn’t say a word on how you should manage your projects or build your software. If you don’t build Kanban on a top of something, be it a set of best engineering practices or project management method of your choice, you’re likely to fail miserably. And then you will be telling everyone that you need to have experienced team to start using Kanban and that it wouldn’t work otherwise.

    So here it is – a handful of risks you should take into consideration whenever adopting Kanban in your team. A bunch of situations observed by the most unlucky guy in the world, who actually sees Kanban failures on occasions. However, what I want to achieve with this post is not to discourage you to try Kanban out. Pretty much the opposite. I want you to think of this list and actively work to avoid the traps. I just want you to succeed.

    And this is why you will hear me writing and speaking about Kanban weak spots again.

    Now, even though I teased much of the content from my lkce11 session above, here are my slides.

    Kanban Weak Spots

    By the way, if you happened to be on my session in Munich please rate it.

    If you’d like to see some more content on the subject, fear not. As I’m very passionate about that I will definitely write more on this soon.

    Advertisement: Want to have such nice Kanban boards in your presentations or blog posts as well? Check InfoDiagram Kanban Toolbox. Use pawelBBlog code to get $10 discount.

     

  • Team Retreat

    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.

  • Learn! Or How to Get a Better Job

    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.

  • Visual Management

    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

    Visual Management

    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.

    Advertisement: Want to have such nice Kanban boards in your presentations or blog posts as well? Check InfoDiagram Kanban Toolbox. Use pawelBBlog code to get $10 discount.