Pawel Brodzinski on Leadership in Technology

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

Author: Pawel Brodzinski

  • 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.

  • One Measure to Appraise Them All

    Once your organization start talking about performance reviews you usually hear about some formal system with the same structure for everyone involved. That doesn’t really sound like a good idea, right? Why companies are using this approach then?

    If you have like a couple hundred people on board C-level exec can’t really say anything reasonable about vast majority of people in the organization. However leaders have to make some decisions basing on employees value, like firing rotten apples or promoting best candidates for managers.

    This is the point where management is tempted to build an appraisal system which makes it possible to compare people easily, so all these decision can be made basing on hard data. The system ends up as stiff and structured checklist which produces grades in the same categories for each employer.

    And this is utterly wrong.

    Actually I believe you can hardly do worse. This approach not only makes an illusion of producing comparable results but also harms relations between managers and their subordinates since performance reviews following this pattern just suck.

    Do a simple exercise: take a description of a few requirements and send them out to a bunch of managers working in software development teams. Now ask them to judge each feature in a few categories in a scale from 1 to 5. Let them judge difficulty, work consumption, innovativeness and business value. Grab these numbers from managers and compare them.

    You will see that someone hit average of 3,5 and another barely 2,5. You will see how differently people look as specific categories. You will see how vague one-word category definitions are. Basically, you will learn what subjectivity means.

    Now, I have a message for you: people are hell lot more complex than software requirements.

    If you used the same system for people what you would get is a set of top marks for a handful of organization’s gurus, handful of worst grades for a bunch of incompetent slackers and like 90% of random results for the rest of people.

    In uniform appraisal system this is taken as reasonable data which decides on a number of things, starting with promotions and money and ending with general respect. These numbers make or break careers. And yes, I’ve just called this data random.

    But that’s not the worst thing which is introduced by uniform appraisal system. Yes, it can be worse.

    Formalized, homogenous appraisal system degrades performance review to simple mark trade instead of making it an occasion to exchange feedback.

    You get what you measure. If you measure few criteria, and these criteria are uniformed among the organization, you create incentive to fight about better marks, so people would get more money, have better chances for promotion and would be able to boast in front of their colleagues how cool their marks were on the last review.

    There is a side-effect too. This approach creates an incentive for managers to run crappy reviews. Instead of focusing on two-way communication, learning what motivates their people, they just go through a simple script: programming three, communicativeness two, quality four, team work two, creativity five, next please. Hey, this is what the system expects from us, doesn’t it?

    Running performance reviews is pretty damn hard job. I always feel stressed when I’m going to talk about one’s performance, no matter how official or unofficial it is. Yes, it is easier to just go through a number of marks and call it a day, but that’s not the option which works for reviewed people. Unfortunately not everyone understands that, so we should build systems which create incentives for positive behaviors, not the negative ones.

    So while I don’t agree that performance reviews are evil in general, we can hardly think about worse approach in this area than a formalized, homogenous appraisal system which unifies measures among all employees. That’s just not going to work.

  • Hyper-Productivity Is Not an Issue

    These days wherever you move you hear a lot of buzz words. People manager, are you? There’s one for you. Oh, you are more into leading projects, I understand. Try with hyper-productivity. You will definitely hear it here and there. Well, maybe it is a way to go?

    For the sake of this discussion let’s consider there are no well-grounded doubts about figures standing behind the idea. Let’s consider hyper-productivity was never called bullshit. Let’s consider you can make your team hyper-productive, whatever this might mean. But before we come to this I have a question.

    Why, the hell, won’t you make your team just productive in the first place?

    The problem I see over and over again isn’t with teams which are performing very well and struggle to improve even more. The problem is an average team can hardly be called productive. Just productive.

    We keep wasting our time because we organize our work poorly. We face way more interruptions than it is necessary. We don’t really care about making our estimates a bit better to avoid panic (and counterproductive) rescue actions at the end of the project. We hire, and then keep, people who don’t give a damn about learning. We promote wrong people who are living proofs of Peter’s principle. We keep making stupid lists of examples just to prove the point which everyone agrees with from the very beginning (well, that might have been wrong example).

    No, hyper-productivity isn’t an issue. If we were able to make average team just productive we’d see hyper-productivity paradise. If you want to optimize system performance you don’t make champions even better – you work to get average majority to another level.

    So don’t tell me how to make my distributed team hyper-productive. Give me an advice how to make a bit more fun out of our mundane tasks or help me improve my recruitment skills instead.

    Hyper-productivity shouldn’t really bother us, even if it isn’t just a buzz word.

  • The Kanban Story: Small Tricks Do the Job

    On my AgileCE presentation on Kaban I said that if your Kanban board doesn’t evolve over time you should treat it as a warning sign. It possibly means you don’t improve workflow. And since there’s no by-the-book implementation of Kanban you should experiment all the time.

    So what has changed on our board recently?

    I can start with things which remain the same – this time we didn’t change structure of workflow. Columns are exactly the same. Limits stand still. But you shouldn’t consider at Kanban board being just a list of stations with appropriate limits attached. Kanban board is a single most important tool you use in Kanban. You look at the board a number of times daily. The more you see there the better is the board. This doesn’t mean we should make our boards completely cluttered. After all, if there’s too much in one place you stop seeing anything but clutter.

    OK, you already know we added something to the board. A few things actually.

    • Different sticky note colors. At the beginning we were working mainly on a single project. Recently we forked our efforts and now we work on 3 different applications. Getting separate color of sticky notes for each project was no-brainer.
    • Blocker flag. Visual mark of blocked feature is a small red sticky note attached to the main card. This is another obvious trick. We added it when we faced the first issue being blocked by external source.
    • Color magnets. We use whiteboard as our board. To make it visible who actually works on specific feature we put color magnets on sticky notes. Each team member has their own color. (Mine is white since I’m such an innocent guy.) Magnets give us quick information about load of each of us at any given moment. Besides, they keep cards from falling down.
    • Dates. We write two dates down on sticky notes. First when we start working on feature and another when we’re finished with the task. We keep forgetting about these dates, since this is pretty fresh idea, but that’s not a problem to fill them after a couple of days when we still remember well when we started/finished work on MMF. This trick helps me to report retroactively cycle time. Earlier I had to dig for information in task management system.
    • Numbers. Each sticky note has its own unique number. This makes it easy to link anything with MMF. A bug? We start with a number and everyone instantly knows which feature is defective. A task? We start with a number and we know which development tasks are related with MMF so we can tell how much work is remaining. We even use them in discussions: “Have you finished ninety seven yet?”
    • Excel sheet as backup. One day I thought what would happen if our cleaning lady would, well, cleaned our board. Man, we would be doomed. So I made simple sheet where I add information about every sticky note, which makes its way to the board. It is also a place where I store information about cycle time etc so it serves as reporting tool too.

    None of these improvements is significant. A few are pretty obvious. Yet when we were starting with Kanban we didn’t use any of these small tricks. They emerged as tiny improvements of the board and the process. And these small tricks do the job. Even though neither of them brings much value on its own they add up and make the board significantly better.

    As additional reading learn how our Kanban board evolved. Check out the whole Kanban Story too.

  • The Ultimate Competence Test versus Deming

    My recent post on verifying competence triggered some reactions, one of them being specifically interesting. Bob Marshall pointed that my idea of competence test isn’t congruent with Deming’s teachings, namely 95/5 rule.

    Deming says that 95% of performance is attributable to the system and only remaining 5% can be attributed to individuals. Does it render the question “Would you hire a discussed person to your own dream company to work in the same role?” irrelevant?

    I don’t think so. The question isn’t really a very generic one and there are a few assumptions made already before you ask it.

    • You have control over the system. Actually the question is about your own company, which means it isn’t some hypothetical organization or random system. We’re discussing the organization you’d like to have. The best possible one you can think of. Besides, you will have a chance to improve the system too.
    • The system is the same for everyone. We don’t discuss best possible performance in the world (whatever that would mean) but performance of different individuals within the same system, namely your company. This means the only differentiators which come into play are individual traits and individual performance.
    • We compare similar systems. Even though we have in mind our dream company we shouldn’t assume it would automatically be top-performing system. If we worked whole professional life in average systems what we are likely to achieve is slightly-above-average system. The change between two organizations (current workplace and our company) won’t be as dramatic. Theoretically it is of course possible, but not likely.

    Besides, what we look for in the competence test isn’t aimed at finding the best performing work environment. It is aimed at finding the right people. Of course I silently assume you won’t hire wrong people to do wrong jobs. I would probably hire none of great developers I know if I started a restaurant.

    If I’m not clear enough let’s go through an example. There is Mark the Coder who works for yet another average software shop. Mark the Coder stands out, at least at his current organization. Now let’s hire Mark in another average software shop. Would he still stand out? Pretty likely.

    OK, so now hire Mark in low-performing company. His personal traits which made him shine in the original organization will play even more important role as the background is worse. Would he still stand out? Yes. Would he perform better than in original situation? Rather not. Actually relatively he should perform worse, but he would still be considered as great performer in his new environment.

    What happens if we hire Mark in high performing organization then? He will likely perform better, as the system itself performs better, but it isn’t so obvious whether he will still be considered as one of top performers. Why? First, high-performing organization is a competitive background for personal traits and second, high-performing organizations tend to draw many top performers making it more difficult to stand out. Either way Mark the Coder should cope with the new situation, even if he loses the guru plaque.

    I know that what we really consider asking the question “Would you hire that person in your own organization?” is the last scenario, which is also the one with least obvious outcome. However if someone has a chance to become a top performer in the new high-performing system it is likely the one who was already among top performers in the old organization, thus Mark the Coder serves as a good candidate here.

    So no, I don’t find the ultimate competence test conflicting with Deming’s teaching. Do you?

  • The Ultimate Test of Competence

    Every now and then we judge people we work with. We go through performance reviews, we recruit and we chat over coffee or beer backbiting our colleagues.

    We use different metrics to make our judgment, anything from formal appraisal process to gut feelings, which renders the results incomparable. There is however one method you may use to decide about competence of different people, from junior team members to your managers.

    The ultimate test of competence:

    Ask yourself whether you’d hire the person to your own dream company to work in the same role.

    If the answer is “I don’t know really” you should count is as “no.”

    If you’d pay someone your own money to have them in the team and in the company it is obvious indicator telling that you consider the person as competent, non-toxic and cooperative. The same situation is with leaders – if you’d like to hire someone as a manager in your dream company they can’t suck. Or do they?

    If you ask me, I’d hire my whole team in my own company. After all, this isn’t the first organization we all work in.

    Now think how many of your current colleagues and managers you’d want to see as a part of your own business. I’m curious to hear your answers.

  • We Achieved This but I Screwed That

    I was a part of an interesting dialogue:

    – Pawel, tell me about your last success.

    – The last launch went flawlessly which means the way we chose to organize the project proved itself as pretty damn good.

    – OK, and what about your last failure?

    – I feel I can’t get through with ideas on improving the organization.

    Now the good part isn’t really me answering these two simple questions, even though I think it is a great idea to ask your people from time to time about their successes and failures. The good part is something I caught myself at after a while.

    It was our success and my failure.

    And the better part – it is not just about words. It is about the way of thinking. I might have said I had chosen our methodology and probably no one would have noticed. But what you say isn’t as important as what you believe.

    If you just switch words to the right ones you will achieve something important – recognition in front of execs is quite a token of motivation after all. But if you really believe in what you say you’ll achieve much more. You’ll always act as the success was an effect of collective effort, not only when you are in front of senior management. Besides, it was an effect of collective effort, wasn’t it?

    So tell me, what your last success was. And how about your last failure?

  • You Need (More) Team Buy-In

    I discussed recently changing the process in one of teams in the organization. In theory everything is totally easy. We need to assess current situation, find out what should be changed to improve the way the team works, apply new ideas and support them over some time to make them persistent and then go for a couple of beers and congratulate each other a stunning success.

    In this specific situation we have already a couple of ideas which should help. And yes, they include K-word. Yet still the plan is to start as we didn’t know much about the team. We try to act as the hammer wasn’t the only tool in our toolbox, even though we do have a hammer too.

    Once we know what is wrong we can apply a cure. And that’s where the hard part begins. If you look at typical pattern of change implementation you will see that the first period after inviting change sucks. People don’t know yet how to work with the new tool, process, rule, you-name-it. Outcomes are likely to be worse than with the old approach. After all, no one said changes are easy.

    Now, here is the trick: if you’re trying to implement change you not only strive to overcome typical issues but also have a reluctant team, which doesn’t want any change at all, you’re going to fail.

    People will get enough arguments to abandon change and if all they want is to get back to the good old way of doing things they will use this chance. What do you need to do then?

    Get more team buy-in.

    Actually this is what you should start with. When you assess current situation you talk with team members. If you don’t talk with people your assessment stinks anyway and I don’t want to touch it even with a stick. Use this opportunity to get people buy-in. You will need every single supporter you can have when issues start popping out.

    Don’t implement change unless you’re able to convince people it is a reasonable idea which would help them and you really don’t try to make their lives more miserable. Even if you personally are convinced that you have a silver bullet which would change your crappy software house into another Google, only better, you won’t win against people who have to follow your process, execute your idea and deal with all of side effects of a new situation.

    When I read discussions about some approach, which appears to be working rather poorly, the first thing which comes to my mind is lack of buy-in among people who are affected by the change. In terms of implementing agile we often forget that problems seen within development team are often triggered outside, likely by management. That’s why, for the purpose of this article, I use term “team” to name everyone whose work will be significantly affected by the change.

    Anyway the pattern remains the same. You just need more buy-in. You may need to work on this with development team but you may need to work with management too. Whichever case is true in your situation, go fix it before you start implementing change. That is, unless you find it pleasant to fail.