Pawel Brodzinski on Leadership in Technology

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

Tag: failure

  • When Kanban Fails

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Kanban Weak Spots

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

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

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

     

  • Definition of Done

    Shim Marom’s post on (low) value of industry reports launched an interesting discussion in comment section, which I took part in by the way. The point we reached was how we define whether the project is completed or not.

    And here we come to the definition of done, term which I learned from Glen Alleman.

    On Time, On Budget, On Scope

    A definition which you will hear most often is project delivery on time, on budget and on scope. And there comes a problem. If we overrun a budget for ten bucks are we still on budget or not? What about thousand? Or hundred thousand? Depends on project, right? So what about 0,1% budget overrun? 1%? 5%? Where is the border between success and failure?

    Note: I haven’t even started with time or scope.

    While this definition sounds nice it hardly responds to typical complex project environments.

    The Story of Changing Goal

    I love the Apollo 13 story. Not only because it is a great story about heroes, but also because it is a great story to learn about project management. If I asked you what was the original goal of Apollo 13 mission probably no one would answer correctly. But well, they definitely hit the space for something more to become a base for a Hollywood movie or to coin one of the famous quotes (one of famous misquotations actually). The thing we remember is that Apollo 13 mission’s goal became saving astronauts’ lives. And we all consider it a huge success.

    Were original goals accomplished? No. Probably neither of them. The money was spent however. Probably more than planned because of unexpected problems. But over the course the goal has changed.

    Recently I’ve read similar story about Sir Ernest Shackleton’s Antarctic adventure. It is 18-month long story about fighting for people’s lives. And again initial goal, which was crossing Antarctic continent, was rendered invalid just after several days and the main problem became coming back home in one piece. Thanks to his commitment and determination Shackleton was successful in rescuing every single man from his expedition. Considering conditions a stunning success.

    Was Shackleton able to pass the Antarctic? No. Failure then?

    Maybe You Tell Us About Real Projects…

    You may say that those stories aren’t about typical IT projects which we deal with everyday. Yes, these are extreme examples but the same pattern we see very frequently, but in a bit different scale. Hey, that’s what embracing change is all about. We try to adjust the course of our projects to make them better respond to clients’ needs.

    After all I don’t believe all projects you took part in were specified perfectly at the beginning and carried through relentlessly to the end according to unchanged plan. My wild guess is only few of you had a chance to work on at least one project which looked a bit like that (and yes, Glen is probably among those few).

    Clients often deliver some wishful thinking as requirements, and then vendors go through them only roughly and come up with a generic document which describes fuzzily what should be done. No surprise the real goal appears to be changing over time as everybody realizes all the assumptions and gaps in initial plan.

    Definition of Done Is Changing

    OK, so goals are changing over time. So is definition of done. We usually do a crappy job defining done. But then we’re even worse in adjusting the definition along the way. We change expected costs and schedule. We change scope. Do we change our definition of done as well?

    I mean unconsciously we do, that’s for sure. After all we’re able to follow our gut feeling and tell this project was a success and that was a failure. We know that major schedule slip will be quickly forgotten if delivered software exceeds expectations. We know that being on time on budget and on scope isn’t a reason to boast when the client doesn’t use the system at all for some reasons.

    So yes, we should know what done means in each and every project. And no, we won’t have a single, universal definition which we can use against all our ventures. It is a very individual thing.

    That’s by the way the reason why the industry reports on state of projects will be criticized over and over again. There just aren’t universal measures which would be widely acclaimed.

    http://main.wgbh.org/imax/shackleton/about-one.html

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

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

  • Managers Are Clueless

    So you’re a manager. You even think you’re pretty damn good manager. Fine for me. Do you remember Pointy-Haired Boss? Yes, that clueless manager from Dilbert cartoon. You have this guy sitting in your head. So do I, by the way.

    Is that supposed to be insult? Well, not exactly. I really think every manager has this clueless version of himself in the back of his head which is used more often than we’d like to admit. You still don’t believe me. Do a simple exercise. Think about your team. Arrange members from the best to the worst. Easy?

    It wasn’t supposed to be easy. The trick is how you decided that one ‘average’ person is after all better than another ‘average’ person. Some guessing I guess. Why exactly you have chosen the best one? And what a couple of worst people have done to earn their place? Is it possible that you justify their position with some past event (success or failure) which was spectacular enough they earn the place in your mind? Is it possible you didn’t take into consideration recent history because you already are strongly biased?

    And now the best part, think how many things you haven’t taken into consideration. You haven’t thought about tons of important things and you were still able to say who is better and who is worse from others. And no, I don’t believe none of them are important. Isn’t that clueless?

    A Confession

    I worked with bunches of underpaid and overpaid folks. I saw work which was underrated or overrated just because of person who authored it or the person who judged or both. Many of decisions standing behind these situations were mine. I’m not proud of it.

    What I can say is I didn’t do it on purpose. I just lacked knowledge. Sometimes I wasn’t even conscious my knowledge was insufficient to make a right call. Sometimes I should try harder or think more. I was, and I am, a clueless manager. I try to fight it but that’s an uphill battle. I have my prejudices and preferences and I don’t claim I’m able to fully ignore them.

    The Bad News

    I’m not the only one. I’m tempted to say that every manager is so because the only ones who would be different must be heartless robots which aren’t great candidates for managers anyway.

    This means you as a manager, and your manager too and her manager and so on, are clueless to some point. Usually more than you’d like to admit. This mean there’s a chance your judgments aren’t fair or your work may be misjudged. And finally this means your subordinates can trick you along with your cluelessness to make you think better about them.

    Managers were, are and will be clueless. We may fight with it but we’re likely to fail. Most of us don’t even try anyway.

  • Lessons Learned: Startup Failure Part 1

    Some time ago we closed down Overto – startup I was involved in. It was a failure – pretty obvious thing since we’ve closed the service. Since we learn much on our mistakes I think a reliable analysis why the business have failed should be valuable for you. For the beginning things we screwed.

    No one working full time

    From the very beginning we knew none of people engaged is willing to leave their daily jobs to commit fully to the startup. We thought we’d able to run internet service after hours. To some point that was true. As far as nothing bad was happening with the servers and the application it was all fine. We were working on new features when we had enough free time. Problems started when we faced some issues with our infrastructure. We weren’t able to resolve issues on the fly and had several downtimes. You can guess how it influenced user experience. That also backfired on service development since we had to focus on current problems instead of adding new functionalities. Lack of person working full-time and being able to deal with maintenance and bug fixing was the most important reason of failure.

    Catching the market

    That’s partially a consequence of the previous point. Since we spent majority of our limited time on trying to keep the service running we weren’t able to catch the changing market. We needed to cover new areas to move the application to another level but we couldn’t complete ongoing development. The whole project stopped in beta version and for users it didn’t look like anything was about to change.

    Lack of marketing skills

    Thin line between life and death of internet service is a number of users. For the initial period of time the numbers were growing systematically. Then we hit the ceiling of what we could achieve effortlessly. It was a time to do some marketing. Unfortunately no one of us was skilled in that area. Even worse, no one had enough time to fill the gap. That would be another stopper if we dealt with the problems mentioned above.

    Business model

    We hadn’t checked very well a business model we set up on the beginning. We were surprised a couple of our features weren’t as unique as we’d initially thought. Ironically that wasn’t a big problem since we had a bunch of ideas how to adjust the strategy in a new situation. Anyway, you should plan to change your initial business model.

    Screwed chance of selling the business

    After we’d decided we won’t be able to maintain the service in the long run we had a chance to sell it. To make a long story short we screwed negotiations starting with way too high price. We thought more about how much work we put into the project than how much it can be worth for potential buyers. Things are worth as much as one’s willing to pay for them, no matter how long it took you to produce them.

    Waiting too long with final decisions

    I think that one is a bit sentimental. Since the service was our child we were reluctant to make a decision about closing it faster and limit losses. We’ve been tricking ourselves thinking that everything would be fine while we couldn’t get the application back to work properly.

    Second part of lessons learned from startup failure

    Whole Entrepreneurs Time series.

  • A Failure Is an Option

    One of my ex-CEOs told me once a story about situation he’d have to face when he’d been a newbie manager. Shortening the story (it’s dull anyway, you can just skip it) a bit there was serious hardware malfunction in a company. There were no spare parts on service stock and they were to deliver their services next day, which was impossible to do without working hardware. The manager felt he had to do something to get machines working again. Unfortunately there was virtually no chance for him to succeed. Company failed to meet their deadlines and he felt as it was partially his fault, which wasn’t true.

    The moral of the story is:

    A failure is an option. Face it.

    By the way I’ve heard the story just after I finally rescued a project after 80-hour over-weekend battle with short brakes to get some sleep. Yes, it sounded totally irrelevant, but what would you expect from CEOs in that matter anyway?

    The moral however is very wise. A failure is an option. Sometimes it doesn’t matter how hard you try there are objective obstacles you can’t deal with. It can happen even if you’re the greatest Project Management Superhero in the galaxy and the biggest projects eat from your hand.

    If you ask me what to do, well, you won’t be surprised with the answer – prepare yourself. Sure, you can sit and cry your eyes out but you won’t get The Most Creative PM Technique Prize for that.

    First thing is to acknowledge you can fail. To be honest most of managers don’t get through this one. You know, you need to tell your ego you’re not as perfect as you think. That’s a tough task. Especially if your ego is so big it goes 5 meters ahead of you.

    Second, to have clean conscience, make sure you did everything you could to avoid failure before giving up. After all you’d prefer to be fairly sure you couldn’t make it, right?

    Third, prepare rescue plan. When you’re finished with hitting the wall hard with your head, have a plan how to call for an ambulance. It was said already that crying over spilled milk or crushed head isn’t the best idea in the world.

    I always smile whenever the reaction for question about potential problem is “we’ll manage, we’re superheroes, don’t ask” kind of approach. And believe me I see that a lot recently. I should have several great stories to tell soon.

  • Almost Completed

    One of projects I’m contributing to is a micro-ISV service. Maybe it’s not the perfect example of micro-ISV, because at least several people are engaged. It’s not single-person business, but the basis is the same. Whole idea was in its origin a world-changing service (or close). The main person working on the idea is a guy who loves it and strongly believes that the service will be great success. The rest of team keeps adding new brainstormed ideas to current concept, keeping ourselves on fire.

    Just like most of micro-ISVs. Just like most of micro-ISVs which failed. I wrote some time ago that faith and will to contribute in the long run are essentials when trying to build a product or service as the micro-ISV. But that’s not all. Another factor which is probably even more important is consistency.

    I’ve seen different “micro-ideas” (like you can call micro-ISV’s ideas for products or services) which had potential at least to earn for themselves. I played my role in those projects as a co-author, as a supporter, as a user. Range of ideas was wide – from a very fresh look on Internet entertainment services to yet another communicator. All of them I can call (more or less) failures. None of them fulfilled author’s expectations in area of revenue, number of customers or users etc. Many weren’t even born to be shown to the world – they died during pregnancy.

    When you have your application completed in 90% it’s usually much less than halfway to successful release. And when you’re 90% completed all the fun is the past. You developed the most enjoyable and the most challenging parts of a code. You exploited all your creative ideas during design. Now you have to focus on boring little improvements of website. Now you have to force your creative soul to think how to make your customers happy instead of thinking how to enjoy yourself with the work. Now you have to fix all those unrepeatable tiny little bugs which allow your frustration to grow. Now you have to deal with The Boring Time. And if you allow yourself to become bored – you lose.

    90% of completeness is just the beginning of the road. In this case 90% finished often means 100% failed.