Pawel Brodzinski on Leadership in Technology

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

Tag: best practices

  • Flailing Around with Intent

    Flailing Around with Intent

    Knowing is not enough; we must apply. Willing is not enough; we must do.

    Johann Wolfgang von Goethe

    Does it sometimes happen to you that you try to explain something in a detailed way to someone, and that person responds with a one-liner that nails the idea? I suck at brevity, so it happens to me a lot.

    That’s one reason why I appreciate so much the opportunities to exchange ideas with smart people from lean and agile communities.

    The most recent one happened thanks to Chris Matts and his LinkedIn post on agile practices. Now, I’d probably pass on yet another nitpicky argument about what’s agile and what’s not, but if it comes from Chris, you can count on good insight and an unusual vantage point.

    Community of Needs

    One reason that I’m always interested in Chris’ perspective is that he operates in what he describes as the Community of Needs.

    Members of the Communities of Needs operate in the area of “Need” to create a meme and then work with the meme to identify fitness landscapes where it fails, and evolve them accordingly. These communities have problems that need to be solved. They take solutions developed for one context and attempt to implement them in their own context (exaption), and modify (evolve) them as appropriate.

    If you dissect that, people in the Community of Needs will:

    • Focus on a practical challenge at hand
    • Be method/framework-agnostic
    • Understand the specifics of their own context and its differences from the original context of a solution
    • Seek broad inspirations
    • Be crafty with makeshift solutions

    The word ‘practitioner’ comes to mind, although it might be overly limiting, as the Community of Needs describes more of an attitude than an exact role one has in a setup.

    One might propose ‘thinker’ as the opposite archetype. It would be someone who distills many observations to propose a new method, framework, solution, etc.

    Thought Leaders

    Let’s change the perspective for a moment. When we look at the most prominent figures in lean & agile (or any other, really) community, who do we see? As a vivid example, consider who authored the most popular methods.

    All of them ‘thinkers’ (in Chris’ frame, members of the Community of Solutions), not ‘practitioners.’

    Before someone argues that the most popular methods stem from practical experiences, let me ask this:

    When was the last time the founding fathers (they’re always fathers, by the way) of agile methods actually managed a team, project, or product? It’s been decades, hasn’t it?

    Yet, these are people whom we rely on to invent things. To tell us how our teams and organizations should work. We take recipes they concoct and argue about their purity when anyone questions their value.

    I mean, seriously, people are ready to argue that the Scrum guide doesn’t call daily meetings ‘standups,’ as if the name mattered to how dysfunctional so many of these meetings are.

    It seems the price to pay for such thought leadership is following rigidity, preceptiveness, and zealotry. Thank you, I’ll pass. It feels better to stay on the sidelines. I will still take all the inspiration I want when I consider it appropriate, but that’s it. It’s not going to become a hammer that makes me perceive every case as a nail.

    Where Theory Meets Practice

    I admit that I have a very utilitarian approach to all sorts of methods and frameworks. If there’s a general guideline I follow, it’s something like that:

    Try things. Keep the ones that work. Drop those that don’t.

    Put differently, I just flail around with an intent to do more good than harm.

    Over the years, I’ve learned that a by-the-book approach is never an optimal solution. Sure, occasionally, we may consider it an acceptable trade-off. In my book, though, “an acceptable trade-off” doesn’t equal “an optimal choice.”

    Almost universally, a better option would be something adjusted to the context. A theory, a set of principles, a method, a framework—each may serve as a great starting point. Yet my local idiosyncrasies matter. They matter a hell lot.

    A smart change agent will take these local specifics into account when choosing the starting point, not only when adjusting the methods.

    For one of the organizations I worked at, Scrum was not a good starting point. Why? Were their processes so unusual that they wouldn’t broadly fit into the most popular agile method? Or maybe a decision maker was someone from another method camp? Might they be subject to heavy compliance regulations that forced them into a more rigid way of working?

    Neither. It’s simply that they had tried Scrum in the past, and they got burned (primarily because they chose poor consultants). The burn was so bad that anything related to Scrum as a label was a no-go. Working on the same principles but under a different banner simply triggered way less resistance.

    Local idiosyncrasies all the way. Without understanding a local context, it’s impossible to tell which method might be most useful and how best to approach it.

    Portfolio Story

    When we operate within the Community of Needs, even when we don’t have a strong signal like the one above, we rarely have a single ready answer.

    Consider this example. As a manager responsible for project delivery across the entire project portfolio, I was asked to overcommit. And not just by a bit. While already operating close to our capacity, top leadership expected me to commit to the biggest project in the organization’s history under an already unrealistic deadline.

    By the way, show me a method that provides an explicit recipe for dealing with such a challenge.

    At its core, it wasn’t even a method problem. It was a people problem. It was about getting through the “but you have to make it work and I don’t care how; it’s your job we pay you for” and starting the conversation about the actual options we had. You might consider it almost a psychological challenge.

    My goal was not to educate the organization on portfolio management, but to fix a very tangible issue in (hopefully) a timely manner.

    If I had been a Certified Expert of an Agile Method™, I might have known the answer in an instant. Let’s do a beautiful Release Train here, as my handbook tells me so. I bet I’d have a neat Agile Trainwreck™ story to tell.

    In the Community of Needs, we acknowledge that we don’t have THE answer and assess options. In this case, I could try Chris Matts’ Capacity Planning, which emerged in an analogous context. I might consider one of Portfolio Kanban visualizations, hoping to refocus the conversation to utilization. Exploiting Johanna Rothman’s rolling wave commitments might help to unravel the actual priorities. Inspiration from Annie Duke’s bets metaphor could be tremendously helpful, too.

    Or do a bit of everything and more. Frankly, I couldn’t care less whether I would do that by the book, even if there were a book.

    Ultimately, I wasn’t trying to implement a method. I was trying to address a need.

    Flailing Around with Intent

    It all does sound iffy, doesn’t it?

    “You can’t know the answer.”
    “You should know all these different things and combine them on the fly.” “Try things until something works.”

    Weren’t the methods invented for the sole purpose of telling us how to address such situations?

    They might have been. Kinda. The thing is, they respond only to a specific set of contexts. Or rather, they were designed only with particular contexts in mind, and they fit these circumstances well. Everything else? We’re better off treating them as an inspiration, not an instruction.

    We’re better off trying stuff, sticking with what works, getting rid of what doesn’t.

    As Chris put it:

    “Flailing around with intent is the best we can do most of the time when we are trail blazing beyond the edge of the map.”

    Chris Matts

    So, if you want a neat two-liner to sum up this essay, I won’t come up with anything remotely as good as this one.

    The Edges of the Map

    We could, of course, discuss the edges of the map. The popularity of a method may suggest its broad applicability. Take Scrum as an example. Since many teams are using Scrum, it must be useful for them, right?

    On a very shallow level, sure! Probably. Maybe. However, if something claims to be good at everything, it’s probably good at nothing.

    The Scrum Curse

    The more ground any given method wants to cover, the less suited it is for any particular set of circumstances.

    And if one wants to build a huge certification machine behind a method, it necessarily needs to aim to cover as much ground as possible.

    So, what is a charted map for Scrum? Should we consider any context where the method could potentially be applied? If so, the map is huge.

    However, if we choose the Community of Needs vantage point, and we seek the most suitable solution for a specific need we face, then the map shrinks rapidly. It will be a rare occurrence indeed when we choose Scrum as the optimal way given the circumstances.

    Then, we’re trailblazing beyond the edges of the map more often than we’d think. And flailing around with intent turns into a surprisingly effective tool.

    Thank you, Chris Matts and Yves Hanoulle, for the discussion that has influenced this article. I always appreciate your perspectives.

  • The Fallacy of Shu-Ha-Ri

    Shu-Ha-Ri is frequently used as a good model that shows how we adopt new skills. The general idea is pretty simple. First, we just follow the rules. We don’t ask how the thing works, we just do the basic training. That’s Shu level.

    Then we move to understanding what we are doing. Instead of simply following the rules we try to grasp why the stuff we’re doing works and why the bigger whole was structured the way it was. We still follow the rules though. That’s Ha level.

    Finally, we get fluent with what we do and we also have deep understanding of it. We are ready to break the rules. Well, not for the sake of breaking them of course. We are, however, ready to interpret a lot of things and use our own judgement. It will sometimes tell us to go beyond the existing set constraints. And that’s Ri level.

    I’ve heard that model being used often to advise people initially going with “by the book” approach. Here’s Scrum, Kanban or whatever. And here’s a book that ultimately tells you what to do. Just do it the way it tells you, OK?

    Remember, you start at Shu and only later you’d be fluent enough to make your own tweaks.

    OK, I do understand the rationale behind such attitude. I’ve seen enough teams that do cherry picking without really trying to understand the thing. Why all the parts were in the mechanism in the first place. What was the goal of introducing the method in the first place. On such occasions someone may want to go like “just do the whole damn thing the way the book tells you.”

    It doesn’t solve a problem though.

    In fact, the problem here is lack of understanding of a method or a practice a team is trying to adopt.

    We don’t solve that problem by pushing solutions through people’s throats. The best we can do is to help them understand the method or the practice in a broader context.

    It won’t happen on Shu level. It is actually the main goal of Ha level.

    I would go as far to argue that, in our context, starting on a Shu level may simply be a waste of time. Shu-Ha-Ri model assumes that we are learning the right thing. This sounds dangerously close to stating that we can assume that a chosen method would definitely solve our problems. Note: we make such an assumption without really understanding the method. Isn’t it inconsistent?

    Normally, the opposite is true. We need to understand a method to be able to even assess whether it is relevant in any given context. I think here of rather deep understanding. It doesn’t mean going through practices only. It means figuring out what principles are behind and, most importantly, which values need to be embraced to make the practices work.

    Stephen Parry often says that processing the waste more effectively is cheaper, neater, faster waste. It is true for work items we build. It is true also for changes we introduce to the organization. A simple fact that we become more and more proficient with a specific practice or a method doesn’t automatically mean that the bottom line improves in any way.

    That’s why Shu-Ha-Ri is misguiding. We need to start with understanding. Otherwise we are likely to end up with yet another cargo cult. We’d be simply copying practices because others do that. We’d be doing that even if they aren’t aligned with principles and values that our organization operates by.

    We need to start at least on Ha level. Interestingly enough, it means that the whole Shu level is pretty much irrelevant. Given that there is understanding, people will fill the gaps in basic skills this way or the other.

    What many people point is how prevalent Shu-Ha-Ri is in all sorts of areas: martial arts, cooking, etc. I’m not trying to say it is not applicable in all these contexts. We are in a different situation though. My point is that we haven’t decided that Karate is the way to go or we want to become a perfect sushi master. If the method was defined than I would unlikely object. But it isn’t.

    Are there teams that can say that Scrum (or whatever else) is their thing before they really understand the deeper context? If there are then they can perfectly go through Shu-Ha-Ri and it will work great. I just don’t seem to meet such teams and organizations.

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

  • 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: Swarming

    If you’re into Kanban you probably have heard the term swarming. Actually chances are good you’ve heard the term despite your lack of interest in Kanban.

    What is swarming?

    In short swarming is all about getting more people to do the task than you’d get otherwise, in normal situation. An example: you have a bug which normally would be fixed by a single developer, but for some reason you have the whole team working on it. And you already have another question…

    Why, oh why?

    Why would you want people to swarm around a small task? Typically teams do this when they face either a blocker, which hampers whole team, or a very difficult problem, which is hardly solvable by a single person. Either way you get more people to move things further, which would be impossible or at least very difficult otherwise.

    Swarming in Kanban, part 1

    Up to this point swarming is something teams do intuitively at times. The reason why the term is mentioned so often in the context of Kanban is one of Kanban rules: limiting work in progress. Because in Kanban we want to have as few ongoing tasks as possible, yet as much as it still does make sense, we have limits for different stages of our process. And it when we hit the limit we treat it as a problem which we want to solve and we want to solve it fast. That’s why we swarm.

    Swarming in Kanban, part 2

    There is another thing which you may read about, which I call everyday swarming. Everyday swarming is done by teams which swarm by default, when no emergency situation happens. The reason standing behind this behavior is trying to make cycle time and/or lead time as short as possible thus flow of tasks very rapid and smooth. Oh, and you have fewer ongoing tasks then too, which means you have less work in progress, which means you have less waste, which means you are oh so lean.

    Our story

    I must admit I don’t really like the idea of everyday swarming. I mean cycle time is definitely shorter but I’m so sure about throughput. Flow is smoother but you kick in a lot of micro-switches when a few people need to integrate their work into one piece of code since they all have worked on a single feature. You also may invite some issues with version control this way since you’ll be working on the same chunks of code. For me the net weight of swarming by default is negative.

    Basically that’s why we avoid swarming whenever possible. When there is some serious problem to solve and standard approach is not enough we naturally help each other. One person after another joins the rescue team and this basically ends as swarming. But other than that we prefer to have only one person working on the task at the same time. Well, of course there are exceptions like discussing design or testing and bug-seeking/bug-fixing but these all are pretty natural things for any software development team. After all it would be pretty schizophrenic to discuss the design with oneself.

    It looks like we swarm as David Anderson initially proposed, despite ignoring David’s teachings when it comes to lead time. I think this is the most natural way of swarming. But of course you remember the rule to experiment like crazy, so you may want to try something different in your team.

    Read the rest of Kanban Story as well.

    http://blog.brodzinski.com/2009/10/kanban-story.html

  • The Kanban Story: Kanban Boosters

    During my talk at AgileCE I mentioned three things as biggest Kanban boosters in our case:

    One of comments I heard about this part was: “Pawel, these things aren’t Kanban-related – they would work in any environment.”

    Well, I’ve never said they’re exclusive for Kanban. My point is: Kanban is pretty simple approach – it really tells you to do just a few simple things leaving most of other aspects open. This means you may (and should) use some help from other techniques/practices which set additional constraints or organize other areas of your process. And boosters I mentioned work exactly this way.

    Co-location allows you to keep your Kanban process as simple as possible. You don’t need to use any software to visualize current state of the project – old-school, hardware whiteboard is enough. It also helps to exchange information between team members which is always important but with minimal formal information exchange in place it plays even more crucial role.

    No-meeting culture brings us “do it now” attitude and saves a lot of time usually wasted on meetings. And we discuss different things more often than we would otherwise because launching a discussion is totally easy: you just start talking.

    Best engineering practices help us to keep the code quality under control. That’s a thing which is basically omitted by Kanban itself so you need other tools to deal with it.

    Now, you can perfectly take your Scrum (or whatever kind of) team and use the same techniques and it would most likely work. Oh, it would as long as your team isn’t too big (co-location and no-meeting culture don’t scale up very well) and you don’t have a list of engineering practices enforced by your approach anyway (like in XP).

    So no, these concepts aren’t exclusive to Kanban. They just work in specific environments. Yours either fit or not. It doesn’t really matter if your process name starts with S or K or X or P or whichever letter sponsors your day.

    After all when I think about Kanban I don’t isolate the method from the rest of our environment – that would be stupid. If Kanban works for us it is because the whole setup is good enough, not just its Kanban part. And these boosters are a part of the story.

    Read the whole Kanban Story.

  • The Kanban Story: Kanban Alone Is Not Enough

    Recently I had a lot of occasions to discuss Kanban with other people, the coolest one being last meeting of Engineering Academy “Diamond Polishing” (for you who speaks Polish there’s video recording available online). One of things which I stressed during these discussions is that Kanban is not enough to manage a software project.

    I already shared practices we employ and those we don’t. But it is important and worth stressing: you can’t just base on three simple rules of Kanban (limit WIP, visualize workflow, measure lead time) alone. Without best engineering practices your product would suck even though you rigorously followed the rules. That’s not the problem of Kanban only – the same is with Scrum. Kanban is here just to help you to organize work better. If you do crappy job it’s still going to be crappy, just organized a bit better.

    What more, while heavy-weight methods enforce some order because of specifying scope of work up front, using formalized acceptance tests etc, Kanban leaves it all open. In other words doing Kanban wrong way you can do much worse than doing Prince2 wrong way.

    We set up a list of practices to avoid the problem. When I think what results we would achieve if we had no continuous build, no unit tests, no knowledge exchange in terms of learning other developers’ code and no coding standards I’m scared. We’d probably land in never-ending loop of dirty-fixing old dirty-fixes to old bugs just to get anything done.

    All these practices sound very natural now but, to give one example, I confess that’s my first successful approach to unit testing since I manage software development teams.

    So no, don’t treat Kanban as a silver bullet which fixes everything in a second. It’s just the part of the job. The rest isn’t enforced, but you have to figure out right pieces by yourself. Continuous integration and automatic testing are rather mandatory if you care about quality and want to ship often, but there is no universal way which works for everyone.

    Read the whole Kanban Story.

    If you like the story or hate it or just want to win signed copy of Scott Berkun book Confessions of a Public Speaker leave some feedback here.

  • The Kanban Story: What We Do and What We Don’t Do

    Last two posts of the series (on Kanban Board and on setting up whole thing) were Kanban implementation-in-a-pill kind of story. As you may guess that’s not all since Kanban doesn’t prescribe many things which you can use and, most of the time, you do.

    To show the big picture there are two lists: practices we use and these we don’t.

    Things we do

    • Cross-functional team.
    As I mentioned at the very beginning (the_beginning) we have cross functional team which is a great thing. Virtually every action connected with our product in any way is performed within the team.

    • Co-location.
    We sit together in one small room. That’s so damn great. I wouldn’t change it for private office even if you paid me.

    • Roles.
    We have old-school roles within the team. Developers who, guess what, develop. We have our commando guy who mixes roles of QA, system administration and maintenance. He could work as our bodyguard too. My role is project and product management which in our case could be called Product Owner as well. We also have a guy responsible for business development. Nothing fancy here. Everyone just knows what they’re supposed to do.

    • Measuring lead time.
    When I initially wrote a draft for this post this was on the “things we don’t do” list. For some time it wasn’t needed much since with no production environment it wasn’t crucial to know whether specific feature will be ready in 2 weeks or rather 16 days. Now, as we need more precise estimates, measuring lead time emerged as useful tool so we started doing that.

    • Continuous improvement.
    Implementing Kanban was an improvement to the old methodology. Starting to measure lead times was another. We look for tools or frameworks which improves the way we develop our products in terms of speed, quality, code readability etc. Nothing fancy here – we just try to make our lives a bit easier whenever we can.

    • Unit testing.
    We write and maintain unit tests. We don’t have 100% coverage though. I trust our developers would write unit tests wisely. Most of the time they add unit test covering a bug scenario as they fix bugs too.

    • Continuous integration.
    Oh, is there someone who doesn’t do that?

    • Static code analysis.
    There are coding standards we follow. They’re checked during every build. After a couple of weeks coding standards became native and basically invisible so it’s hard even to say that it’s a real practice.

    Things we don’t do

    • Iterations.
    At least formal iterations. We don’t have sprints whatsoever. To bring some order we group some features and call them “iteration,” but that’s nothing like scrumish iterations. I’ll write a bit more about our pseudo-iterations soon since that isn’t something very standard done by-the-book.

    • Stand-ups.
    We have permanent sit-downs instead. Whenever something needs to be discussed we just start the discussion not waiting for morning stand-up whatsoever. No-meeting culture works surprisingly well so far.

    • Formal retrospectives.
    Same as in previous point. We just launch “I don’t like it, let’s change it” kind of chats whenever someone has some valuable input. You could call them informal retrospectives on call.

    • Burndown charts.
    We have no fixed scope within iteration to burn since we don’t have real iterations. I occasionally draw burndowns for a specific feature (a single sticky note). I do it mainly to check how my well works schedule simulation (estimates plus statistical analysis).

    • Code review.
    I’m a big fan of code review. I tried to implement it twice in my teams and failed twice. As long as developers won’t want to do code review I’m not going to force them. That just doesn’t work this way.

    • Pair programming.
    This one I don’t believe in. So do our developers.

    • Test driven development.
    We write unit tests. We do this after not before. This is another practice I’m not a big fan of and another which takes people who strongly believe in it to make it work.

    If I forgot to mention something on either list just let me know what I omitted and I shall provide update.

    I encourage you to read the whole Kanban Story.