Pawel Brodzinski on Leadership in Technology

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

Category: project management

  • The Project Portfolio Kanban Story: A Basic Approach

    You already know why I decided to try out Kanban as a tool to organize our project portfolio. To be honest I didn’t spend much time on considering the initial Kanban board design. Remembering about experimentation mindset you should have when using Kanban I decided to start with anything which seemed sort of reasonable and adjust the whole thing on the way.

    One of observations I made recently is how we stick to standard Kanban board designs. It seems that this is a path of least resistance – to use what we already know and are familiar with. I pretty much did the same. I started with a design that I used when I was applying Kanban on a team level. I just tried to map a process in a very generic way to a list of stages, and then track projects as they go from the left side of the board to the right.

    This is what I started with:

    As you can see I started on a pretty high level. We had projects we expected to start soon, and most of them eventually were started. Then we had whole ongoing phase separated only to three, very generic stages.

    As our clients are typically rather big companies most of the time we have pretty formalized analysis phase at the beginning of a project. This stage was worth separating as it there are significant differences, both in terms of effort we invest and people involved, between analysis and building stages.

    Then there was generic building phase. I didn’t try to track details for example in projects where we had iterations. I didn’t try to show specific stages in projects where we could define them. One reason was that the development process isn’t homogenous – depending on a client, a size and a type of a project, a development team and a few other criteria this process can look differently. Another reason was I didn’t want to go into deep details, especially not with the first version of the board. After all it was expected to be changed.

    The last building stage sub-column was representing projects which went into user acceptance tests. Similarly to analysis, pretty typical stage, even for clients that get iterative deliveries. And again, a part of a process we wanted to distinguish as it usually is a pretty specific in terms of team’s involvement.

    Finally, there was maintenance column which is sort of done column on steroids. On a typical Kanban board done column is a way to say that we don’t plan to do anything with an item which made it way there. Eventually, we remove an index card or a sticky note from the column to make a room for incoming ones. On a project portfolio level moving cards into the last column is sort of double blessing. Not only do we know that we are done with building a project but we also switch into maintenance mode, which is usually the most profitable stage of a project lifecycle.

    A pretty natural move to make was attaching team names to project index cards. Even though we were changing teams responsible for projects very, very rarely I decided to go with small stickies attached to index cards as sometimes it happens that a couple of teams are working on a single project.

    Now, a couple of things which weren’t that intuitive with this project portfolio Kanban board. First, there were no limits whatsoever. I played with the idea of adding some but eventually, I came to a point that it’s not only a number of projects that matters but the size of them is equally important. In other words one team can cope with a single big project or a few smaller ones concurrently and both are perfectly acceptable scenarios. I just decided to see how it goes and make up my mind about limits later on.

    Second, the board wasn’t really co-owned by everyone in the team. OK, in a team of almost 150 people it would be sort of difficult to have a board co-owned by everyone. However, considering there are just about a dozen project teams we could have one representative of each team and we all could perfectly work on a single board. Well, we theoretically could, if not the fact that we were spread over the whole building. Also, I didn’t want to enforce on each and every team a new duty which might well change pretty soon.

    I decided to start with this project portfolio Kanban board treating it like a personal Kanban board. It was owned, updated and changed only by myself; although anytime I was learning a new fact on any of projects I was updating the board. Soon enough I started having visits not because I was in the room, but because the board was there.

    A nice side-effect of such approach was that I could have my project portfolio Kanban board on one of whiteboards in my room which meant it was always at hand.

    Either way, I knew it was sort of temporary state. The goal was either to move toward co-ownership of the board or dropping the tool all along. As later appeared I pursued this goal soon, but that’s a subject for another chapter of The Project Portfolio Kanban Story.

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

     

  • The Purpose of Retrospectives

    Those of you who read Software Project Management regularly know for sure that I have sort of experimentation attitude. I like to try different things, see how they work and, if they sort of do, share my experience here with you. I’m particularly happy with a bunch of such concepts, one of them being ad-hoc retrospectives.

    This story is more than a year old, but recently Bernd and Ilja from it-agile reminded me about it with their comments under the post.

    A short version of the idea is that, instead of doing regular retrospectives bi-weekly, monthly, or whatever your cadence for retrospective is, you do a very short and focused ad-hoc discussion on a single problem raised by any team member. The outcome should be similar to what you get from a regular retro – an action point, or a bunch of them, aimed at solving the issue. In my case the whole mechanism proved to work very effectively. If this teaser sounds interesting I strongly encourage you to read the full story.

    Both Bernt and Ilja pointed that I shouldn’t call it a retro. As Ilja puts it:

    Retrospectives are more than just meetings where you solve problems you are already aware of, anyway.

    Well, I guess we are in full agreement on this one. The only difference is I actually believe that even with ad-hoc retrospectives we are (usually) solving problems that we aren’t yet aware of. At least we aren’t when we launch the retro. Pretty often we start with just a symptom. Someone spots something that they think is worth discussing. So here we are – at ad-hoc retro.

    First, we don’t have to agree that this is a real problem and often, initially, we don’t. Thus a discussion. Even though we actually are focused on this single starting point, we dig deeper trying to find some common denominator for our views.

    Second, as I’ve already told you, we usually start with just a symptom. Quite often we are yet to discover, and address, a root problem.

    Finally, we try to come up with some action points to fix a root cause we agree on.

    Now, I happen to facilitate a bunch of regular retros recently and all of them seem to follow similar pattern, no matter the team or the organization. We start with a handful of things we like or don’t like, try to cluster them somehow, look for root causes and address them. However, it all starts with observations people make.

    It’s not some kind of magic that tells us what we are doing wrong. It’s not an outsider who comes and blesses us with an epiphany. It’s not a scientific process which makes us come up with the right solution. It’s the team that finds it out by themselves.

    In both cases: regular and ad-hoc retros the outcome is similar, the process is similar and even the same people do the job. The main difference is granularity. While during a regular retro we try to cover things which happened during a specific time-box, on ad-hoc retrospective we start with just a single idea. An idea we would write down on the on a sticky note at the very beginning of the next regular retro anyway. In other words we would bring it up as well, no matter the process.

    I just wanted to add that another difference is, that during typical retros, not every problem is acted on. We usually try to focus just on a bunch of most important things at the moment. However, on a second thought it works the same with ad-hoc retrospectives. Sometimes after a brief discussion we just decide to leave a thing alone for the time being. We either don’t share views of a person who proposed the issue or don’t see any action points that we could agree on or whatever else. So similarly to regular retrospectives the outcome can be “do nothing” too.

    If nothing so far convinced you that both concepts are surprisingly similar I have a question about a purpose of retrospectives. It is improvement, isn’t it? We want to do better in future that we’ve just done. If so, we can perfectly do this job using both approaches. Of course, depending on a team’s maturity I would go with one or another, but that’s a totally different story.

    Of course we can bring it down to some orthodox discussion over definitions, but don’t count in. I’m more into solving problems than arguing over definitions. It just feels more useful.

  • Get Rid of Estimation

    Software estimation. Ah, a never-ending story. Chances are good that, whenever you’re talking about building software, this subject will pop up soon. You can be pretty sure that basically everyone around has problems with estimation or simply struggles with it. And that’s virtually obvious that there would be a new sexy method of estimation every year or so. The method which is claimed to solve an unsolvable puzzle.

    Recently there was yet another question on estimation on Project Management StackExchange. This sole fact isn’t probably worth writing a whole blog post about that, but there was one side thread which is worth focusing at.

    One of advices I shared was that whenever you can you should avoid estimation at all. This sprung sort of objection. OK, so the subject definitely is worth wider discussion.

    First things first. Why do we estimate at all in the first place? Well, we usually want to know how much time it’s going to take to build this damn thing, don’t we? Um, have I just said “usually?” Meaning, “not always?” Actually yes. It’s not that rare when we either don’t need any estimate at all or we just want to have a general insight whether the project will be built in hours, days, weeks, months or years. In either of these cases just a coarse-grained wild-ass guess should be fine. If it’s needed at all.

    OK, but what about majority of cases when we need some kind of real estimate? For example all those fixed price projects where estimates are basically a part of risk management, as the better the estimate is the smaller are chances that the project goes under water. I can’t deny that we need to have something better than wild-ass guess then.

    Yet, we still can avoid estimating quite often.

    Let me start with one of obvious things about estimation: if you base on historical data, and you apply them in a reasonable way of course, you can significantly improve your estimates. In other words, no matter the method, if you are just guessing how much something is going to take, you will likely to end up with way worse results when compared to a method, which uses your track record. And yes, I just dared to name planning poker “guessing.” It is collective, involves discussion, etc but usually it is just this: guessing.

    Cool, let’s use historical data then. What’s next? My next question would be: how precise must your estimates be? Seriously, what kind of precision you aim for? My point is that we need very precise estimates very rarely. This is by the way the reason why I don’t use Evidence Based Scheduling anymore.

    Anyway, ask yourself a question: how much you would pay for bringing your estimates to the next level of precision. Think of it like being correct in terms of estimating in years, months, weeks, days, hours, etc. Let’s take just an average several-month-long, fixed-priced type of project.

    If I’m wrong with years I’m totally screwed, thus I’d pay significant part of project budget to be correct on such level. If I’m wrong with months it might be a hit on our reputation and also it may consume our whole profit we get of the project, so I’d be ready to invest something around the profit to be correct with months. Now weeks. Well, a week here, a week there, does it make such a difference in this kind of project? Can’t I just assume there is some variability here? Unless of course our deadlines are written in stone, e.g. you adjust your software to law changes. In most cases I’d invest just a handful of bucks here at best. Days? Hours? Are you kidding? Does it even make a difference that I spend a day more on such project?

    Now you know what kind of precision you expect from your estimates. Would it be possible for you to come up with estimates of such precision basing purely on historical data? I mean, can’t you just come up with a simple algorithm which automatically produces results reasonable enough that you can forget about all the effort spent on estimation?

    Whenever we come to discussing estimation I like to share the story from one of my teams: basing on a fact that we were collecting data on our cycle times and we reduced variability in task sizes coming up with the idea of standard-sized features we were able to do a very good job with estimates not estimating at all. We were simply breaking work down so we could learn how many features there are to build and then we were using very simple metrics basing on our track record to come up with the numbers our sales department requested. By the way: a funny thing is, almost all of that appeared as an emergent behavior – something we started doing as a part of continuous improvement initiative.

    Either way, even though we were capable of providing reasonably precise and reliable estimates we didn’t really estimate. I was surprised how easy it was to get rid of estimation, but then I can come back to the point from the beginning of the article: what is the point of estimation? You don’t do it just for the sake of performing the task; you do it for a reason. As long as you achieve your goal, does the method really matter? It means that you can get rid of estimating even if you do need some kind of estimates.

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

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

  • Project Management in One-Man Project

    Recently I came across a very interesting question on Project Management Stack Overflow. The question is how to organize project management in tiny projects, where everything is done by a single person or just a couple of them.

    The interesting thing here is that when we think about the point where organization introduce formal PM role we usually see at least a few dozen people. So how about startups, where just a few people are working in the whole organization?

    Let’s consider one-man project. I leave aside all tasks directly related with software development, so for the sake of this article I don’t care about version control or bug tracking. Which leaves us with a few of basic areas.

    • Scope management

    You actually need to know what you’re going to do. At least on general level. Actually in startups it’s not a good idea to have detailed plans of development since, well, what you start with is wrong and you’re going to change the course along the way. However if you don’t know, even roughly, where you’re going and you can hardly tell what is your goal then you might look for another project or another job instead because you’re not succeeding. So yes, a bit of scope management is crucial – you have to know that you’re building a tower and not, say, space ship.

    • Task management

    You already know where you generally are going. Good. Now you have to figure out the next step. Or the next feature you’re going to build. Then you build it. And you repeat the process. I mean from the point when you figure out the next step, not from setting the general direction. Of course you don’t have to be so short-sighted to plan only a feature ahead but you do need to break the scope down to smaller tasks and start building your tower brick after brick. And of course you need to know which brick goes first and which goes next.

    • Product management

    This is kind of tricky. Actually if you know the scope and you dealing well with tasks you pretty much have this one covered. Given that you’re building the right thing that is. Product management in such small project is all about making sure that you’re building the right thing. It’s not on brick level but you need something more than just a picture of tower pinned over your desk. You actually have to know that you want to keep bad people in hostage there so you need cells, torture chambers and such. Then you need to figure out how these things should work so clients… I mean hostages are served… I mean tortured well.

    • Communication with users and/or clients

    Finally, you need to verify whether your dream about best of the breed torture tower is something people actually want. You need to regularly confront your ideas with clients or users or both (depending on your target group) to make a sanity check: are we still going into the right direction. Yes, you need to talk with those tortured poor souls to learn whether they’re happy with the service. You might also check your butchers – they do use your product as well. If the tower isn’t ready, go find potential customers and potential users and get their feedback. Since you’re running one-man project you don’t have clearly defined requirements so this part is even more important than in typical projects.

    Now, I’m well aware these areas aren’t strictly connected with project management as some corporate PMs out there know. In big teams PM can be isolated from product management and from end users, scope can be thrown at the project team in huge specification before the project starts, but well, we don’t discuss big teams working on boring BDUF project here, do we?

    By the way PMSE (Project Management Stack Exchange) site is awesome not only in terms of inspiring blog posts. You will find there a lot of great stuff so what are you waiting for? Go check the site.

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