Pawel Brodzinski on Leadership in Technology

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

Author: Pawel Brodzinski

  • Visualization: Don’t Get Attached to a Specific Tool

    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.

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

     

  • Give Honesty a Try

    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.

  • Kanban Leadership Retreat

    I spent last few days at Kanban Leadership Retreat. An original David Anderson’s idea was to gather in one place thought-leaders working on Kanban and provide them a platform to exchange experience, ideas and thoughts. I must say it kinda scratched my ego in its back to be invited.

    Anyway I’m still impressed how great the event went. I mean, I know that gathering some great minds in one place and giving them free beer (one evening only, but still) is a sure-shot recipe for a stunning success. To be honest, I did have high expectations. Basically all of them were exceeded.

    As the retreat worked as unconference vast majority of sessions ended up as discussions. There was little-to-none pre-prepared content which was both good and bad. It was good because it really enabled a lot of good discussions and thought exchange but there were moments when I’d appreciate a bit of structure, which is naturally brought by standard presentations.

    Personally I’d also prefer to see sessions a bit more focused on real-life stories than on meta-level but I guess expectations on this one differed.

    Anyway, volume of mind-blowing ideas I’m still trying to think through was astonishingly high. After all, what could you have expected after inviting all those though-leaders, and I take the word “leader” very seriously here, to the same place? By the way: you can definitely expect some of those ideas shared here in near future.

    Actually I went to the retreat with a goal to discuss a few of them: portfolio-level Kanban, Kanban failures and methods of selling Kanban to teams and organizations. Lucky me, each of them have made it to the event program. And basically each of the sessions looked totally different than I’d projected. This basically means I got a new, and unexpected, perspective on ideas I’d already had which, by the way, might make attending my future sessions on Kanban way more valuable, if you excuse this shameful plug.

    But all in all it wasn’t the content which was the most valuable for me. People were. I always say that networking is the most important part of any event but this time it was totally on steroids. The format of unconference, the choice of people and never-ending Icelandic days made it the ultimate networking event. If, by any chance, I looked as a child in chocolate factory please forgive me – I had damn good reasons to look so.

    I should probably mention all great folks I was talking to, which would be kind of boring for people who weren’t there, so I’ll refrain (BTW: if somebody is curious please check people I recently followed on Twitter). But if you are the one of them I’d like to genuinely thank you for all the stuff I learned from you.

    Huge thanks for organizing the whole thing goes to David Anderson and his staff along with Hillel Glazer, who facilitated the event.

    Personally I will be there next year. That’s no-brainer for me. If any of you, by any chance, is invited you shouldn’t hesitate whether it is a good idea to go even for a second.

  • Challenge your Rules

    This is the old lesson, but the one we need to learn over and over again. As managers we’re all about rules. We work like this and not like that. We do things in such and such way. We expect people to act like this. We forbid other behaviors.

    Nice. We can do it even worse trying to formalize all these rules.

    We need the rules not without a reason. If I want to be fair for more than a hundred people in my team I just can’t make every decision on the fly. Otherwise people would feel they’re treated randomly and the outcome of our discussion depends mainly on my humor or on the weather or whatever. If I want my judgment to be consistent over time I need to develop a set of rules, either formal or informal ones, so I can refer to them each time.

    The problem starts when we set these rules and never question them. Actually every time we trigger any rule-based decision we should take at least a few seconds to ask ourselves whether the rule is still reasonable or it is already good time to adjust it.

    Over past few months I could share a number of examples when I challenged and eventually changed my rules. Either because it appeared the rule didn’t work well or it had unplanned side-effects or there was a lot of resistance.

    And this is exactly how it should work. Our training policy was considered too harsh? Fair enough, we’ve just changed it. Recruitment process was considered sub-optimal? It doesn’t work that way anymore. We had a clash with managers regarding sharing specific information among them? Well, I won’t fight with everyone, so forget about this issue.

    The lesson here is: challenge your rules. Leading people isn’t about setting and following rules. It’s about adjusting to the situation.

  • Visualize Everything

    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!

    Advertisement: Want to have gorgeous Kanban boards in your PowerPoint presentations? Check InfoDiagram Kanban Toolbox. Use pawelBBlog code to get $10 discount.

     

  • Procedure Is Not an Answer

    I’m constantly getting frustrated whenever I see this behavior: people trying to set up some rules or procedures which tell everyone what to do in such and such hypothetical or unlikely situation. Who should tell me what to do when support engineer gets sick and can’t pick up the phone? Who is responsible for sorting our priorities when emergency screws our plan up? What should I do when another ash cloud hits our project.

    Well, I know what the wrong answer is. The wrong answer is: let’s write a procedure, or set up a rule, which tells us what to do so no one really needs to use their brains to find it out. Let’s write darn checklist for everything so we can tell that project couldn’t possibly have been screwed because we have a nice column of ticks on the list. It couldn’t have been, even when the only things we see at the moment are a totally pissed off client and burning brothel which we used to call “a project.”

    You just can’t have a rule for everything.

    Um, after a second thought, you actually can.

    The rule is: just follow damn common sense!

    Don’t know what to do? Find it out. Talk with people. Share your problem. Actively look for a solution. Take responsibility for sorting out the mess. As long as you solve the puzzle it doesn’t really matter whether you followed rules or whether there even were any rules in the first place.

    If you’re kind of a prophet and you know exactly what kind of issues you’ll be facing on October 4th, or any other date in future, go set up rules which will help you deal with these problems. However if you’re like normal people without hugely overgrown ego, let’s just agree that it isn’t possible to predict all the issues we might face.

    Let’s agree that we all are professionals who are willing to work hard, hand to hand with each other, on solving any shit we’ve got into. Let’s just agree we don’t need procedures or rules to deal with every single situation the future brings.

    Unless the only thing you look for is to deal the blame among others, that is.

  • Experiment!

    I have a question for you: when was the last time you did an experiment on work you do? I mean if you are a developer when did you try something new: new practice, new way of doing things, maybe new technology to deal with a problem? If you are a project manager when you tried to do your stuff differently? Maybe it was a different way of running a retrospective or moving a planning meeting to a cafeteria or something completely different?

    If you don’t have the answer at hand think about it for a while. It is kind of important.

    If you think that there is expected answer you’re right. The expected answer is “today.” I expect you experiment all the time. I expect you challenge the way you work constantly. I expect you put rules to a question every now and then.

    It’s a funny observation – as I go through different questions on PMSE I often see this pattern: “I follow this, this and that and I do have this issue.” Every time one of answer is: “challenge your rules.” You can bet this kind of answer will be there in a matter of hours.

    This doesn’t come up as a surprise for me. This is the lesson I get over and over again. What you know is wrong. Well, it’s wrong in a way that it isn’t the best, or the most optimal, way of doing things. So if you want to keep you saw sharp you need to look for ways to improve your toolbox constantly.

    Is there a better way to do it than experimenting?

    So please do one thing today: do an experiment on your toolbox, your rules or the way you build things. Change something and see how it goes.

    Then, make it a habit.

    And if you ask what kind of experiment I did today there were many of them: I was experimenting with approach we have to training, with tools we use to build applications, with Kanban at portfolio level and with team organization. And these are only things I touched in some way today.

  • Surprising Truth about Kanban Improvements

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

    Kanban Improvements – Emergent Behavior

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

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

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

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

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

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

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

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

    That’s not all.

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

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

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

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

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

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

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

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

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

     

  • The Kanban Story: Standard-Sized Features

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

    The concept is called standard-sized features.

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

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

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

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

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

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

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

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

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

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

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

  • Project Management in One-Man Project

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

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

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

    • Scope management

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

    • Task management

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

    • Product management

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

    • Communication with users and/or clients

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

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

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