Pawel Brodzinski on Leadership in Technology

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

Category: project management

  • 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

  • How to maintain backlog?

    In one of recent postings I asked you how big your backlog is. My argument was that trying to enforce small backlog size is counterproductive. Although small backlog is easier to manage throwing things away from it just to keep it small isn’t the best idea.

    However that doesn’t mean you shouldn’t do some backlog maintenance from time to time. What more, applying a few simple rules can help you to manage backlog easily despite its pretty big size.

    Keep epics, split late

    Sometimes we add to our product a big story. An epic. It is actually pretty interesting example in terms of sizing backlog. Why? Well, no matter if you split the epic into a list of smaller stories, i.e. sized similarly to your typical features, or keep it big you add a huge piece of work. A piece, which usually makes sense as long as it is completed as a whole. So yes, you need quite a capacity to add the feature, no matter which approach you choose. What do you do if your backlog is limited?

    Anyway, my advice is to keep epics in backlog as long as possible and split them in the last responsible moment. It is aligned with agile late design approach but that’s not why I advise you so. Actually as long as you don’t start working on the epic there’s no reason to keep a dozen of sticky notes on the board instead of a single one. It’s enough for you to look at epic to know roughly what is to be done. You will need more details when you start development of first epic-related feature so no need to worry at the moment.

    It is easier to reprioritize the epic over and over again if it’s in one piece. And reprioritizing is the most common task when it comes to managing backlog.

    Groom from time to time

    If you have spacious backlog you will face this situation on occasions: you will find out that one or more features waiting in the backlog are no longer relevant. Maybe you’ve changed the goal of your app or you abandoned industry which was addressed with the feature or you just don’t have a faintest idea why you wanted to build the damn thing in the first place. Either way it’s time to forget about it.

    Grooming backlog is a great occasion to do that. What exactly grooming is? A simple process of reviewing all features in backlog to verify their relevancy. Yes, if your backlog is big it takes time. But after all this is the way to make it at least a bit smaller, thus more manageable. And you don’t do it every week as you don’t change general plans for your product that often.

    Group features

    There’s an observation which can be helpful as well. Unless we work on maintenance project where priorities are usually set by the client we tend to build groups of similar features and not randomly choose one from here and another from there. Grouping features which are similar or features which touch the same parts of code can be helpful in terms of prioritizing work. Once done you can just throw in another feature from the group instead of scanning through the whole backlog to look for a relevant task to put in todo queue. That is as long as your general priorities don’t change.

    Grouping features also helps in prioritizing whole backlog. Instead of considering each and every feature separately you decide on a group which means you use the same time to judge a dozen of tasks you’d use to judge a single task otherwise.

    Dealing with big backlog isn’t that hard after all. All you need is some order and a few rules which help you to organize a long list of tasks somehow.

  • Specifics of Voluntary Projects

    Recently I told you about TEDxKrakow and how great idea it is to get engaged in a project like that if you want to get some experience in project management.

    No one commented that voluntary projects can’t be exactly the same as typical commercial projects even though I pretty much expected to hear this kind of argument. I did because it would be well-grounded. Voluntary projects are specific because, well, they are voluntary.

    OK, so where are differences?

    • No managers. No one is a boss. No one can just tell others they have to do something. There is no easy path. You have to earn your power before you can use it. People won’t start listening to you just because you are able to talk loudly. You have to show that you are doing at least as much by yourself and/or earn their trust before you start shouting your orders all over the place.
    • More talking. Talking is easy, talking is cheap. Unfortunately talking doesn’t get things done. People tend to throw great ideas as long as someone else is supposed to make them real. Unfortunately it sometimes turns into much talking and little doing as there isn’t really a business client who would make quick decisions on what is must-have and what is nice-to-have. A pretty good playground for doers I’d say.
    • More freedom. Unlike in typical projects you actually choose what you’re going to do. It’s like the open auction – I have this and that tasks unassigned, who’s going to take them over? Specialization works pretty similar though – we tend to choose things we are competent at and avoid those we suck at.
    • It’s easier to shine. In voluntary projects no one wants to get all the credit. After all it isn’t a place where people are going to build their whole careers. Chances are good that your effort will be properly credited. Just choose your tasks wisely and then deliver what you promised to deliver. Since in voluntary projects over-promising is just as common as in all others it should be enough to make you stand out.

    There is one more thing. It is real fun to be a part of this kind of project. But, after all, I’m not sure if it is a general rule or TEDxKrakow I used as example is fun to work on or fantastic people I met in this venture made it so. Or maybe all above are true.

    And if you haven’t yet registered to this fine event do it while you still can.

  • Hyper-Productivity Is Not an Issue

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

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

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

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

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

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

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

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

  • Learning Project Management Basics

    A question about starting career in project management is heard pretty often. A question about value of different project management certifications usually follows.

    There is a bunch of standard answers for these questions. Apply for junior role in project management. Attend a course. Help your PM in her job. Get a certificate (this or another). Buy and read a stack of books on project management etc.

    I have another answer. Actually the answer isn’t exactly mine. I’ve ruthlessly stolen it from Scott Berkun.

    Go, run a project.

    “How? I mean I’m yet trying to get project management job, remember?”

    Pretty much everything which happens around you is a kind of project. If you invite a group of friend for a dinner it is a project. If that doesn’t sound like a real project think bigger. Maybe you can organize vacations for friends?

    “Yeah, and what do I learn from such a simple thing?”

    Don’t tell me it’s easy – I’m just finalizing sailing trip for 25 people. And, believe me, friends aren’t the best clients you can find around. It requires the same skills you’ll be using once you get your PM job to organize this kind of trip.

    “Maybe that’s a nice idea but I don’t have 25 friends.”

    That sucks, man. But you definitely have some non-profit organization which would appreciate some help in their projects. And they do have a lot of them. And they’d love your help they’d get for free (non-profit often means non-paying too).

    “But, you know, this whole non-profit stiff isn’t really something I’d like to work on.”

    Um, you think once you are a project manager you’ll be able to choose projects you like and reject those you don’t. I have a bad news for you. You won’t. You know life isn’t as nice as they told you.

    “OK, but how it helps me to learn project management?”

    You basically organize a group of people to do what you want. They come to a meeting point. They go to target place where they’re warmly welcomed by your hosts. People know when they can go watch latest World Cup match and when they should bring you a cold beer in exchange for organizing this great trip. Earlier everyone paid you their share of costs so you could have paid for your shelter.

    This isn’t much different from project management in real world. You make people doing what you want. They work on a project tasks of your choice. Everyone knows when they’re free to learn new technology and when they should focus of finishing before deadline. Earlier people agreed on plan of splitting tasks and build a schedule etc.

    “What about all the formal stuff? I don’t have to create technical specifications when I organize a trip for friends.”

    Oh, really? You don’t? That’s interesting… OK, just joking. All the formal stuff will differ among companies so it isn’t so important anyway. Of course you should know what WBS is and understand how to find critical path, but that’s not a rocket science.

    What more usually candidates for project management positions lack practical knowledge – lack of understanding of some technical terms isn’t so common.

    So go, find a project and run it. After all there aren’t many things which would match your friends thanking you for a great trip and asking whether you’re organizing it next year too. This single thing is worth the whole effort. The funny thing is it works similarly in projects you run at work.

    By the way, I’d use the same method to learn leadership.

  • Agile Isn’t Immune for People Who Don’t Give a Damn

    I like presenting. I just love the fact that every time I deliver the presentation I find something new in there. It’s like having tiny epiphanies while you’re talking to a crowd. And I’m sure I wouldn’t have them if I didn’t overcome my fears and didn’t start speaking publicly.

    A thing which hit me last time I was delivering my Kanban Story presentation was how fragile agile is in terms of people who don’t give a damn. In the summary of presentation I make a point that Kanban may not be for your team if you work with undisciplined engineers.

    But what I realized while I was talking it is not only about lack of discipline. It’s about care. In Kanban people have to care about Kanban board. They have to move cards as they progress with features. They can’t abuse limits unless it is agreed among the team and team rules allow to. They should think how they could improve the board. They should keep the board up to date.

    Why it is so important? Because the board is single most important information radiator in Kanban teams. If contents of Kanban board are random you spread random information about project among the team and outside the team. You pretty much misinform everyone around. And now the important thing:

    In Kanban teams anyone can easily abuse Kanban board.

    It’s enough someone doesn’t care. He doesn’t care to move cards through the board or put his marker on task he’s working on at the moment or ignore transition criteria or whatever. Suddenly you have random Kanban board and no systemic tools to deal with the issue. People versus Kanban 1:0 at halftime. If you want to know how the match ends, well, you’ll have to read the blog in future since it is a subject for another post.

    It’s already half of A4 page and I haven’t really mentioned agile in general. Only Kanban. Kanban this and Kanban that. Don’t I have something else to say? Well, I do, thanks for bearing with me so far.

    One of reasons why Kanban is so easily abused by people who don’t give a damn is the fact that Kanban prescribes close to nothing. But enough of K-word. Scrum is more formal. Actually Scrum is pretty formal approach if you ask me. How it deals with the problem?

    A bit better. Stand-ups, time-boxing and planning meetings are all practices which help to deal with undisciplined team members. (I wanted to write “engineers” instead of “team members” but I’ve just recalled there are no roles in Scrum besides Scrum Master, Product Owner and Team Member and I prefer not to be killed by some Scrum extremist.) With these practices it is easier to make someone stick to convert folks who don’t care. If you work with Scrum you can’t work without time-boxing while the rest of the team has 2-week long sprints. You are asked the same questions as everyone else during stand-ups. There is more of a stick in Scrum than in Kanban. (Have I just said K-word?)

    XP goes even further. Rules are surrounding you everywhere, my poor engineer. It almost tells you how to pee. Not in pairs. fortunately If you work with XP and you don’t give a damn you’re probably already fired.

    But let’s face it – how many teams out there use eXtreme Programming religiously? Few. More of them follow just a couple of engineering techniques choosing Scrum as their process base. And even then we have whole variety of Scrumbuts, Scrumbans and Scrumwhatevers.

    Average agile approach in real world, if there happen to be something like that, would cover a very limited number of rules. I’d say that there would be less of them than Scrum proposes. And even then rules are often softened or teams choose those which are less painful to adapt.

    So we come back to the first point. The fewer constraints (aka enforced practices) we have in place the more easily our process can be abused by people who don’t give a damn. If your method base on a lot of common understanding instead of tons of process documentations and a number of strict rules buying all people in becomes crucial. Having few rules means that you give people power to create and adjust your software development/project management approach.

    It also means you give them power to destroy and harm it.

    If you like this post you should thank Michal who took the discussion up on Twitter.

  • Risk Management in Small Teams

    I was taught risk management the classic way. You know, risk log, voting for probability and impact, finding out which risks are the most painful, deciding on mitigation plan, discussing results etc.

    A cool thing in this old-school process is that it activates different members of the team. Even those, who wouldn’t be asked otherwise. Even those, who would tell you that the project is doomed unless you decide to do something about that performance issue found last month.

    At the same time in small teams this kind of process looks like complete overkill. In small teams which deal with small chunks of work knowledge about risks (about everything actually) is often commonly shared. The problem isn’t about bringing individual opinions to the table. The problem is to make risk management as simple as possible yet still effective.

    An easy and powerful approach here is to forget that there is something like risk management at all. At least to the point where you don’t consider having dedicated formal process to do risk management. Instead you incorporate risk management to everyday tasks: stand-ups, retrospectives, demos, planning meetings etc. You discuss potential risks every time you discuss a task or story. You discuss potential risks whenever you feel about it.

    You won’t even need a risk log. If you talk about risks at every occasion you quickly learn how to catch those which may become painful (filtering by type) and those which are likely to hit you (filtering by frequency of mentioning).

    When you keep talking about risks all the time people learn to deal with them naturally as they work on their tasks. Potential performance problem Luke mentioned yesterday? I’ll run some stress tests as I just have a while and maybe Mike would take a look at database as he’s already tweaking it to build that new feature. The trick is we don’t call it a risk. It is just a performance issue. Possible performance issue actually. Luke just thought it might become a problem but in a couple of days the problem will be gone, this way or another. And you don’t need to use the word risk, have a risk log, perform risk assessment, build and implement mitigation plans etc.

    The only thing you need to have this kind risk management in place is a bit of trust and open atmosphere. Oh, co-location and no-meeting culture may help as well but in small teams both are usually in place already.

  • When Kanban is the Best Choice

    Kanban, as any other methodology, isn’t a silver bullet. There are situations and teams when it shows its full potential but there are others where its impact will be limited. Where Kanban suits best then?

    Micro-sized teams

    It is said Scrum works best with teams of 7 or close to this size. Sometimes we deal with smaller groups. 3 people working on a project isn’t something very uncommon. For such micro-sized teams Scrum is often too formalized. You can limit a number of rules you follow and still keep good quality. And you have a bit more time to do the real work.

    Frequent priority changes

    “Walking on water and developing software from specifications are easy if both are frozen.” Unfortunately we deal with a lot of changes as we build software. There are new features; importance of tasks changes, new top priority bugs requires instant attention. Our response is moving to more flexible approaches. We try to avoid BDUF projects. We switch to agile methods employing short iterations. We even make iterations shorter and shorter. It allows us to change priorities frequently. Once every couple of weeks if we take typical Scrum implementation.

    The problem is when priorities happen to change even more frequently. Once every few days. Or even every single day. And yes, there are such projects. Kanban is a great answer for them. Feel free to change priorities every day. As long as it is well-grounded it shouldn’t ruin your project.

    Maintenance projects

    A typical maintenance project routine looks like this:

    1. Whenever high-priority bug is submitted fix it as soon as possible
    2. Low-priority bugs becomes high-priority ones when resolution deadline approaches; then see above
    3. Whenever a client orders change request (CR) and there’s no high-priority bugs – try to do it as soon as possible
    4. If there are more than single concurrent CR ask project manager about priorities
    5. If there are no bugs or CRs do some refactoring or other improvement job

    Sounds like ideal Kanban playground, doesn’t it? That’s typical case of event-driven development (not event-driven programming) where you don’t actually have a roadmap or something but you do whatever new day brings. After all you don’t expect to have a bug submitted tomorrow, or do you?

    Multiple small projects

    Working on several rather small projects or sub-projects with the same team at the same time is pretty difficult. Resources (what a nice name for your people) are usually insufficient since it is harder to synchronize stream of small orders to keep it at the same level all the time and bringing more people just-in-case isn’t the best business strategy around. This ends up with (surprise, surprise) a lot of priority changes and trade-off games. “We can complete this additional project on time but we’d fail to meet a deadline here or there.”

    With standard structured project management approaches coordinating different threads with ever-changing priorities becomes pretty much a hell. What Kanban does is it organizes workflow so the main, well almost the only, thing you should care about is setting priorities at the beginning of workflow.

    Common part

    The common part for all of environments above is they don’t require many constraints to work. Few simple rules which come with Kanban should be enough to get things done. Another common thing is mid- and long-term planning is hard or even close to impossible, which is another problem hardly resolvable with more structured approaches. These two things are the most specific for environments where Kanban shows its full potential.

    This isn’t really a post which is a part of the Kanban Story but if you found it interesting you should like the story as well.