Pawel Brodzinski on Leadership in Technology

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

Author: Pawel Brodzinski

  • Taught Helplessness

    Roy Osherove in response to my last post on the art of saying no linked to his short (but very good) article on coaching, pointing it is better to use a chance to help people grow instead of simply turning their requests down.

    Yes Roy, you’re right. To some point at least. I mean I love the “What are you going to do about that?” story. But I also know a different flavor of it. It goes like that.

    – Pawel, I have a problem with my project here…
    – Um, what are you going to do about that?
    – I need more people so please assign them to the project.
    – Well, that might be a bit difficult. Do we have other options?
    – No, this is the only one.
    – Are you sure? Can’t you juggle with tasks in the schedule, haggle with the client so we can do something later or something less, incur some technical debt or just be late with this task?
    – No, we need more people. There’s no other choice. If you don’t give me them the world will burn in hell of flames and our poor souls will be lost.
    – I have no free people, sorry. Now, deal with that.

    I know – the last line should go like that:

    – I have no free people. What are you going to do about that? Ha! Check, mate! I have just used magic Roy Osherove’s formula so you lose and I win, sucker!

    The problem I see here is taught helplessness. People choose the only solution they believe would work, no matter how unlikely it is to happen, and don’t even try to look for any other idea. It’s my way or highway kind of situation. And well, it’s usually my way when we are at that.

    Usually in such cases unless you start with the art of saying no you can’t move to what are you going to do about that. You can hardly turn active search for reasonable solution on unless you turn down the one which is imprinted deep in the mind of a person who ask the question.

    Taught helplessness basically makes people immune for coaching. If you’re going to help them grow, you better have a good no at hand.

  • Visualization Stupid!

    Kanban is a funny animal. I started my journey with Kanban treating is as a tool. Then I realized it is more of a vehicle which improves things around. Now, I extract some ideas standing behind the method and use them independently in different situations.

    Since Kanban is as easy as possible – I use to describe it as “three rules, one tool and simple mechanics” – there aren’t many ideas you could exploit, but there’s one which is especially appealing. A contest: which one am I thinking about?

    Yes, I know. I ruined everything with the title. What a dumbass I am. Anyway yes, visualization is the concept I like so much. Generally I’m known to be attracted by every whiteboard or flipchart around. If you see me sitting peacefully in a room with a completely clean whiteboard and set of markers you can bet I suffer. I’d love to write, draw, scribble and note on the board, so we all can see some reference to what we are talking about or how others may understand what we’re talking about.

    Feel free to laugh at me because of this. It doesn’t happen without a reason. I learned how much value simple visualization can bring. I’m sure there’s some psychological gibberish which shows how our brains deal better when we can refer to a huge visual brutally presenting the core of the issue, but I don’t really care.

    I use visualization because I know it helps me. It helps to me to organize presentation, like the one I’m preparing for ACE Conference. It helps me understand the problem, like learning how many quality engineers we do need at the moment. It helps me to express my thoughts, like when we’re discussing performance appraisals.

    Next time, when you have some problem, try to draw it on the whiteboard or flipchart. I mean really. No matter what the problem is or how you choose to visualize it. It would help you to understand and chances are good you’ll find a clue how to solve it.

    If you wondered why I brought two whiteboards with me to my new room, now you know.

  • People Are Not Our Most Valuable Resource

    I hear that one from time to time: “people are our most valuable resource.”

    Well, they are not.

    People aren’t your most valuable resource. People aren’t goddamn resource at all. People are, well, people. Individuals. Folks who somehow like to be treated as real persons and not precious pieces of junk otherwise known as servers and such.

    Every time I hear this cliché about people being most valuable resource I wonder: how the heck can you say people are most valuable when you treat them as resource? As commodity. As something which can be replaced with another identical um… resource. If you say that, you basically deny that people in your organization are important.

    And it doesn’t really matter how hard you try to avoid calling people with that name. If you believe they are (put here “most valuable” or whatever bullshit you like) resources you won’t trick them. They won’t feel respected and they won’t trust you. Why should they after all? Do servers trust project leaders? And no, that won’t make people motivated whatsoever.

    I know, this is a rant. But this makes me crazy. I mean, how could we learn such humiliating behavior? I’m just waiting until I hear “Hi resource” instead of “Hi Jane” when Mr. I’m-So-Damn-Important-Project-Manager meets one of his project team members.

    Then, I’m going to hurt somebody. And I guess it won’t be Jane.

  • Scrum versus Kanban

    These days every blog discussing agile topics should have a big hairy article on Scrum versus Kanban, so here it is. Well, just joking. Actually many people, way wiser than me, approached that subject some time ago already presenting different arguments. If you want to hear some of the strongest opinions out there check Ken Schwaber’s post on how Scrum is good and Kanban sucks. If you look for more weighted opinion David Anderson shared one. Just recently Mike Cohn also added very reasonable two cents to the discussion even though he actually doesn’t agree with David.

    Also there’s been a lot written about Scrumbut and Scrumban. I don’t see the point in repeating once again that if something works for your team – go for it, no matter if that breaks the orthodoxy of the method of your choice.

    Note: I’m well aware that until now I just share what I’m not going to write about. Is this post is going to be just a set of links to some good articles though? No, not exactly, but please do check mentioned articles – they’re a piece of good reading. Anyway, to the point. There’s one thing which is often mentioned as one of main differences between Kanban and Scrum but I think this is the core of the whole this versus that thing.

    The point

    From pretty much every Scrum and Kanban comparison you’ll learn that introducing Scrum is a revolution while with Kanban it is rather evolution. You’ll also be pointed that both approaches foster improvement. Now, finally, after all that beating around the bush: my point here is how Scrum revolution differs from Kanban evolution in terms of introducing improvements and why it is so.

    Team model and software development process

    Let me start with something I was learning for quite a long time (no, I’m not that bright to catch it during the first class):

    Scrum proposes pretty damn good team model and process for building software.

    If you look for model team which would work in majority of situations go for a Scrum team: cross-functional, small and tightly-integrated. If you look for healthy approach to software development you can’t really go wrong with Scrum. Scrum is well-thought and well-weighted approach. No surprise it ruled the agile world.

    On the other hand Kanban tells you that your team model is good for now, no matter how it is organized. And your process of building software is OK even if it’s pretty chaotic. For now.

    Kanban doesn’t propose any specific team model or software development approach.

    It basically means that you get no hints whatsoever how the well-organized team would look like. Nil. Nothing. Find out by yourself. No help here. Well, almost.

    The difference

    When organizing Scrum team you can basically turn your thinking off. Well, sort of. It’s all in the book. Someone took the effort to propose team model which I’ve just labeled “pretty damn good.” Same with the process you’re meant to follow.

    Kanban chooses the other approach: we don’t know what optimal solution for your team is. Here’s some help but you’re going to learn it by yourself.

    The difference? Pretty damn good doesn’t automatically mean optimal. Scrum is optimized for majority of teams, not for your unique group. Yes, of course, Scrum has improvement mechanisms, retrospective being the flagship here, but in terms of general rules it stays unchanged.

    Kanban accepts that starting point may be way worse than in Scrum case but leaves you all options open. You aren’t really constrained with specific practices or models. What you’re going to end up with is totally on you and your team.

    Help you get

    You can put it in other words if you prefer. Scrum tells you how you should change, at least to some point. Scrum is like your mother-in-law – she always knows that you suck here and there and how exactly you should act to be um… better.

    Kanban on the other hand is like your friend, close but probably not the best one you have. He’ll try to show you where you could improve but won’t state it explicitly. It’s just not that kind of relationship. It will be rather a set of hints and smoke signs – it’s you who chooses to use them to change yourself or just ignore them.

    Which one is better

    Neither. Despite comparisons I’ve just use I really think there’s no winner here. And yes, I’m generally considered as a Kanban guy but I also strongly believe there’s no silver bullet.

    If you need a kick start Scrum may give you one even though it imposes some constraints on the way you work. On the other hand if you have in your team someone who is experienced with variety of different methods it may be a good idea to start with Kanban and check where it’s going to lead you.

    After all, since I’m not an orthodox, I’ll also tell you should experiment like crazy, no matter which path you choose. Heck, that’s where all those Scrumbans started – people were changing their process, people were breaking The Holy Rules of The Method just to end up with something more optimal for them.

    Final thought

    If I want you to remember one thing from this post it would be: Scrum tells you explicitly how to organize work and improve things, while Kanban tells you nothing about the ideal models and helps you find out the optimal way by yourself.

    After all, this post is big and hairy so I guess I succeeded with the task anyway.

    Advertisement: Protect your business from a surprise software audit with License Dashboard.

     

  • Mechanics of Kanban Improvements

    As I’ve already started working on my session for ACE Conference 2011 I tinker at different improvements introduced by Kanban and the way they pop out. Actually if I had to point a single, most surprising for me, feature of Kanban I’d point exactly the way it fosters improvements.

    When we were starting with Kanban I expected it to be more a very lightweight approach, which organizes the workflow and doesn’t get into way, than something which may trigger any improvements on its own. Things didn’t really work that way.

    Yes, we fixed issues we’d faced at that time but that was to be expected. Then we kept finding new issues and correcting them. For a longer time I didn’t really put much thought how it worked but I had to explain somehow specific practices we introduced in my presentation on AgileEE as I wanted to talk about the subject. I realized that we didn’t plan them. They just popped out. Somehow. Magic?

    No, not magic. After short investigation I found the one to blame – it was Kanban. Thanks to using Kanban, specific problems were unveiled and we were just fixing them, sometimes completely unconsciously.

    One of my favorite stories is when I suddenly realized we had collective code ownership. Yes, it was totally out of the blue. “Wait,” I thought “didn’t we discuss it through? Didn’t we end up with conclusion that we wouldn’t have collective code ownership? What the hell?” Actually it appeared that it was just easier to have collective code ownership in a pull system, such as Kanban, so people stopped thinking whether this is their own or someone else’s code. After some some time we had collective code ownership implemented basically effortlessly.

    That is exactly the mechanics of Kanban improvements. You introduce them because it’s just easier that way. You either see something is wrong on the board and have a quick discussion how to tackle the problem and implement a solution or people start dealing with the issue unconsciously. Either way you end up with your process slightly improved.

    And you repeat this activity. Multiple times. After some time when you compare what have you started with and what you ended up with you start thinking: how the hell this whole improvement thing in Kanban works? You can’t see it but somehow it’s happening. All the time.

    Well, it seems it just works that way. Don’t complain, just make use of it.

  • Project Management Styles: The Good, the Bad and the Ugly

    This time a quick look at different types of project management styles. Since I’m dealing with many different teams and many different project managers I hear plenty of opinions about PMs and approaches they employ in their work.

    Somehow those opinions tend to support one of three general pictures: the good, the bad or the ugly. Somehow those opinions tend to be pretty aligned. My wild-ass guess: that’s not without a reason. Actually the more I think about that the more I’m sure I could put any project manager I know in one of these buckets.

    The Good

    You know your job. You try to do your job well. It doesn’t mean you don’t fail. Oh, you do, that’s for sure. However chances are good that every failure is an occasion to learn for you.

    The funny thing is the sole reason that you know your job and try to do it well isn’t enough to be respected by people around. There’s something more. You can adjust yourself to changing environment. After all, as a PM, you’re in the middle of the mess, usually called “a project.”

    You’re a good observer. You know about people you work with. Sometimes you know about them more than their managers or themselves. You call risks out. Not only project-related ones. Also those which are tightly connected with people and their characters. That doesn’t mean you’re always listened. Heck, that doesn’t even mean you’re often listened. But it isn’t a reason to stop trying.

    You’re good but it doesn’t mean you don’t have rough edges. Oh, you do. A lot of them. So yes, we had our fights and misunderstandings. It’s likely we filed each other under “problematic” label after our first meetings. But then, we both know this job takes all sorts and it’s our mutual business to find a way to cooperate well. What more, we clearly stated what we expect from the other side which helped to shorten the process of learning each other.

    Now, you’re one of those who I want to work with. I mean really. You aren’t an easy partner but discussion with you is never a waste of time, even if part our ways without finding consensus. It’s good to see you popping up in my office even when you bring a problem with you. It’s good to know you’ll be running projects I care about.

    Besides, that’s not only my opinion. People keep pointing on you as a project manager they’d like to have in their projects.

    The Bad

    For whatever reasons you don’t really like what you do. It may be anything from feeling you’re predestined to something other/better to belief that your work isn’t appreciated enough. Either way you don’t like the point where you stand.

    The real problem is you don’t do much to turn things around. If we don’t count complaining that is. It’s either definition of your role which is wrong or expectations are too high or boss is a jerk or project is a nightmare or moon is in the wrong phase. You feel a kind of doomed. You can’t work the way you’d like and you have no guts to consistently work to change things around.

    As a PM you have your power though. You use it to show that you are important. You request compliancy, you condemn overruns, you demand people, resources and budgets. There’s interesting thing here – you seem to always know the answer. The best solution is the one you point. And if reality doesn’t stick to it, well, so much the worse for the reality.

    Somehow almost everyone around never lives up to your expectations. And almost everyone around would say about you exactly the same. They keep asking what exactly you are responsible for as they’re suspicious enough to think it should be more than you seem to accept at the moment.

    We might have had our fights, but that’s not so obvious. You might have been just ignored in a well-mannered way. Chances are good you haven’t really fought for your projects. After all the whole world is allied against you, isn’t it?

    Besides, that’s not only my opinion. Most of project teams which worked with you will prefer some other project manager. They won’t be totally disappointed with having another project with you though. After all it’s better to have someone who isn’t supportive but isn’t a pain in the ass either.

    The Ugly

    You consider yourself as a damn good project manager. You’re a tough type, but that’s what this role taught you to be. You don’t care whether you’re liked or not. This job isn’t about being likeable but about pushing projects to their end. Yes, that’s the word, you push these projects. Without you all developers would end up reading news or playing Counter Strike all day long.

    You know how to use project management tools you have. They may say you’re kind of formalist but that’s how you show who failed with their tasks and where eventual project failure should be addressed. Also your ass is always covered. You have e-mails, documents and such for every problem in the project. In the worst case you can say: “Haven’t I told you that?”

    I have mixed feelings about you. Sometimes you’re able to put together a group of people and make them playing as project team. Sometimes playing a bad sergeant brings projects closer to the successful end. Unfortunately at least equally often your approach triggers allergic reaction in project teams which brings additional issues to the project. You have an ability to change performance of teams. The problem is it works in both directions – sometimes it goes up and sometimes it goes down.

    By the way: your successes seem to be interlaced with failures – isn’t that surprising? With your rock star project management skills every project should be a stunning success. I know it’s always team’s fault but hey, there are fellow PMs who seem to have much better success rate.

    Besides, that’s not only my opinion. People say different things about you. There are those who consider you as a model project manager and those who prefer to have no project manager at all than to have you to lead their projects. Have I already mentioned “mixed feelings?”

  • Good Waterfall Is Better Than Bad Agile

    Lech brought an interesting subject recently: isn’t running an R&D project with heavy-weight, structured approach extremely difficult?

    We use to think that we need very flexible approaches for projects which aren’t defined very well, thus agile being frequently a tool of choice for R&D projects, which bear a lot of unknowns by definition. After all can you really produce reliable plan for a research project? It is research; you don’t really know what you’re going to end up with.

    But we fall in the trap of simplifying things. When we think about heavy-weight approach to project management we instantly see BDUF waterfall project with no checkpoints on the way carried through without taking changing conditions into consideration. Yes, there are still a lot of projects done this way but this isn’t the only way of running projects non-agile way.

    The trick with R&D projects is that you wander through unknown areas. It doesn’t mean you can’t plan you journey though. It doesn’t mean you can’t assess your progress and change your course along the way. It doesn’t mean you can’t measure where exactly you are or compare that against expectations which were set up front.

    What more, to some point agile, when done well, enforces us to do exactly that. But then every reasonable approach, no matter whether it’s heavy- or light-weight, does the same. We can have inspect-and-adapt attitude with pretty much any project management approach used these days.

    The real problem is we often misuse tools we have. Project management methodologies aren’t an exception here. When we fail to apply our project management approach reasonable it doesn’t really matter which one we choose – the result will always be poor.

    So my answer for the problem from the beginning of the post is: as long as your project management approach is well-organized and reasonable your R&D project will go well. It doesn’t matter much whether the method is heavy- or light-weight. However if you fail to apply the approach right way don’t expect much of success in your project even if the label on you’re a tool of your choice says “agile.”

    In other words good waterfall is better than bad agile.

    Since I expect “but good agile is better than good waterfall, especially for R&D projects” kind of argument I’ll answer it up front: it depends. It depends on many factors, starting with your domain, going through organizational culture and ending with people you work with. And yes, we can discuss each case separately.

  • Kanban Board: Keep It Simple Stupid

    In one role or another I often help teams to try Kanban out or just to help them to create their task board or Kanban board. There is an interesting pattern I observe.

    First thing is happening when a team discusses what columns should appear on the board. It is very common, and advised, to start working with Kanban with exactly the same process you already have in place. You could expect people would know it by heart. It should be really quick: “we do this, this and that, so it goes to the board.”

    Well, it appears that “process we follow” is pretty ambiguous most of the time. There are discussions whether something is a separate stage of the process or rather a part of the bigger task etc. People find they don’t really know where to put specific tasks as they’re floating depending on a number of factors. It appears the process isn’t really defined or not everyone is on the same page or people understand their tasks differently.

    Note: it all happens without any change in the process. No wonder why many process transitions are failed. What do you expect when people don’t really get how they’re working at the moment, let alone how they’re supposed to work?

    Then there is another observation. In the long run Kanban boards tend to become more and more complex. As teams work with their boards they add something to the structure more often than they remove anything. That’s perfectly understandable. When people learn better their process and the board which should reflect the process they have more ideas how to improve it. So they do, adding things and making the board more complex over time.

    Usually later version of the board has more columns/sub-columns/lanes/you-name-it than the earlier one. Sticky note bears more information too. Well, if you compare the first version of our Kanban board with the last one you’ll exactly see exactly the pattern.

    OK, but where does it bring us?

    Considering these two things: we usually don’t really know the process we try to map with the board and the board becomes more complex over time we should avoid over-engineering the board. Start simple and keep it simple. Don’t try to map every possible issue with the initial design of the board.

    I would even say that the idea to start with a single “ongoing” column representing the whole process of doing the work is pretty good. You will split it anyway but at least you will know exactly why you’re doing that and which stages you want to make explicitly visible and separated from others.

    When crafting your board, if you have doubts whether you should add a column or lane or something or not as a rule of thumb you shouldn’t do that. You’ll do it later… if you really need it.

  • Why Money Doesn’t Motivate

    I touched money and motivation subject recently. Since the post generated quite a discussion it seems the subject is important for many. It also seems many people disagree with the opinion that money doesn’t really motivate which is nice since it gives me excuse to beat the dead horse again.

    In short my points were:

    • Money is more a hygiene factor than a motivator.
    • When you pay less than some healthy level expected by people they start looking for a job.
    • As long as you match people’s comfort level they get, or don’t get, motivated by non-monetary factors.

    I received a number of counterarguments in comments, which I’ll try to address here. I’m aware I overstate bit here and there but that (hopefully) doesn’t change validity of arguments.

    Money does motivate people (and go sell your crap somewhere else)

    A nice thing about Dan Pink’s TED Talk is that he’s making a case. He brings arguments – studies made all over the world – to prove the point: money doesn’t seem to make people work better. Now, I haven’t looked very hard to find research studies which prove the opposite, but maybe you can redirect me to them. For now I consider it is 1:0 for Dan’s team.

    I saw teams whose productivity increased significantly just after bonus money was promised. The problem is usually they were just tricking the system. They knew they could do the job in given time but it was better to slack at the beginning waiting for the magic wand of extra money to be used. Then everybody got at full speed to save the project. The only thing which surprises me is where the hell the management was and why nobody did anything about that sick situation?

    I know lots of examples of people working their asses off because project required their extra effort. Usually they got a big bag of money at the end and everyone was happy. Does it mean money motivated them? Well, I think we’re messing the cause with the effect here. They didn’t start discussing with their managers how much they were going to get. They just gave more, because they thought it was a right thing to do (I know I totally oversimplify here, but we won’t discuss everyone’s individual drivers here, will we?) Then the effect usually was they got some extra money, which was of course completely fair.

    And for the end, if money motivates people my question is: why they don’t get more and more motivated as they get more and more money? I gave quite a lot raises and huge piles of extra money in my career and my observation is it makes people happy. Happy, not motivated. They’re engaged as they were. They give a lot, as they did. But somehow they don’t seem to be motivated better.

    Of course sometimes they consider the money they got as an insult and their motivation fall flat in its face but we’re talking about motivating, not de-motivating, here.

    Companies (and villains running them) want to have engaged people but only to exploit them (that’s what villains do after all)

    That’s true for some companies and some villains running them. But if that is your only experience with your employers please accept my humble condolences. There are toxic companies out there. There are normal companies with toxic managers as well which, from employee’s perspective, is no different. The world however isn’t inhabited with villains only. There are superheroes as well. If you’re sick of work among bad guys maybe it’s time to join Rebel Alliance, La Resistance or other good guys of your choice.

    I know it’s easy to generalize basing on your own situation and experience (that’s what I do on the blog virtually all the time), but be sure to check what’s happening out there in other organizations, especially when your experience is limited to one or a couple of teams/companies.

    Because of rapid development of IT industry we face deficit of good, experienced leaders and managers. It’s even truer in countries where the industry is even younger, like in Poland where I live. But still, that’s not a reason to dismiss the existence of healthy companies or decent managers.

    People should earn amount they expect or they get frustrated (which is bad since frustration is such a nasty word)

    Well, yes. Sort of. We come back to the discussion over a healthy level of salary. If I get paid above some expected minimum, which is a very individual thing, I could always use a raise but I don’t get frustrated about money. However if you asked me how much I wanted to earn my answer would be likely something more than I get. That’s how humans work – we always want more than we have.

    And now that you asked me, yes, I do have a pitch to ground why I should earn more. But don’t be stressed, I’m not going anywhere only because my pitch doesn’t convince you. See? I’m not frustrated.

    However I do agree that once we don’t get the amount we expect there’s always a risk that the other company would offer us more and then we’d be really incentivized to make a move. But I guess that’s the risk most of companies tend to accept. After all last time I checked running a business was about earning money and not spending everything just to pay people more.

    Best moment of motivation is when you see the money on your bank account (let’s switch to weekly wages, shall we?)

    OK, I admit, I don’t get this. At all. You mean once you see a bunch of money on your account you’ll be coding like crazy till the night? Would it be a better motivation to earn weekly wages than monthly salaries only because they’re um… more frequent?

    It’s difficult for me to address this argument but I guess we define motivation differently. As industrial bloodsucker I consider motivation as something good not because the word sounds nice but because motivated people tend to produce better results when they work. Call it a better productivity, bigger involvement or whatever.

    I understand people are happy when they see salary on their account but if we can build no connection with their work quality whatsoever let’s not call it motivation, OK? Of course feel free to correct me if I’m missing something here.

    Over time people get more experienced so they should get raises (like levels in RPG games)

    Um… no. Next please!

    Well, actually that’s the tricky one. Once we get more experienced and more knowledgeable it’s a natural thing we tend to want more, thus expected raises. The problem is employment isn’t an RPG game and our contracts aren’t a leveling system.

    Contract and salary represent a result of a kind of compromise. It’s about how much specific employee is worth for specific employer. It means that the same employee would be judged, and paid, differently depending on the hiring company. And yes, it does mean your salary depends on company’s clients, hiring strategy, specific managers you’ve been talking with, shape of the industry, organization’s career paths and a hundred of other factors which are completely independent on you.

    Sometimes getting more experience and/or knowledge doesn’t make you more valuable for the company. So maybe it’s time to learn what makes one a more valuable person for the specific organization instead of waiting for a reward for seniority?

    There are many jobs which can’t be loved which means people do them for money (after all love and money are the only motivators in the world)

    True. There are many jobs which can’t be loved, especially in the corporate world. But that doesn’t mean people do them for money and for money only. If they hated virtually everything about their jobs they would be looking for new ones like crazy. Somehow vast majority of them do not. I assume it’s not that bad then.

    We don’t get frustrated with our jobs in a second or after a single issue. Frustration grows over months, possibly years. Then yes, it is about a single problem or a single situation but it’s just the last straw.

    Our happiness with our jobs is a complex thing. I could count multiple things I’m happy with and multiple of those I’m definitely not happy with. However the overall mark is pretty good so I’m not going anywhere and probably one new ugly thing isn’t changing this attitude.

    I think it works pretty much the same with jobs which are considered as, well, not-so-nice. Corporate world is the one where conditions are usually less humane but then majority of corporations don’t deal with the risk of being extinct in a few months – something which is pretty common among startups. It’s of course only one of examples but the theme is similar in many cases. After all, when the company offers only jobs which are totally hated they’re going out of business soon as CEO won’t deliver all the projects single-handedly.

    Now, I’ve shared my arguments a little less briefly but I’m sure I haven’t convinced everyone (that wasn’t the goal by the way). Let’s get the heated discussion started.

  • 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