Pawel Brodzinski on Leadership in Technology

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

Tag: process improvement

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

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

  • Internal Audit: Lessons Learned

    Last week we had an internal audit in our team. If you automatically think “ISO 9001” when you hear “internal audit” let me just state it had nothing to do with ISO. We have a few so called quality requirements in the company and every team should follow them but these aren’t anything like ISO procedures.

    The reason why I was interested how the audit would go is we work pretty differently than the rest of the organization so quality requirements aren’t really adjusted to our specifics. I was also curious how our non-standard process would look like in comparison to other teams.

    I caught a few things which are worth sharing.

    Small Features versus Big Features

    Our currency for functionality is MMF (Minimal Marketable Feature). MMF itself probably doesn’t tell you much and I know different teams use different sizes for MMFs. In our case average MMF can be coded by a single developer in about a week, so they are pretty small.

    On the other hand in other projects typical currency for functionality is requirement which is significantly bigger and, as such, less detailed. I’d say that on average it is few times bigger than MMF.

    Where’s the difference? I mean, besides the size itself. One very visible difference is we do significantly less paperwork. With features small enough that they can be easily analyzed and decomposed by product owner, developer and tester we don’t need to write low-level design documents or test cases or user stories. We can spend more time doing the real work instead of creating a pile of documents which tend to become outdated as soon as you hit the save button.

    Frequent Deployment versus Not-So-Frequent Deployment

    I guess there aren’t many teams which still treat deployment as one-time effort done at the end of project. But still, frequent deployment is a painful thing, especially when developers work in different team than QA engineers and QA engineers work in different team than release managers. An average project isn’t deployed biweekly. Not even close.

    On the contrary we deploy, on average, once every 9 days and I mean calendar days here. Of course it didn’t look like that from the very beginning and it cost us a bit to get there. I would say it took us about half a year to gain this pace.

    Where’s the difference? I could tell you about time-to-market, but it really depends on project whether you need time-to-market counted in days or months. The cool thing is somewhere else. With such a short cycle time we don’t have a temptation to incur technical debt. We don’t leave unfixed bugs. We just don’t. After all we might have been discussing about a single low priority bug, not a few dozens of them so the fixing cost would be so low that we don’t even start the discussion in the first place. Even if we hit a dead-end redoing the whole darn feature doesn’t take us a couple of months – it’s just a few days so it’s much easier to accept it.

    Everyone on the Same Page versus Formalized Process

    We’re small team and we’re co-located so we have fairly few communication issues. The process we follow is very simple and, what is even more important, crafted by our team. We all are at the same page.

    Most of the teams in the company follow more formalized process. There are different functional teams which are meant to cooperate, there are specific documents expected from each other by people working on projects etc. On the top of that there’s some office politics too and formalized process is used as a weapon.

    Where’s the difference? This one was pretty much a surprise for me, but it looks like our process appears as mature and effective even though it isn’t even recorded in any form. We just know what everyone should do. Whenever some obstacle appears on the way people naturally try to help each other as they see and understand what’s happening. And yes, I’m over the top just because no one forced me to write the process description down. On the other hand formalized process is often artificial for other teams who have to follow it and they sometimes focus on being compliant to the process (or fighting with it) instead of building software.

    What Does It Mean For You?

    I’m not trying to say here you should now automatically cut every feature you work on in half (at least), deploy three times more frequently than you do now and throw every procedure out. It would probably end with chaos, which your managers might have not appreciated.

    I’m not trying to say it was easy to get where we are now. It took great people, some experience, a lot of experimenting and enough time to get better at what we started doing. A year ago I would have hard time trying to point how our approach might be better than what you could find in the rest of the company.

    And I’m not trying to say you should read these advices in “this over that” manner known from Agile Manifesto. It’s not only our team which is pretty different than average team in the company but a product is also far from standard projects we build in organization so I compare pretty different environments. I wouldn’t even say that every single team in the company would benefit from implementing our approach, although a few of them definitely would.

    These are just things I learned while talking with Ola who audited our team (and many other teams in the company). For me these lessons weren’t obvious. I mean connection between frequent deployment and short time-to-market is pretty clear for anyone who understands what “deployment” and “time-to-market” means, but I’ve never really considered that very short production cycle may help to avoid technical debt too.

    And if you’re interested what the audit result was, I’d say it was pretty good. I mean, everyone likes to listen to some compliments from time to time, so we may want to ask for another audit soon.

  • The Kanban Story: Kanban Board Revisited

    Kanban doesn’t prescribe much – if you follow The Kanban Story you already know that. Kanban Board which is a key tool in Kanban isn’t pre-designed or something. You need to tailor your own. That’s how we did with our Kanban Board.

    We decided to start with something simple and then adjust things as we go. We redesigned Kanban Board because it is meant to be changed. But even then it wasn’t the final shape.

    When we left the board last time it looked like that.


    What was the problem?

    On a general level we switched to more frequent deployments. At the beginning we didn’t have any system in production but it has changed. Sort of. Anyway our endpoint was no longer “ready to ship” – we wanted to see new features live.

    Before the change we were marking MMFs as “in production” by throwing sticky notes out. The problem was there was no limit for “ready to ship” station, so features could wait there on a huge stack waiting for deployment. Something rather opposite to what we’d like to see.

    The other thing which pinched me was documentation. We had a stage for this purpose but it appeared we were documenting after we’d pushed feature into production. This was perfectly fine since we don’t sell boxes with up-to-date documentation inside and it was no problem at all to have documentation updated a couple of days after deployment. The problem was our Kanban board didn’t correspond with this.

    After playing with some ideas we came with version 3.0 of our Kanban Board.


    What has changed?

    The left part hasn’t changed at all. We were happy with it.

    The first change was merging “test” and “ready to ship” columns into one under the name of the former. What we got was testing stage which was separated into ongoing and completed phases. When a feature was tested it was ready to ship. We no longer expected documentation to be updated before shipping since we weren’t working like this anyway.

    Another thing was adding “live” column which means feature was successfully deployed. I didn’t like the idea of adding another “deployment” station since deployment is very fast in our case.

    Documentation was left as the last but one column and at the end “done” station emerged. After all it is such a nice name for a column.

    Limits

    Redesigned part of the Kanban Board reflected our workflow much better but required also limits adjustments. Instead of rethinking whether we should add 1 here and subtract one there I wiped out all limits and rethought them from the beginning.

    Limits of 3 for “todo” and 4 for “development” had worked well so they got their way back to the board.

    The next one, and the hard part, was limit for “live” station. Remember our pseudo-iterations? Because of this approach we deploy a few features at once. So far there were two or three in each package. However it happened a couple of times that an emergency feature was added during a pseudo-iteration. Since this kind of feature was meant be included in the same deployment package this made a maximum of 4 MMFs possibly being shipped at once. That’s how “live” stage got its limit.

    The same reasoning applied to “test” station. Since it was possible to move 4 sticky notes at once to “live” column, they all had to be taken from the previous one, thus we couldn’t set there anything less than 4. We didn’t want to set anything more either, so the lucky number was exactly this: 4.

    “Documentation” got a limit of 2 since it’s often convenient to document 2 corresponding features at the same time.

    Looks like we get more and more columns over time. I just wonder whether that’s a good thing.

    If you liked the post you may want to read the whole Kanban Story.

  • The Kanban Story: Implementation of Kanban

    So you want a story about the most painless implementation of new software development/project management methodology in industry history? Here it goes.

    There was nice afternoon, sun was shining and air-conditioning was silently humming. One of our engineers asked me what about this new methodology we were talking about a couple of weeks earlier. So I described them how it works in details telling basically nothing more than could be found in great Henrik Kniberg’s article on Kanban I mentioned earlier. It took definitely less than a half of hour, including Q&A.

    Then we drew our Kanban Board discussing which stages we wanted to have. More about creating our Kanban Board in the next post.

    The very next problem we have to solve was what exactly we want to move through out Board. We couldn’t decide on a color of sticky notes. I thought classic yellow would emphasize our respect for established rules of software craftsmanship while there were opinions that green would be better since it corresponds with stability of our software and flawless builds we get on our build server… OK, just joking here.

    Actually the problem was what granularity we’d use on sticky notes. MMF (Minimal Marketable Feature) is a nice concept but sometimes too vague. Generally we try to use MMF whenever it makes sense but sometimes we use non-marketable features as well. Example? When we had screwed something in database structure we got “fixing up a database” post-it. Unless you freaking darn good marketer this isn’t “marketable” at all, but pulling flawed database with the product all along the way would be kind of a pain in the ass. Fixing it later would cost far more than doing it fast. This substitutes being marketable if you ask me.

    To simplify things a bit we dropped using user stories. We decided using inside-out approach which in Tyner Blain article on agile prioritization is described as wrong one. The reason was most of the time splitting tasks in a way which was convenient for our development team created results which were identical with these achievable with outside-in approach (splitting tasks in a most convenient way for a customer). In these rare moments when it did not I could live with that and for me it maked development cycle more reasonable. Yes, I sure am biased with my past experiences as a developer or trying to play as someone like that.

    Anyway we ended up rather with old-school features describing (hopefully) fine-enough-grained functionalities rather than scenarios describing how user would interact with the application.

    Having this done we filled the Kanban Board with sticky notes showing what we were doing at that moment, what were planning to do and then we set up limits for each column. Again, more on this in another article about Kanban Board.

    Basic setup of tools was completed. The rest was to follow few simple rules, limiting WIP (work in progress) being the most important one.

    Basically Kanban was implemented and it wasn’t even a time of sunset, which we wouldn’t saw from our window anyway. We turned off air-conditioning and went home.

    I know things start to look interesting barely now but feel free to check out the first few parts of The Kanban Story.