Pawel Brodzinski on Leadership in Technology

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

Tag: project management

  • Hand-Offs Are Bad (But Unavoidable)

    Recently many of my discussions on process optimizations come to a point where we focus on hand-offs. When I say about hand-offs I think about every situation when a work item, feature, user story, requirement, or however you call those gizmos you build, is handed from one person to another. Think a business analyst handing requirements to a developer or a developer handing updated version of an app to a quality engineer, etc.

    Now, hand-offs are bad because I say so. You have to believe me because I am a Jedi.

    OK, being serious, I can show you why it is so. Every hand-off which is incorporated in your process is a place where work can pile up, and it usually does. Lots of tasks waiting to be picked up by another team member – doesn’t it sound familiar? Basically, one of things we are trying to do whenever we’re implementing Kanban is to limit work in progress, and one of very first effects of it is limiting a number of tasks waiting in these hand-off stages.

    There is more however. Another reason why hand-offs aren’t cool at all is it means making knowledge chain longer. It means adding another link between client/user and people who actually build the thing. You are virtually asking for more of unspoken assumptions and interpretations while making it even more difficult to sort things out whenever they’re vague. You will go through all these people to get the answer for your question. Or, more likely, you will just make one more assumption which is likely to be wrong.

    Then, we have responsibility. It’s funny to look at these huge corporations adding new roles and teams to their development process. Somehow they believe that each team which is more downstream will verify what a team which is more upstream has just done. At the same time they’re dissolving responsibility for building good software, and building good software is I guess what is what they aim for. I don’t say that mentality like “I have a whole team of quality engineers so they will catch any bugs I make” is something they consciously incorporate to their process but that’s exactly what they typically get. They should really look at those small companies that are built purely from software developers. Somewhat magically they can deliver high-quality software. How come? How is it even possible without a crowd of business analysts, quality engineers, release managers and whatnot? I have a hint: they all feel damn responsible for quality as they hand their product off only once – right to their client.

    I am well aware that, most of the time, we can’t get rid of all hand-offs from our development process. I don’t even say that we have to avoid them by any means.

    I just say that we should be aware of everything that comes along with them and…

    • Limit a number of hand-offs to lowest reasonable level. Think about any shortcuts in your process that you can make without quality loss. Think about simplifying the process.
    • Avoid adding new hand-offs whenever possible. Sometimes we want, or need, or have to add another link to our chain. Sometimes we want to have a messenger between clients and users and development team. But please, don’t add more messengers that it is absolutely necessary. As a rule of thumb: the closer development is to the client/user the better.
    • Measure and control hand-off stages you already have. Learn how big piles of idle tasks there are. Limit work which is waiting for someone. Organize your process in a way which supports quick consumption of work items which hit one of hand-off stages.
    • Make hand-offs more informal. The more informal hand-off is the more smoothly it will usually go. People sitting in one room, cross-functional teams, little formalisms all help to keep hand-offs informal.

    In terms of improving team’s productivity it is really a low hanging fruit and the one that may teams don’t even think of.

    If you don’t think it is a problem in your case, perform a little experiment. Measure how much time your work items live within the process and then split it into two numbers: how much time someone is actively working on them and how much time they are waiting for someone to take care of them. Simplifying things a bit, the latter number is the price you pay for all your hand-offs. And yes, I pretty much expect that, statistically speaking idle time is way bigger than active time.

  • The Project Portfolio Kanban Story

    The Kanban Story was the idea which came to my mind soon after we I started playing with Kanban with my team back then in early 2009. I thought that sort of live journal of our Kanban adventure can be an interesting thing to read. I knew that we probably got some things wrong initially but after all Kanban encourages you to have experimentation mindset and also I’m a strong believer that failure is actually a good thing.

    By the way: now that I read my story, sometimes I deeply disagree with the way we approached Kanban, yet still it was a valuable experience and hell of a lesson.

    The Kanban Story ended up as the most popular series of posts on this blog of all time and a few chapters are also high on the top 20 list. Sort of success I’d say. So when I started playing with portfolio level Kanban I decided to go the same way. I let myself a few months of experience just to have some content for the beginning and here it is: the very first post of The Project Portfolio Kanban Story.

    It will follow similar pattern as The Kanban Story which means I won’t try to address all the problems of the world but will rather focus on the specific situation and explain what we did and why. Expect much of the context and much of experimenting to find the right solution. Expect wrong decisions and changes. It’s going to be some sort of experience report. In chapters. I hope you will enjoy it as much as its predecessor.

    Here’s the list of all posts of The Project Portfolio Kanban Story:

  • What Makes a Good Retrospective

    The other day I facilitated a retrospective for a fellow team. My goal, as a facilitator, was basically to help them to suck as much value out of the meeting as possible.

    Now, before we move on, a picture from a past. I recall a bunch of retrospectives which looked like this: a whole project team met for a longer time and everyone was asked what was good about the project and what needed improvements. Then, one of project leaders wrote it down in a document uploaded the document to a server and finally everyone could just happily forget about the whole thing.

    Does it sound familiar? It probably does for many of you. Does it add any value? Um… next question, please. Isn’t it a complete waste of time? Oh well… If you don’t plan to make any use out of retro, don’t even start it.

    So the question is: what makes a retrospective valuable?

    The answer is actually pretty simple.

    Value of retrospective can be measured in terms of changes sprung by it.

    It basically means that the team decided to act, to try something new, to deal with a problem. It doesn’t necessarily mean that it will be an overnight success. Most likely it won’t. But at least they gave themselves a chance. They might even totally fail with the first approach, but they kept trying.

    Note: when I say changes I think about things which are really changing, not about those we just say we’re going to change but don’t do so.

    Anyway, another problem pops up. We want changes, but how to make them happen?

    Um, that’s sort of easy. Remember about a few simple rules:

    • Don’t chase too many goals. It’s usually tempting to cover each and every issue we spotted. After all we have all the enthusiasm and we want to improve. The problem is that when we commit to too many tasks we’re going to fail at many of them. Then, we’ll get discouraged that we don’t see any results of retro and our enthusiasm won’t be that enthusiastic next time. If there’s going to be the next time, that is.
    • Assign people to tasks. Task with no individual attached to it isn’t really assigned. A decision that the team would do something means that, well, someone else can do it, not necessarily me, right? Tasks assigned to everyone most likely end up not being done by anyone.
    • Have deadlines. Ask when you’re going to be done doing this or that. Keep your deadlines possibly short, yet definitely reasonable and achievable. Stating that something will be done in 6 months is meaningless. In 6 months I can work in the other place of the planet. A couple of weeks are a time frame we understand way better than a few months. If tasks don’t suit short time frames, chop them to smaller ones.
    • Verify outcomes. When deadlines pass remember to discuss with the team what was done, what was the outcome, what else, if anything, has to be done about discussed issues. Again, I don’t assume that all the problems are solved. You may end up with a solution, which didn’t work, and will to try something different. You can also end up with solved problem but the least you should do is saying so. Starting the next retro with such a summary of outcomes from the previous one is a good practice.
    • Repeat. One retro is just a quick fix. If you need sustainable change do retrospectives regularly. I don’t believe you are so perfect that one retro is enough to solve all the issues you might possibly have.

    In short you want to end up with a short list of actionable work items assigned to people and then check how you’re dealing with them.

    Of course sometimes it just sounds that easy. Sometimes you need to work hard to avoid blame game, get focused on specific issues, cut out longish but pointless discussions, learn to accept things you can’t change etc. Sometimes you will need to try different formats to animate communication or build basic trust between team members or change their attitude to anything positive. Sometimes it may be damn hard work to do.

    But as long as you aim for the goal and your actions help in achieving it, you should do pretty well.

  • Pull and Push in Kanban

    Kanban is a pull system. Period. In Kanban everyone pulls the task from the previous stage to another. Developers pull tasks which are ready, quality engineers pull tasks which are built, release managers pull those which are tested, and so on, and so forth. Basically every operation on the board happens that way.

    Well, almost.

    There is one interesting thing I realized talking some time ago with Nadia Zemskova in Copenhagen. In one situation we usually have push instead of pull operation. When? Consider a typical Kanban board where a backlog is split into two columns: long-term backlog where you put everything you’re going to build and short-term ready column or to do queue where you put just a few tasks of highest priority at that moment. The board which looks like that:

    Now, what is happening here is usually a part of job of product owner or product manager: they have to choose what the most important thing to be build at the moment is and push them into production process. Um, have I just used the word push?

    But that’s exactly what happens. When working with backlog we don’t just pull first thing from because first we have to decide what is going to the top. When we prioritize features we look though all of them as we theoretically have to compare every possible pair of features and say which one is more important or more urgent. We actually decide what exactly will be built in the first place. We push a bunch of features into to the top of the queue or, in other words, into production process.

    From this point the whole process is pull but the first stage works the other way round. There are two differences between first stage and the rest.

    First, when prioritizing features we usually work on big pool of them – actually all of them which are in the backlog. Later we usually don’t have more than just few features to choose among and very often we can pretty safely assume all of them will be completed soon enough.

    Second, at the beginning prioritization is crucial part of our activity – we make conscious decisions what should go first and what should go next. Later in vast majority of situations we can use simple mechanisms like first in first out and it would work well. At the beginning we can’t go with something like that as we’d be building our software in rather random manner. And that doesn’t sound like a great idea if you ask me.

    That is why we retreat to the good old push to manage backlog.

  • Procedure Is Not an Answer

    I’m constantly getting frustrated whenever I see this behavior: people trying to set up some rules or procedures which tell everyone what to do in such and such hypothetical or unlikely situation. Who should tell me what to do when support engineer gets sick and can’t pick up the phone? Who is responsible for sorting our priorities when emergency screws our plan up? What should I do when another ash cloud hits our project.

    Well, I know what the wrong answer is. The wrong answer is: let’s write a procedure, or set up a rule, which tells us what to do so no one really needs to use their brains to find it out. Let’s write darn checklist for everything so we can tell that project couldn’t possibly have been screwed because we have a nice column of ticks on the list. It couldn’t have been, even when the only things we see at the moment are a totally pissed off client and burning brothel which we used to call “a project.”

    You just can’t have a rule for everything.

    Um, after a second thought, you actually can.

    The rule is: just follow damn common sense!

    Don’t know what to do? Find it out. Talk with people. Share your problem. Actively look for a solution. Take responsibility for sorting out the mess. As long as you solve the puzzle it doesn’t really matter whether you followed rules or whether there even were any rules in the first place.

    If you’re kind of a prophet and you know exactly what kind of issues you’ll be facing on October 4th, or any other date in future, go set up rules which will help you deal with these problems. However if you’re like normal people without hugely overgrown ego, let’s just agree that it isn’t possible to predict all the issues we might face.

    Let’s agree that we all are professionals who are willing to work hard, hand to hand with each other, on solving any shit we’ve got into. Let’s just agree we don’t need procedures or rules to deal with every single situation the future brings.

    Unless the only thing you look for is to deal the blame among others, that is.

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

     

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

  • 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