Pawel Brodzinski on Leadership in Technology

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

Author: Pawel Brodzinski

  • Kanban Basics

    I often say that you can implement Kanban in your team in a single afternoon. That’s how we did that after all. So when Andy Brandt asked me to do Kanban Basics webinar I expected that preparing it would be pretty simple. How long can you talk about few-hour-long task?

    Well, it wasn’t as simple as I expected.

    Kanban itself is very simple. But telling people they should visualize workflow, limit work in progress and measure the flow isn’t really all the basic stuff they need to know. After a while it always ends up with questions how we do this and how we do that.

    What limits should be set on board?
    What happens when a bug is found during testing?
    Should sticky notes be moved back on the board at all?
    How cycle time is measured?
    What happens when the limit is reached?
    What to do when emergency task pops up?
    How to cope with multiple projects?
    Is feature-by-feature deployment mandatory?
    How estimation is done?

    That’s an interesting observation – I often deal with most of these questions at the end of my Kanban presentations, no matter if I cover basic or advanced material. After giving it some thought I decided this would be a good starting point to prepare Kanban Basics presentation.

    What I ended up is presentation below. It covers a bunch of scenarios visualized with (surprise, surprise) Kanban board. Additionally I used Scrum as the reference to make a basic Kanban description easier to understand.

    Kanban Basics

    If you have some basic questions which seem to be omitted in the presentation, please leave a comment. I’d be happy to both answer the questions and update future versions of the presentation.

    If you speak Polish feel free to watch the recording of the webinar.

    Also, check The Kanban Story series as it reveals all the details of Kanban implementation in my current team.

  • The Beauty of Kanban

    OK, I admit it. This is a biased post. But you should have known. I’m sharing our journey with Kanban for more than a year already and the journey itself is even longer. And I’m still not fed up with all that Kanban thing. But then, after days like today, I realize why I appreciate Kanban that much.

    Majority of you was in this situation before – you saw your team working on tasks as planned when someone came with that super-important, top-priority pre-sales project which totally required that your team added widget foo to some application. And it had to be done exactly then.

    What I used to do in those situations was anything between panicky search for least loaded engineer and panicky explanations why we couldn’t do that before requested deadline. Either way the word “panicky” was involved. In every situation the threat was the same: we had a lot of pre-planned work to do and needed no additional distracter so what we really hoped for was to get the salesman hell out with his damn pre-sales project.

    And now? Now I just put the task on the top of the stack. Well, I do if it is important enough of course. Then the magic happens. In vast majority of cases you get someone to start working on your damn widget tomorrow. Day after tomorrow if you’re less lucky. Glad I could help you that fast. Note: I didn’t tell you “at the beginning of the next sprint.” But now, the best part.

    It doesn’t ruin the way we work. We aren’t distracted by your drop in. It is the process we follow which allows us to deal with the issue so quickly.

    As I think about that, we hate all those unplanned tasks not because they’re unplanned (we know they’re going to happen after all) but because they force us to change our initial plans. If we had a framework which helps us to embrace those tasks in a way which is acceptable for our dear stakeholders (what a nice way to call salespeople, isn’t it?) wouldn’t that be worth trying?

    So what are you waiting for? Go try damn Kanban!

    Going to the meeting to tell business folks that you’re going to do your best adding all those crazy things they think they need to get the deal (and not lying on the same time) and then getting back to the team knowing that you aren’t going to change all their plans is priceless.

    And that’s the beauty of Kanban.

  • The Value of Certification

    The other day I had hot discussion about the value of certificates. We went through certificates for developers mainly but the issue is general: how much value certificates bear from the company’s perspective?

    The point where the whole discussion started was when we started analyzing what the most objective way to appraise engineers is. Typically organizations have some appraisal system in place – I don’t want to go deep into it as that’s the subject for another story. Anyway every such system is subjective as it bases on one person judging another. And the Holy Grail of many managers is to make appraisal system more objective.

    That’s where certification kicks in. Certificate is objective. One either passes an exam or not. It’s not her manager who says “she knows Topaz on Tires at 8 out of 10… I guess.” There are some standard criteria which say whether it is 89% or 23% or whatever.

    Then certification process is run by some external entity which isn’t biased so certificate is a kind of independent evaluation. Guys from certificating entity don’t really care if a specific individual passed the exam or not, at least as long as they have steady flow of incoming candidates to be charged for certification process.

    Where’s the problem then?

    It seems certification evaluates people independently and is objective. Unfortunately it’s also pretty much useless.

    The problem I have with vast majority of certification programs is that the only thing people are taught while preparing to earn the certificate is how to pass the exam. They don’t learn how to be a better programmer or a better project manager or how to deal with a specific technology. They basically learn what question schemas and standard answers are.

    You get what you measure. If you measure how many certificates people have you will get “many” as the result. Would that mean that you’d improve skills of your teams? No, not really. So my question is: which problem are you solving this way? Except of course having a huge pile of certificates.

    And by the way the real issue of subjective appraisal system is not system’s subjectivity but lack of trust between senior management and appraisers. “I don’t trust your evaluations so I’ll cross-check them with some certificate.” Well, I’d prefer to work on building trust relationship instead. But maybe it’s just me…

  • Being a Leader

    Recently a subject of leadership pops up on Software Project Management pretty often, but usually I look at it from manager’s perspective. After all that’s something I do for living – managing teams. So yes, being a leader is the first and probably the most important role of manager (by the way, the post on role of manager turned into full-blown presentation which causes some buzz every time I deliver it). But leadership isn’t exclusively attached to management.

    We are leaders in our workplaces, but we lead in different communities and informal groups as well. And even if we stick to our professional lives we can lead in technical areas or be typical people leaders. Leadership has many names. This was exactly the theme of my recent presentation on the subject which I delivered as a guest on Toastmasters contest.

    Being a leader

    A very interesting discussion followed the session. I used leadership definition I’ve heard from Mary Poppendieck: “Ability to attract followers is exactly what makes you a leader.” The definition neatly covers all sorts of tech leads – if I believe you’re knowledgeable and experienced person in a specific area I will come to pester you every time I need help with that matter. In other words I will follow you, which according to definition makes you a leader.

    The argument against that approach is that we call it authority and not leadership and leadership is/should be discussed from a perspective of leading teams/groups. I can’t say I agree with this point of view as we’d have to cross out many leaders who build their follower base thanks to extraordinary knowledge and technical skills. What do you think?

    By the way, after criticism I faced on my slides from AgileEE I built this slide deck differently. Happy now?

  • The Kanban Story: Moving Cards Back

    This is the question which I hear very often: should we move back cards on the Kanban board when we realize the feature isn’t that advanced as it looks like? A typical example may be about feature which has been developed and is being tested and it appears some bigger patch has to be applied. Another, more interesting one, may be about feature waiting for someone outside a team, i.e. waiting for client’s decision.

    So, coming back to the question, should we move back cards?

    I always answer that is isn’t forbidden, so it is a subject of rules agreed by the team, but I don’t think it is a good idea. Consider a simple situation:


    You have development column full and it appears one of cards from testing should be moved back, so you break the limit. On the other hand you don’t want to move the card back to todo column since it isn’t a feature which is 0% done. It just has to be changed or has to wait for something before a team can perform further tests.

    OK, the simple answer is that you should avoid moving cards back and do whatever it takes to clear the feature out of the board while the card stands where it is. As long as you have all the tools to do the job this approach works pretty well.

    However, sometimes you don’t have control over the feature anymore. One of teams I’m working with has pretty complex deployment process. To make the long story short we have to wait until the customer performs some task to be able to move further. The part of the process is out of our control. Be it waiting for clarifications regarding a bug or completing acceptance tests for a feature to give a couple of examples.

    Now if we put features we really work on along with those which were waiting for some external input in the same column we’d end up with crazy high limit. That is as long as we cared not to break them every now and then. We may have a couple features which we are actually fixing and a dozen of them which are waiting for client. And setting the limit of 15 doesn’t sound like a good idea if you ask me.

    We solved the issue by setting additional todo queue within the column. It works as priority queue, so if we look for features to work on we consider cards from the priority queue first and only then from the previous column.


    Feature B would be taken before feature D. Additional trick we needed was to visualize which features in priority queue were ready to go and which were still waiting (small sticky notes attached to cards can be used for that).

    Thanks to this approach we can have reasonable limits in every column we have control over. What more, mechanics of the board forces us to finish the older tasks first. If there is a task in priority queue which isn’t blocked anymore it we start working on it before we move to regular stuff.

    The downside is we have some hidden work in progress which isn’t limited in any way. But at least we make it visible and get rid of it as soon as possible. And we don’t move cards back which always create some mess.

    One final advice: if you face this kind of situation once a year don’t bother to rearrange the board. You will need adjustments if, and only if, it is a common issue in your team.

    Read the whole Kanban Story.

  • Embrace Failure

    I failed. It wasn’t very spectacular. Well, if I asked people around they wouldn’t even say it was a failure, but for me it was below-average performance. Thus failure.

    Did I feel bad? I did. I couldn’t help. I knew I shouldn’t but after all I’m just a human. But then I consider it as much better thing which happened to me than just another success. Why?

    Because we don’t learn from successes. We learn from failures.

    When we achieve success it’s like someone was telling us “you’re great, no need to change.” And there is a need to improve. Always. The thing is we usually don’t see it unless we fail.

    The trick is to embrace failure. Welcome it warmly. It is your ticket to another learning session. Yes, you will fill badly for a while, but in the long run it is more valuable than success.

    Failure is an eye-opener. Suddenly you see what you were doing wrong and you don’t understand how blind you’d been not to spot it earlier.

    Failure is a kick in the butt. You feel bad so you know you have to do something to avoid this unpleasant feeling next time. Unless you’re a masochist and you like to feel bad.

    Failure is a helping hand. You get some guidance what you should improve or what you should avoid.

    We are told we should embrace change. I see no reason why we shouldn’t embrace failure.

  • So You Promoted Wrong People to Management, What Now?

    It seems recently I’m telling you a lot stuff about people management and managers in general. If describing the role of manager wasn’t enough you could also read a rant about screwed promotions which we see so often. This all stuff is good (yes, such a shameless self-promotion), but it assumes one optimistic thing: you can still make decisions who will be promoted to management.

    However sometimes we don’t choose who is promoted to managerial positions. These decisions have already been made and they’ve been made wrong. If your task is to deal with that you’ll need to follow a three-step scenario.

    1. Coach

    OK, great engineer doesn’t make a candidate for a great manager. But it doesn’t make you can’t make a good manager out of great engineer. The trick is to raise awareness that someone doesn’t perform well as a manager and coach them to improve their people skills. Help them to change their focus from engineering to people management. However this effort can’t be unlimited. If someone isn’t willing to change you won’t force them. Then it’s time to move to the point number 2.

    2. Find a better place

    If someone excelled as an engineer and you can’t make a good manager out of them you might try to move them back to some engineering-related role. Maybe design, maybe architecture, maybe even project management would be a good place. It all depends on an individual case. Of course it is tricky – what you basically do is you move someone back from management to engineering, so you better have pretty prestigious engineering roles. And do it if, and only if, you believe the person would perform well in a new role. If you can’t find such role or leaving management isn’t really an option all you’re left with is a solution number 3.

    3. Let them go

    If you can deal with an issue other way you should let wrong people go. And yes, this means you’re losing a great engineer, who unfortunately became poor manager and is unwilling to switch back to the role which he performed well at. What you’re left with at that point is either to keep someone who do crappy job, which also affects their team, or to let them go and find possibly a better candidate. Well, if we discuss someone who failed at points 1 and 2 of the plan I’d let him go. As harsh as it sounds it is a good decision for both of you and for the discussed team.

    Keeping poor managers is much worse than admitting you’ve made wrong decision promoting them in the first place.

    And if you want to see more stuff about being a good manager you will appreciate my recent presentation titled Good Manager, True Leader, which I delivered at our internal company conference.

    Good Manager, True Leader

  • How to maintain backlog?

    In one of recent postings I asked you how big your backlog is. My argument was that trying to enforce small backlog size is counterproductive. Although small backlog is easier to manage throwing things away from it just to keep it small isn’t the best idea.

    However that doesn’t mean you shouldn’t do some backlog maintenance from time to time. What more, applying a few simple rules can help you to manage backlog easily despite its pretty big size.

    Keep epics, split late

    Sometimes we add to our product a big story. An epic. It is actually pretty interesting example in terms of sizing backlog. Why? Well, no matter if you split the epic into a list of smaller stories, i.e. sized similarly to your typical features, or keep it big you add a huge piece of work. A piece, which usually makes sense as long as it is completed as a whole. So yes, you need quite a capacity to add the feature, no matter which approach you choose. What do you do if your backlog is limited?

    Anyway, my advice is to keep epics in backlog as long as possible and split them in the last responsible moment. It is aligned with agile late design approach but that’s not why I advise you so. Actually as long as you don’t start working on the epic there’s no reason to keep a dozen of sticky notes on the board instead of a single one. It’s enough for you to look at epic to know roughly what is to be done. You will need more details when you start development of first epic-related feature so no need to worry at the moment.

    It is easier to reprioritize the epic over and over again if it’s in one piece. And reprioritizing is the most common task when it comes to managing backlog.

    Groom from time to time

    If you have spacious backlog you will face this situation on occasions: you will find out that one or more features waiting in the backlog are no longer relevant. Maybe you’ve changed the goal of your app or you abandoned industry which was addressed with the feature or you just don’t have a faintest idea why you wanted to build the damn thing in the first place. Either way it’s time to forget about it.

    Grooming backlog is a great occasion to do that. What exactly grooming is? A simple process of reviewing all features in backlog to verify their relevancy. Yes, if your backlog is big it takes time. But after all this is the way to make it at least a bit smaller, thus more manageable. And you don’t do it every week as you don’t change general plans for your product that often.

    Group features

    There’s an observation which can be helpful as well. Unless we work on maintenance project where priorities are usually set by the client we tend to build groups of similar features and not randomly choose one from here and another from there. Grouping features which are similar or features which touch the same parts of code can be helpful in terms of prioritizing work. Once done you can just throw in another feature from the group instead of scanning through the whole backlog to look for a relevant task to put in todo queue. That is as long as your general priorities don’t change.

    Grouping features also helps in prioritizing whole backlog. Instead of considering each and every feature separately you decide on a group which means you use the same time to judge a dozen of tasks you’d use to judge a single task otherwise.

    Dealing with big backlog isn’t that hard after all. All you need is some order and a few rules which help you to organize a long list of tasks somehow.

  • Specifics of Voluntary Projects

    Recently I told you about TEDxKrakow and how great idea it is to get engaged in a project like that if you want to get some experience in project management.

    No one commented that voluntary projects can’t be exactly the same as typical commercial projects even though I pretty much expected to hear this kind of argument. I did because it would be well-grounded. Voluntary projects are specific because, well, they are voluntary.

    OK, so where are differences?

    • No managers. No one is a boss. No one can just tell others they have to do something. There is no easy path. You have to earn your power before you can use it. People won’t start listening to you just because you are able to talk loudly. You have to show that you are doing at least as much by yourself and/or earn their trust before you start shouting your orders all over the place.
    • More talking. Talking is easy, talking is cheap. Unfortunately talking doesn’t get things done. People tend to throw great ideas as long as someone else is supposed to make them real. Unfortunately it sometimes turns into much talking and little doing as there isn’t really a business client who would make quick decisions on what is must-have and what is nice-to-have. A pretty good playground for doers I’d say.
    • More freedom. Unlike in typical projects you actually choose what you’re going to do. It’s like the open auction – I have this and that tasks unassigned, who’s going to take them over? Specialization works pretty similar though – we tend to choose things we are competent at and avoid those we suck at.
    • It’s easier to shine. In voluntary projects no one wants to get all the credit. After all it isn’t a place where people are going to build their whole careers. Chances are good that your effort will be properly credited. Just choose your tasks wisely and then deliver what you promised to deliver. Since in voluntary projects over-promising is just as common as in all others it should be enough to make you stand out.

    There is one more thing. It is real fun to be a part of this kind of project. But, after all, I’m not sure if it is a general rule or TEDxKrakow I used as example is fun to work on or fantastic people I met in this venture made it so. Or maybe all above are true.

    And if you haven’t yet registered to this fine event do it while you still can.

  • Implementing Change

    The other day I was asked to discuss how we can improve the way one of our software development teams works. Well, actually it was rather something like “Pawel, help us to implement Kanban” but, as it soon appeared, it wasn’t that simple.

    A typical discussion about implementing Kanban

    Me: So where do we start?

    Colleague: Um, I’m not really sure if Kanban is really for us. Convince me.

    Me: I don’t want to. If something doesn’t suit your team I’ll be the last person to convince you to implement it.

    Colleague: So where do we start?

    Me: Maybe with problems you and the team have. I guess there are some otherwise we wouldn’t be talking now.

    It isn’t about applying recipes

    The discussion changed its course. We immediately switched from discussing Kanban to talking about issues and looking for a solution which would be suitable in each and every individual case. If one of problems is people don’t want to have yet another place to do task management, and they can’t abandon either of current systems, introducing Kanban board may not be as great idea as it initially appears.

    If you start discussion with the conclusion already fixed in your head you will not only miss opportunities to improve but you also risk applying the wrong cure and making the situation worse.

    It is OK if you just don’t know

    A couple of times through the discussion I came up to the point where I had no idea what the right solution might be. And this is perfectly OK. It’s not about playing knowledgeable person. It’s about giving the good advice or not giving any advice at all.

    What more, admitting that you don’t know the answer is just a starting point for digging deeper. Each of these moments triggered some changes in our analysis. If we can’t go further here, maybe we should try there. Let’s stop talking about techniques which may or may not work and make a fast-paced Q&A session about potential issues the team may face. Or maybe let’s do mental walkthrough of processes the team covers.

    As it appeared each time we admitted that we don’t know helped us with coming up with a reasonable conclusions at the very end.

    Adjust tools for people, not the other way around

    When you know some method or approach and it works fine for you, you are always tempted to apply it in other environments too. The problem is other environment means other people. As a result your approach may not be so great anymore.

    But who said you can’t change the approach? Are methods we use some kind of dogma? Actually choosing a subset of techniques or practices from any given methodology is usually better than not using them at all. And if you choose wisely even a couple of small changes may yield significant improvements. So yes, do adjust methods before applying them.

    That doesn’t mean people shouldn’t change ever. Of course they should. But motivation to change should be intrinsic and not enforced from outside, i.e. because manager told so.

    A funny thing is that with this approach you can end with similar conclusion to the one you started with. The difference is now you are more likely to succeed as, even though you aim at the same target, you will choose different way to get there.

    And in case you were curious, yes, we eventually came back to Kanban.