Pawel Brodzinski on Leadership in Technology

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

Category: kanban

  • Kanban Story: Kanban Board Should Reflect the Reality

    The other day I had a discussion over a Kanban board design. A team has realized the board doesn’t reflect the way they work ideally. We started analyzing what happened. What did actually introduce a disconnection between the reality and the board? We ended up with quite an interesting conclusion. It appeared that the board showed the process as we’d like to see it. Unfortunately in reality the situation was far from optimal. The team wasn’t able to follow the “ideal” process even though they would like to do so.

    A natural reaction was asking a question: should we keep the board as it is and try hard to adjust the way we work to the “right” way, or we should sort of degrade the board to sad reality.

    First of all, I understand why this question pops up. We naturally want to keep the board “better” so as to help us improve our process. We expect the board to be the sign pointing toward the ideal.

    Except Kanban improvements don’t happen this way.

    Yes, you’ve already have my answer in the post title so you shouldn’t be surprised. The board should reflect the reality no matter how sad it is. The reason is simple: when you work with Kanban you make everyday decisions basing on what you see on Kanban board. Now, if the board lies you are likely to make wrong decisions.

    We probably discuss decisions like “whether I should start building another feature or maybe help with testing the other one” or “are we ready to deploy it into production yet?” However, if such wrong decisions stack up they don’t do any good to you, your team or your project.

    Not only is there hardly any improvements at all but you actively harm the project.

    Kanban improvements work differently. People change their behavior or attitude basing on what they see on the board and constraints the board enforces on them and not because the board shows the ideal world. So first, there should be a change in the way the team works and only then we should adjust the board.

    In other words the board should always reflect the reality.

    If you liked this post you may also like the whole Kanban Story series, which is a documentary of one team’s adventure with Kanban.

  • What Kanban Really Is

    I promised to share more thoughts on my Kanban presentation from AgileByExample. Actually during abe2011 there were 3 sessions which touched Kanban in one way or another. And then, well, and then there was a heated discussion, mercilessly cut off by the conference hosts. Even though we didn’t convince each other to our points (after all it isn’t the goal of discussion, is it?) I definitely learned a lot from it.

    First, to set the tone, my presentation.

    Surprising Truth about Kanban Improvements

    I shared the story how, thanks to Kanban, in one of my teams we improved our engineering practices and changed our behaviors. Kanban is such a nice improvement vehicle and I wanted to show it.

    Then, Marcin Czenko shared his experience with Kanban pointing that it is a tool for more experienced teams and that, generally speaking, teams shouldn’t start with Kanban. They should start with something more structured, like Scrum, and only then evolve toward Kanban.

    That’s how the beast has been awakened.

    I’m a living counterexample of Marcin’s hypothesis but that’s not the point. Actually Marcin’s session was just one example of something I kind of know. I mean I remember when I treated Kanban the same way. It was a couple of years ago.

    Let’s consider for a moment that Kanban is a project management of software development approach. With just a few rules Kanban can be a dangerous tool. I mean it leaves much freedom which can obviously be used in many different ways. To sanction chaotic process for example.

    OK, the moment has passed: Kanban isn’t goddamn project management or software development method! Kanban doesn’t tell us how we should build our software. It doesn’t say a word about managing projects. I don’t say you can’t use Kanban to help you dealing with software projects though. You sure can. Heck, this was the initial idea, or so I believe at least. But I beg you; please don’t rely in this area on Kanban alone. And if you do, don’t complain later.

    Kanban is a tool which helps to deal with changes and improvements. If used as they say in the instruction it should allow you to improve. Improve your process, your practices, your behaviors and your attitude. However, Kanban is no guarantee that you will have the best organization around. It doesn’t even give you some sort of benchmark which allows you to compare your team to others.

    With Kanban you don’t go to a specific point, or a specific organization, which looks like for example Scrum by the book. With Kanban you just try to be better tomorrow than you are today. Oh yes, it means that tomorrow you totally can have crappy process, useless practices, bad behaviors and negative attitude, but at least the direction of changes would be right and they would be slightly better than they used to.

    Now, if you treat Kanban as your project management or software development method you are disappointed and rightfully so. You could have done better applying one of proven methods which, when done right, sort many things out from the day one. But don’t blame the method. Blame people, in this example meaning: yourself.

    Coming back to unfinished discussion with Marcin: I would advise Kanban as a good choice for many teams which aren’t experienced much. They actually might very quickly move past the point, which they would have been in if they’d chosen to start with by-the-book method. It all boils down to their attitude to Kanban. As long as they understand how it works achieving quite impressing results is that hard.

    I am well aware this whole thing isn’t obvious and people treat Kanban differently. Especially when they played with it only in one specific environment. I don’t blame them. I explain, I bring examples, I discuss. It seems sometimes I even argue and write longish rants. But it is work which I really love to do. So, thank to Marcin, here it is: an overgrown explanation of one of my favorite David Anderson’s quotes:

    Kanban is an approach to change management. It isn’t a software development or project management lifecycle or process.

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

  • Kanban: When It Is Hard to Map a Process to a Kanban Board

    I was asked for an advice the other day:

    “We have a problem with mapping testing stage into our Kanban board. In ideal world we would test a feature once it is developed, and deploy it on client’s testing environment if and only if every bug we find in the feature is fixed and verified. Unfortunately the reality isn’t that nice – pretty often we deploy a feature even though testing isn’t finished or some bugs aren’t fixed. Sometimes the feature passes user acceptance tests (UAT) even though there are known, sometimes even major, bugs on our side. It introduces a mess into the Kanban board as we have features shown as under testing even though they are already deployed so basing on the board it is hard to say what exactly is happening with a specific feature.”

    One of answers could be: fix your damn development process and bagger off. However I don’t count it as a good answer really. I mean yes, it is broken process which generates mess so we should work on that as well although it’s a longish discussion and it’s definitely not my point here.

    My point basically is: if your process doesn’t suit your Kanban board, adjust the board otherwise every time you look at the board trying to make a decision you will stare at fiction. You don’t want to make decisions basing on fiction, do you?

    OK, in this case a starting point looked something like that:

    The basic problem was that in reality testing was done throughout testing, deployment and UAT phases. Even worse, given that it’s a client who says the feature passed UAT, meaning the exit criteria is acceptance from the client, it was possible that testing was still ongoing while the feature formally was at the right edge of the board (UAT done).

    In short: when looking at the board it was impossible to say which features have been tested, which are being tested and which are yet to be tested.

    A question: how to map such situation into linear process, which we usually have on Kanban board? Well, you basically can’t do it. Fortunately, and correct me if I’m wrong, we were never told that we need to map everything into a linear process. Actually we weren’t even told we need a Kanban board. We were just told to visualize workflow.

    Coming back to the point, we ended up with a conclusion that in this case testing is an ongoing activity happening concurrently during a big part of the whole process. Digging deeper we decided that basically there are only two types of bugs related to any feature: these which would block us to use the application in production and those which wouldn’t. It doesn’t really matter whether a bug is minor but the client insist on fixing it or an issue wasn’t found by the client but from our perspective it is a major problem – we just wouldn’t push the application with this feature into production.

    What struck us at that point was that such information can be easily attached to a feature: we potentially could use a feature safely or not. It’s not a stage of the process – it is a status of a feature. Why shouldn’t we show it as a feature status though? Say, a small red sticky note attached to a feature when it isn’t good to go and a green one when it is.

    To be perfectly compliant with Kanban rules we should make the policies explicit – what does it mean that a feature is or is not good to go? At this point, it was pretty easy. A feature isn’t good to go either when its testing wasn’t completed or we have at least one unfixed blocking bug submitted to this feature. In such situation we should have a small red sticky attached to the feature. On the other hand, a feature is good to go when its testing was completed and there are no open blocking bugs. In this case we attach a small green sticky to the feature.

    One more tweak which was pretty obvious: as we want to distinguish features which we’ve started testing from those we haven’t, we attach small red sticky exactly at the moment when testing starts.

    The board after changes looks like that:

    Looking at the board you can tell that feature C went through internal tests and there are no known blocking bugs. On the other hand, feature D which is at the same stage of the process (UAT) isn’t good to go, for whatever reasons. We also have a situation where feature B, which passed user acceptance tests (UAT) have a red sticky attached to it, which means there is still something wrong with it – most likely a bug found internally but the one which is important enough that it has to be fixed before we consider a feature done-done.

    We can also easily distinguish features which are being tested from those which aren’t. Features F and H are of the former group and features E and G are of the latter. Note that feature E is on the later stage of the process than feature H and yet is wasn’t touched by a quality engineer even though the feature H was. By the way: it may be perfectly reasonable decision when you have to make constant tradeoffs what is more important and goes first and what is less important and waits for its turn.

    To summarize: what we basically did was we came back to roots. When teams start playing with Kanban one of the first things they do is mapping their current process into a Kanban board. It seems this activity isn’t exclusive for the first day only. On occasions we notice that our Kanban boards don’t precisely describe the process we follow and this is exactly the moment to review and improve the board.

    Another lesson here is that you shouldn’t try to adjust your process to simple constraints the basic board sets. If your approach is: the reality should suit my board and if it doesn’t so much the worse for reality, your board will quickly become irrelevant and you will get no value from it whatsoever. If the most basic methods can’t help to map your process into the board look for methods which work, even if it takes some more effort and creativity. The board itself is as flexible as it is physically possible. Given that you use the physical board that is. Use this power.

    And then, once you solved your own problem, don’t forget to improve constantly. In this case I have at least a couple of ideas for improvements but there’s no point in applying all the new ideas unless you validate the older ones. With the right mindset there will be a lot of occasions to try out new concepts with no doubt.

    If you liked the article check out The Kanban Story – a documentary of discovery and implementation of Kanban in one team.

    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 Kanban Story: Skipping Part of Process

    The more complex your process, and your Kanban board, becomes the more likely it is you’re familiar with the following situation: you work on a task which doesn’t go through each and every stage of the process so you’d like to skip one of two of them.

    Consider a very simple board.

    What happens when we build a feature (feature E) where there’s nothing to be documented? What to do with a sticky note on the board? Should the process be changed?

    What happens when we have research task (feature H), which we don’t know outcome of, and we want to put it on the board? What if after research (development) we decide that it’s not going anywhere to a product? I mean we’re done with development but we don’t plan to do anything more about the task: neither testing, nor documentation, nor deployment.

    Before we go further I have another question: does this specific situation happen frequently? If not then don’t even bother. If it is an exception then treat it like exception. You don’t get points for following the process religiously.

    However, if it happens at least from time to time you should probably stop and think. One idea is redesigning the board in a way which incorporates such situation. Except you’ll likely end with conclusion that you have two different processes out there: one for regular development and another for research (or no-documentation development). So we come back to a question what to do with that?

    Well, you can split tasks into two boards but this way you either loosen your limits, e.g. additional limit for one research task, or you lose some flexibility, e.g. splitting your current limits among two boards. Either way I’m not a fan of the approach.

    What we ended up with in such situations was just skipping parts of the process which were irrelevant. No documentation? The sticky note goes directly to documentation done column instead of testing done. No follow-up after research whatsoever? Um, seems like we’re done done with this one so we should probably put the sticky note in the last column.

    Again, we don’t get points for being ideally adjusted to the process. The board should reflect the way we really work and it shouldn’t constrain us too much. If this is how things really look like why shouldn’t we just show it?

    Skipping parts of the process on the board for specific tasks is an option to consider. One advice though: as with any other movement happening on the board, make transition criteria explicit. If something goes directly from development to done column everyone in the team should be able to tell precisely what it means. And of course the answer should be basically the same each time.

    If you liked this story make sure you check the whole Kanban Story series.

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

     

  • Visualization: Don’t Get Attached to a Specific Tool

    If we are in Kanban world when we think visualization we see a Kanban board. We see a process mapped into columns with limits attached to them. We see sticky notes, which represent minimal marketable features. We see additional visuals which help to show priorities, blockers, people who are responsible for a task etc.

    We mentally substitute visualization with the Kanban board.

    To some point it works great. Well, after all it’s not without the reason that a Kanban board, or more generally a task board, became a tool of choice of so many teams.

    However, it was never written that one of few Kanban rules is using Kanban board. Please point me to such advice if I’m wrong. Anyway, the rule is about visualization and Kanban board is only one of possible means to this end.

    One of great lessons from Kanban Leadership Retreat was how many different approaches are possible in terms of visualizing work. Actually typical Kanban board looked kind of boring among that bunch of great folks as basically everyone had at least a couple of ideas how it can be done differently, depending on a specific situation of course.

    The message is: it doesn’t really matter how you visualize your work as long as you are successful at that. Task board or Kanban board is fine, and it usually is very intuitive to use by a team, but quite often there are better ways to do it.

    Consider a situation where you deal with a lot of small tasks. Do you really need to put each and every 5-minute-long tasks onto a post-it? Maybe there are more efficient ways to deal with them?

    On the other hand, what about tasks which last long months? As I’m playing with project portfolio level Kanban it is a very timely question for me.

    A classic form of the board, which I currently use, isn’t likely the best possible approach. I have at least a couple of ideas how to change it. And yes, now that you asked, I was totally inspired on Iceland event to improve my project portfolio Kanban board.

    Probably it won’t be a Kanban board as we know it any more. I will still use stickies and whiteboard but it’s not going to look like any other board I’ve had so far. And that’s the real lesson I got on Kanban Leadership Retreat.

    Don’t get attached to a specific tool. Kanban board is just a tool. Visualization is way, way more than that.

    It’s kind of funny to realize how we learn to treat some things as obvious, like having Kanban board as a part of introducing Kanban. Fortunately, at some point of time we just realize it’s only a tool and we should use it as long as it is useful. If it’s not it’s better to use another one.

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

     

  • Kanban Leadership Retreat

    I spent last few days at Kanban Leadership Retreat. An original David Anderson’s idea was to gather in one place thought-leaders working on Kanban and provide them a platform to exchange experience, ideas and thoughts. I must say it kinda scratched my ego in its back to be invited.

    Anyway I’m still impressed how great the event went. I mean, I know that gathering some great minds in one place and giving them free beer (one evening only, but still) is a sure-shot recipe for a stunning success. To be honest, I did have high expectations. Basically all of them were exceeded.

    As the retreat worked as unconference vast majority of sessions ended up as discussions. There was little-to-none pre-prepared content which was both good and bad. It was good because it really enabled a lot of good discussions and thought exchange but there were moments when I’d appreciate a bit of structure, which is naturally brought by standard presentations.

    Personally I’d also prefer to see sessions a bit more focused on real-life stories than on meta-level but I guess expectations on this one differed.

    Anyway, volume of mind-blowing ideas I’m still trying to think through was astonishingly high. After all, what could you have expected after inviting all those though-leaders, and I take the word “leader” very seriously here, to the same place? By the way: you can definitely expect some of those ideas shared here in near future.

    Actually I went to the retreat with a goal to discuss a few of them: portfolio-level Kanban, Kanban failures and methods of selling Kanban to teams and organizations. Lucky me, each of them have made it to the event program. And basically each of the sessions looked totally different than I’d projected. This basically means I got a new, and unexpected, perspective on ideas I’d already had which, by the way, might make attending my future sessions on Kanban way more valuable, if you excuse this shameful plug.

    But all in all it wasn’t the content which was the most valuable for me. People were. I always say that networking is the most important part of any event but this time it was totally on steroids. The format of unconference, the choice of people and never-ending Icelandic days made it the ultimate networking event. If, by any chance, I looked as a child in chocolate factory please forgive me – I had damn good reasons to look so.

    I should probably mention all great folks I was talking to, which would be kind of boring for people who weren’t there, so I’ll refrain (BTW: if somebody is curious please check people I recently followed on Twitter). But if you are the one of them I’d like to genuinely thank you for all the stuff I learned from you.

    Huge thanks for organizing the whole thing goes to David Anderson and his staff along with Hillel Glazer, who facilitated the event.

    Personally I will be there next year. That’s no-brainer for me. If any of you, by any chance, is invited you shouldn’t hesitate whether it is a good idea to go even for a second.

  • Visualize Everything

    One of Kanban rules is visualization. This is one I like the most since I just can’t sit at ease next the the clear whiteboard. I have that urge to grab a marker, a bunch of sticky notes and make the board a little less white.

    Anyway, visualization isn’t the concept unique for Kanban (what is after all?) and recently you probably hear about it very often. It was one of returning messages across this year’s ACE Conference and it was very similar at GOTO Copenhagen – Dave Thomas pointed it as one of key factors of successful teams. And then of course there was all-day long Kanban track which, as you may guess, was covering visualization over and over again.

    So the message is: visualize it! Show what you’re doing on the board. Make it visible for everyone in the team. Make it visible so everyone knows what’s happening. Make it visible so it’s hard to ignore that, especially when things go wrong.

    We are inevitably heading toward the question: what “it” is?

    Well, “it” is pretty much anything. Because it’s not just “visualize it” – it’s “visualize everything.”

    Stages of your process? Checked. Limits? Checked. Who does what? Checked. Blockers? Checked. Cycle time? Checked. Priority? Checked. Area or module of a project? Checked. Emergency state? Checked. And this is only the beginning. These are actually the most obvious examples. Add to your sticky notes any information a team will need. Put it on the board. Visualize it! It is a way of communication. And the one which isn’t intrusive.

    It may sound a bit counterintuitive but it works miracles. My recent playground is project portfolio level Kanban and the interesting observation I’ve made already is how the board helps me every time I need to plan new projects or make a tradeoff to respond to changing situation. It even tells me when I need more people faster than our budgeting software, which we typically use for this purpose.

    The reason is simple: visualization just works. So go, visualize everything!

    Advertisement: Want to have gorgeous Kanban boards in your PowerPoint presentations? Check InfoDiagram Kanban Toolbox. Use pawelBBlog code to get $10 discount.

     

  • Surprising Truth about Kanban Improvements

    My session at GOTO Copenhagen was on Kanban improvements. My goal was to show the mechanics of improvements in teams adopting Kanban and you probably know me enough to know I wanted to build the session over real-life examples. Here is what I ended up with.

    Kanban Improvements – Emergent Behavior

    The result was a bunch of stories following similar pattern: we introduced Kanban, then some existing behaviors became visible and finally we started improving doing it either consciously or not. That was basically the point I thought about when I started building the presentation.

    However when you think about it longer you notice that it’s not that simple. I mean the pattern itself is simple, but that’s not all. It’s just the tip of the iceberg.

    Let’s take collective code ownership – one of my favorite examples. Consider you start with a typical situation where code ownership isn’t collective at all. You deal with bus factor of one and your life is miserable. Given that you adopt Kanban, your developers should start pulling different features to work on, not necessarily features which deal with the code written by themselves. They want it or not they have to start learning code written by others and knowledge is slowly spread among the team members. Eventually, after some time, the code is owned much more collectively than it used to be.

    It’s a nice example. If we stop here it is still a nice story of improvement. But if you look a bit closer there’s much more than just that.

    Let’s go back to developers pulling features from codebase they aren’t familiar with. A question: what do you think a decent developer will do in such situation? Probably they’re going to start with learning what a feature is all about. Then, and it now becomes interesting, they will start learning the code they will be changing and updating. This activity has even a name – code review. You may argue, but it actually is code review. It probably isn’t very formal but last time I checked you weren’t getting point for making code reviews as formal as possible.

    It starts looking better, isn’t it? Let’s move to the next step then.

    We have the situation where a decent developer is reviewing someone else’s code. I bet they spot some bad code out there. It’s kind of safe bet – we aren’t machines so we do make errors on occasions. What’s next? Well, one of ideas is to find the one who wrote that crap and make them fix it. Except it doesn’t work, because the author is either busy, already working on different project or left the company 3 months ago. It’s much more likely that the developer would improve the code by themselves. And you already have guessed – this one also has a name: refactoring.

    It looks like it’s not only collective code ownership but we also get code reviews and more refactoring in the package.

    That’s not all.

    Look at the situation focusing on how it changes people. You teach them good practices and you do it by example. You don’t just try to convince the team that code reviews are good. You kind of trick people to actually start doing it. You give them a precious gem – real experience instead of just an opinion. You push people to learn.

    Quite much of that already, but if you think I can’t draw another connection you’re wrong. This is the last one, I promise. At least for now.

    Probably the best thing which happens here isn’t really about engineering practices. It isn’t about learning either – after all you shouldn’t need to push people to learn anyway. The best thing is you draw people out of their comfort zones on so many levels. They start working on unfamiliar code, they start using new practices, and they start learning new things. In terms of everyone’s personal development you couldn’t do them a better favor.

    OK, now remind me where we have started. I believe it’s been drawing a connection between introducing Kanban and collective code ownership. How come we’ve gone that far?

    This is exactly the surprising truth about Kanban improvements. There is no detailed plan of adopting specific practices or improving specific things. You just set the proper framework and let people figure out the rest.

    I really like the metaphor David Anderson shared: it’s like organizing a good party. You bring food and beverages, you have music, you organize enough room to chat, eat, dance, etc. And most importantly you invite the right people. In details you don’t know what will happen. Your goal isn’t to plan everything to the last possible bit. You just create a framework for people to have fun.

    Same applies to Kanban. It’s just a framework for people to improve. You bring your board and a bunch of simple rules. You show them the idea, but then it’s up to them where they’re going to take to whole thing.

    You end up observing interesting connections between Kanban, collective code ownership, code reviews, refactoring, learning, moving people out of their comfort zones, etc. Continuous improvement in Kanban is rather a complex mechanism inside, yet it doesn’t mean it is hard to operate it. It kind of operates itself. And this is exactly the reason why it is so great.

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

     

  • The Kanban Story: Standard-Sized Features

    It’s been some time from the previous chapter of the Kanban Story but it doesn’t mean we’ve stalled. There’s an interesting concept which I keep referring to but only recently realized I’d never really written about it.

    The concept is called standard-sized features.

    If you read about Kanban you just have to be familiar with the term Minimal Marketable Feature, which is a piece of functionality which is as small as possible, yet sellable to a potential customer. It is a very nice concept and that was exactly what we started with when we were adopting Kanban.

    However, after some time we realized that we sacrificed marketability of our features in order to get them similar in size. This change wasn’t really planned. It just seemed more convenient on occasions to split the work that way.

    It might be easier for us since we were never orthodox with MMFs. After all how could you possibly marked some architectural changes or rewriting one of integration interfaces from scratch? Anyway that wasn’t a reason to come up with standard-sized features (should I call them SSFs?)

    SSFs were born because we needed to prepare some estimates for fixed price projects even though for most of these projects preparing estimates was the only activity we were performing. It is a kind of situation when you don’t really want to invest lots of time yet you still want to come up with some reasonable numbers in case you actually get the project and are expected to deliver it.

    In such environment MMFs can be tricky. I can perfectly market a feature which consists like a couple dozen lines of code if it is the right code in the right place. On the other hand for some other features you may need tons of code until finally there is something which can possibly be sold to anyone, assuming that they’re partially crazy and would buy some half-baked functionality.

    So yes, MMF can differ vastly in size. And this renders your average measures, like average cycle time, pretty much useless. If variation of cycle time is big so you may deliver it in 2 days but you can also deliver it in 2 months, depending on what kind of MMF it is, you can’t base on average or median. This way if you’re out of luck and get a bunch of huge MMFs you’re also totally screwed.

    The answer can be SSF. With standard-sized features you don’t really care what you can market. Actually that’s probably not the case for majority of teams since we rarely directly sell our crap… I mean products. SSFs however allow you to deal neatly with estimation. You can use some simple methods to come up with a number which would go into a formal agreement like instantly, no matter how hard you try to explain a salesman what coarse-grained estimate really means.

    Another nice trait of SSF is it helps make flow smoother. If feature’s size differs much you tend to have those big tasks hanging there for a longer time. It makes the team less flexible, as part of the team is dedicated to work on this specific task, and it consumes part of the limit for a longer time which may yield some blockers.

    One of arguments against SSFs I heard is it’s pretty hard to learn how to get features standard-sized. Probably if you want to make them all delivered in 9 days sharp it is hard indeed. However you don’t aim for such accuracy. Variation between 6 and 12 days is completely enough. Anyway the surprising thing, at least for me, was we quickly became pretty good in splitting the work into standard-sized chunks of work. It looked like we didn’t even try and got it right, so we just kept doing the good job.

    Standard-sized features proved to be valuable so you might consider them as one of options when deciding what exactly you want to have on your sticky notes you put on the Kanban board.

    If you liked this story make sure you check the whole Kanban Story series.