Pawel Brodzinski on Leadership in Technology

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

Category: kanban

  • A Love Letter to Physical Whiteboards

    A Love Letter to Physical Whiteboards

    A few days back, Tonianne DeMaria wrote about how differently we process physical and digital visualizations.

    “Have you ever noticed how your brain just feels different staring at a physical Kanban papered with Post-its versus when scrolling through task cards in a digital tool? Turns out that it’s not your imagination at play here, it’s neuroscience.“

    Physical Whiteboards Are a Luxury

    I’m a long-time fan of physical visual boards. Since my earliest experiments with Kanban, I have always used whiteboards as much as I could.

    Which is not much, sadly.

    We live in an increasingly digitalized and distributed world.

    In the late 2000s, when Kanban was gaining popular awareness, there were no good tools simulating a visual board. The latest craze in project management circles was online tools doing Gannt charts. Now? Even JIRA has it.

    A decade ago, the world was just flirting with remote work. Post-COVID? It’s a norm. Scarcely any team can reliably assume that everyone will be in the same physical space.

    Suddenly, digital boards are everywhere, while a physical whiteboard looks like an extravaganza.

    And if you collaborate with customers from another geography, which has been more than a dozen straight years for me, then a whiteboard wasn’t an option at all.

    Or was it?

    Edge Case Whiteboards

    We tend to limit the application of visual boards to only the most obvious contexts. Project work. That’s it. Nothing interesting here. Move on!

    If, however, we consider it as a tool for visualization of all sorts of workflows, then we’ll quickly notice that the work flows on many levels and in different contexts, far beyond the usual applications.

    One such example is our sales board.

    visual board sales process

    Over the years, we’ve tried different tools to manage our sales prospects. We’ve tried anything from Trello to Salesforce (BTW, Trello was actually pretty good).

    And yet, after another frustrating event when something “fell off the table” yet again, I suggested scratching the digital tools. We repurposed one of the whiteboards as our sales activities HQ.

    I lived happily ever after.

    Physical Board in Digital World

    We don’t have the comfort of having everyone at the office all the time. Over the time the board has been in place, we have had people involved living in different cities.

    Still, we arrange to meet at least weekly in the same room.

    “But Pawel, it means that you can reliably update the board only once a week!”

    More frequently, in fact, but that’s correct. We can’t rely on it being up-to-date every single day.

    The thing is, it doesn’t matter.

    The activities we track don’t have an hourly rhythm that many software development teams experience. There aren’t that many active items on the board, either.

    A side note: The picture shows the actual state, although I obfuscated the names on post-its with fancy technology (more post-its).

    Flexibility of Physical Boards

    I like this example as it shows several advantages of using a whiteboard populated with sticky notes.

    Defining the Workflow

    While the structure of the board is nothing fancy, there are a couple of things that we get for free on a whiteboard, while they would be a pain in a digital tool.

    • The middle section (mild/warm/hot) is a subflow. And not even a real flow, as items freely travel between all three stages. The overarching flow is: parking, the middle section, and the virtual ‘done’ column. Most work just doesn’t flow linearly from one JIRA column to another.
    • The ‘done’ column has two possible outcomes (success/failure), but we cut the column vertically. Anyone want to take a shot at which outcome is more desirable (even without reading the labels)?
    • We added vividly visible definitions of key columns. All the important information is there, in front of anyone’s eyeballs.
    • My favorite: with sticky notes, color-coding is painfully obvious. And yes, color coding is still screwed up in just about any digital tool out there.

    By the way, there’s a reason why we split the middle section vertically while the done column horizontally. The mild/warm/hot part follows the behavior of “reading from the right,” where whatever is closer to being done also gets priority attention.

    The rightmost column presents a simple differentiator of the outcome. There’s no immediate stuff to do with the items in there.

    We handle items in different sections of the board differently, and the design reflects that.

    Data on Index Cards

    Over time, we began adding various data to individual index cards.

    sticky notes on sales visual board

    There are lead times (which we measure in months, by the way), sources of contact, etc. However, we could define all of this as custom fields on a digital board.

    The interesting part is that we add whatever random bits of information are crucial. But only crucial. No wall of text with the summary of the last call with a potential client.

    Why? Because there’s not enough space to slap everything there. Thus, the constraint serves as a filter.

    The Overview

    That’s by far the most essential part. With just a rudimentary understanding of the columns and post-its colors, you could easily assess what’s happening in the whole sales process.

    Having an opportunity to glance at the board when we come back to our desks with coffee serves as a trigger to follow up on whatever we forgot about. We can nudge another person to ask about their task simply because we notice it accidentally.

    It’s this helicopter view that’s almost nonexistent in digital tools. And when it is, it typically is another dedicated view that one has to check explicitly.

    This kind of serendipitous information consumption happens almost exclusively with physical visualizations.

    A Love Letter to Physical Boards

    The tradeoff we make between digital and physical boards is not only about convenience. It’s also about how we engage with information.

    It’s obvious when you think about it. Tonianne observes:

    “It’s worth noting that our spatial memory and systems thinking abilities evolved in the physical world.“

    We are genetically wired to use physical visualizations. It’s no wonder they serve us better in a broader range of contexts.

    Yes, there are situations when we want or need to focus on only a short list of a few tasks that are assigned to us. It’s just an infrequent occurrence when it’s the most effective choice for the team.

    So, treat it as my love letter to physical boards. Like any other person, I use digital tools a lot. I have to. No matter how hard I try, my whiteboard won’t be useful to a client in New York.

    Yet, there are many situations where the simplest old-school visualizations are feasible. And when they are, they are bound to beat the crap out of digital tools.

    The inspiration for this post came from our discussion with Tonianne DeMaria and Jim Benson (of Personal Kanban fame) on Substack, where they’ve recently started publishing. If any of the above considerations sounds interesting, I recommend subscribing to their newsletter.

  • Reinvent Your Daily Meetings

    Reinvent Your Daily Meetings

    Are you still doing daily meetings in the format suggested by Scrum? The three famous questions:

    1. What did you do yesterday?
    2. What are you going to do today?
    3. Are there any obstacles?

    Do yourself a favor and stop.

    It might have been a useful practice two decades ago. But it is not anymore. Not in that form.

    The Old Cure

    Here’s the thing. The ideas behind Scrum date as far back as the 80s, and its first applications happened in the 90s. Yes, it’s that old. But that itself doesn’t deserve criticism.

    However, when you look at the 2000s, when Scrum got its prominence, your average team’s tooling looked very different. The visual boards were yet to become popular. The state-of-the-art task management system was a filtered list.

    Jira dashboard from the 2000s

    No one in the IT industry seriously talked about limiting WIP then, so we were drowned in an excessive amount of ongoing tasks. That made navigating long, long lists of work items even more of a maze from nightmares.

    It’s no wonder that people saying what they were doing yesterday and what they plan to do today was a refresher.

    The New Situation

    Fast forward 10 years, and teams suddenly have very readable visual boards as a standard practice. Limiting work in progress may still be a challenge, but we’ve gotten progressively better.

    Also, new visualization standards allow for better comprehension of whatever is in flight. Even Jira caught up.

    Jira visual board from the 2010s

    As long as:

    • the board is up to date
    • there’s even remotely reasonable amount of work in progress

    we can clearly see who’s doing what.

    How? Just look at the board—it’s all there; thank you very much.

    And if, by any chance, the board would suggest that a person still works on 5 different things, then it’s not the form of the daily meetings that is the main problem.

    Who Cares?

    If you still think the old form of the daily updates makes any sense, look at people’s engagement during them. There’s precisely one person who’s interested in the entirety of the updates.

    The Scrum Master.

    For the rest of the team, it’s a ritual they follow out of habit. At best, they are interested in what a couple of people working on the most related tasks are doing, and then they’re off again.

    So it’s like a theater with many actors and just one attendee (the Scrum Master).

    It’s even worse. Almost all that information is readily available on the visual board. So that one person could have gotten it without getting everyone involved.

    Not Just a Status Update

    That’s the point where people tell me that I describe a daily meeting as a glorified status update, which it wasn’t meant to be.

    Fair enough. So what is it?

    A way for a remote team to get together and gel? Fine, get together and gel. I doubt that answering who does what is the best way to do it.

    So, maybe, it’s a place where we discuss obstacles and problems. Fantastic! That’s actually the only original question that is still useful. Then, ask only that bloody question and be done with it.

    Whatever the purpose of the meeting is, name it. I bet there’s a better format to address that very purpose.

    And yet, in 2025, people will still answer those three questions invented three decades ago.

    Daily Around the Board

    The intention behind the original standup format was a team sync-up. That goal is still worth pursuing. However, we have options that weren’t available a quarter of a century ago.

    My default way of running dailies relies on four elements:

    • We use blockers extensively to show any impediments
    • We keep the visual board up to date (it’s “the single source of truth”)
    • We run dailies around the board
    • We read the board from right to left (or from most to least done) and focus purely on blockers

    That’s it. It’s enough to focus on the important stuff. The rest is business as usual and not worth mentioning.

    You can easily cut the daily meeting time by half (or more), make it more engaging, and (a bonus) use it as an encouragement to keep the board up to date.

    There’s literally no coming back.

    The Purpose

    Sadly, we still stick to practices. They might have been visionary decades back, but somehow, we stopped asking about their purpose and blindly stuck to them.

    If we did, we would challenge many of the techniques we use.

    Ask yourself this question: If Agile were invented today, what practices would it devise? It would most definitely be different from what you’d find in a Scrum Guide.

    So do yourself a favor, stop answering the three standup questions, and, for a change, start using this daily hangout to make something useful.

    That’s what Agile intended us to do, after all.

  • Levels of Slack Time

    Levels of Slack Time

    I learned the meaning of slack time years back in the context of Kanban. Once we start managing workflow for effectiveness, we necessarily create these moments when we want to stop the work. Otherwise, we’d overload the bottleneck.

    When we design the slack time in the system, the natural question is, what’s next? How do we use it?

    The Use of Slack Time

    My first natural, although with the benefit of hindsight simple, answer was to optimize the teamwork.

    There’s always a colleague who would appreciate help. There’s always a stage of the process that no one loves (code review, anyone?). There’s always an improvement task that just never makes it the top priority (like paying technical debt back).

    Then, there’s a whole another context. Individual. Slack time creates a perfect opportunity to invest in oneself. Catch up with what’s new with technology (with the AI race, it seems like there’s something to catch up with almost every week). Learn something outside of the immediate context of the project. Sharpen one’s saw.

    But then, when we start considering the value of slack time in a more generic context, we realize that it goes way beyond the team level.

    Think of a fire station. Their whole system is designed around slack time. We don’t try to optimize the work for fire brigades for utilization. It would mean that we want firefighters fighting fires all the time.

    Thus, we’d either have an excess of fires or firefighters moonlighting as arsonists.

    Cross-Team Slack

    We can then abstract away the idea of slack time and consider how it applies in different contexts.

    The most basic context would be individual. Slack time helps me to get better.

    Going just a bit further, we have the team level. Slack time helps the team to become more effective. We achieve that either by coordinating around the ongoing tasks (short-term help) or working on improving the long-term performance (continuous improvements, paying technical debt back, etc.).

    So far, it’s all the basics. But what if we take another step into a broader context?

    Then we end up in cross-team/cross-project land. We start considering coordination problems. We look at interdependencies. We analyze an entirely different layer of work design.

    As much as we have a bottleneck within a development team (let’s say it’s testing), we will have one if we consider a cross-team initiative (let’s say it’s passing the security acceptance).

    Once we understand this high-level picture, we can use slack time to help the entire initiative become more effective. It’s likely that one team being able to deliver more features or deliver them more predictably will not move the needle of the whole product by a millimeter.

    The actual bottleneck may be in the design, or release, or even grand product-related decisions.

    That’s where cross-team slack time can be redirected. It would mean we’re asking the question: what’s the best way to help when I see the big picture?

    Organizational Improvements

    Can we go further up, though? Once we consider individual, team, and cross-team levels, is there more?

    But of course, there is.

    Once we strip the context from the product/project work, we look at the bare bones of any company—its organizational design. And there’s always plenty to do around these parts.

    At this level, we wouldn’t ask questions about improving my project/product. We’d look for ways to make the whole company improve.

    Think of any novel initiatives. Of course, “novel” is in the context of this company; I don’t expect us to routinely do world-changing stuff. Starting a self-help group. Running a new product experiment. Looking for fellow folks to challenge existing management paradigms. Opportunities are almost endless here.

    The more extravagant you become with the ideas, however, the less likely you’d be allowed to implement them. And here comes our culprit.

    Role of Autonomy

    We established different levels of slack time:

    • Individual
    • Team level
    • Cross-team
    • Organizational

    The further down that list you go, the bigger the potential impact of the changes. But most people wouldn’t even consider going beyond the team level. Why?

    Simplest answer? They don’t have enough autonomy.

    The degree to which we can impact our organization depends on our sphere of influence. And that is strongly correlated with how distributed autonomy is in any organization.

    It’s not binary, of course. It’s not that I can or cannot make a decision in a cross-team context. Sometimes, even when I can’t call the shots, I can influence the decision-maker.

    But if I don’t have autonomy on a team level, I shouldn’t expect to have influence on a cross-team level. Thus, we can use the autonomy distribution as our measuring stick.

    Limited Autonomy, Limited Impact

    Whenever I teach that stuff during workshops and university courses, I ask people a series of questions to assess how much their organizations distribute autonomy.

    The questions are separated into groups, roughly referring to the three levels mentioned above: team, cross-team, and organization. The outcome is the same every single time.

    We see a lot of autonomy on a team level. Teams can freely decide about many things. I think we have Agile to thank for that.

    But then, it breaks. Once we get to cross-team, the perceived autonomy goes from “significant” to “barely there.” And it won’t be a surprise that when we touch the organizational level, it’s non-existent.

    In such an environment, we shouldn’t expect to get that much out of slack time.

    So, the next step after introducing slack time to our systems is to get more autonomy in it as well.

  • Milk Kanban

    Milk Kanban

    When people say Kanban, they tend to think of a specific set of practices. Whiteboards & sticky notes (both almost universally virtual). Tasks moving through columns that represent workflow. Every now and then, WIP limits even.

    As often as we do it with other things, it reduces a broader principle to a set of oversimplified techniques, which, in turn, tend to underdeliver in many contexts.

    Kanban

    In its original meaning, Kanban represented a visual signal. The thing that communicated, well, something. It might have been a need, option, availability, capacity, request, etc.

    In our Kanban systems, the actual Kanban is a sticky note.

    It represents work, and given its closest environment (board, columns, other stickies, visual decorators), it communicates what needs, or needs not, to be done.

    If it’s yellow, it’s a regular feature. If there’s a blocker on it, it requests focus. If there’s a long queue of neighbors, it suggests flow inefficiency. If it’s a column named “ready for…” it communicates available work and/or handoff.

    A visual signal all the way.

    Visual Signals

    Let’s decouple ourselves from the most standard Kanban board design. Let’s forget columns, sticky notes, and all that jazz.

    Enters Kasia, our office manager at Lunar. One of the many things Kasia takes care of is making sure we don’t run out of kitchen supplies. The tricky part is that when you don’t drink milk yourself, it becomes a pain to check the cupboard with milk reserves every now and then to ensure we’re stocked.

    Then, one day, I found this.

    A simple index card taped to the last milk carton in a row stating, “Bring me to Kasia.” That’s it.

    In the context, it really says that:

    • we’re running out of (specific kind of) milk
    • we want to restock soon
    • there’s enough time to make an order (we don’t drink that much of cappuccinos and macchiatos)

    But it’s just a visual signal. Kanban at its very core.

    Simplicity is the King

    What Kasia designed is a perfect Kanban system. It relies on visual signals, which are put in the context. Even better, unlike most Kanban boards I see across teams, the system is self-explanatory. Everything one needs to know is written on the index card.

    That’s, by the way, another characteristic of a good Kanban system. It should be as simple as possible (but not simpler). Our workflow representations tend to get more and more complex over time by themselves; we don’t need to make them so from the outset.

    It’s a safe assumption that, almost always, there’s a simpler visualization that would work just as well. We, process designers, often fall into the trap of overengineering our tools.

    And it’s a healthy wake-up call when someone who knows close to nothing about our fancy stuff designs a system that we would unlikely think of. One that is a perfect implementation of the original spirit, even if it doesn’t follow any of the common techniques.

    Because it’s all about principles, not practices.

    That’s what we can learn from Milk Kanban.

  • Don’t Limit Work in Progress

    I’m a long-time fan of visual management. Visualizing work helps to gather low-hanging fruits: it makes the biggest obstacles instantly visible and thus helps to facilitate the improvements. By the way, these early improvements are typically fairly easy to apply and have big impact. That’s why we almost universally propose visualization as a practice to start with.

    At the same time a real game-changer in the long run is when we start limiting work in progress (WIP). That’s where we influence the change of behaviors. That’s where we introduce slack time. That’s where we see emergent behaviors. That’s where we enable continuous improvements.

    What’s frequently reported though, is that introducing WIP limits is hard for many teams. There’s resistance against the mechanism. It is perceived as a coercive practice by some. Many managers find it really hard to go beyond the paradigm of optimizing utilization. People naturally tend to do what they’ve always been doing: just pull more work.

    How do we address that challenge? For quite some time the best idea I’ve got was to try it as an experiment with a team. Ultimately there needs to be team buy-in to make WIP limits work. If there is resistance against a specific practice, e.g. WIP limits, there’s not much point in enforcing it. It won’t work. However, why not give it a try for some time? There doesn’t have to be any commitment to go on after the trial.

    The thing is that it usually feels better to have less work in progress. There’s not that much of multitasking and context switching. Cycle times go down so there’s more of sense of accomplishment. The pressure on the team often goes down as well.

    There’s also one thing that can show that the team is actually doing much better. It’s enough to measure start and end dates for work items. It will allow to figure out both cycle times (how much time it takes to finish a work item) and throughput (how many work items are finished in a given time window).

    If we look at Little’s Law, or rather its adoption in Kanban context, we’ll see that:

    Little's Law

    It means that if we want to get shorter cycle time, a.k.a. quicker delivery and shorter feedback loops, we need either to improve throughput (which is often difficult) or cut work in progress (which is much easier).

    We are then in a situation where we understand that limiting WIP is a good idea and yet realize that introducing such a practice is not easy. Is there another way?

    One strategy that worked for me very well over years was to change the discussion around WIP limits altogether. What do we expect when WIP limits are in place? Well, we want people to pull less work and instead to focus on finishing items rather than starting them.

    So how about focusing on these outcomes? It’s fairly simple. It’s enough to write a simple guidance. Whenever you finished work on an item first check whether there are any blockers. If there are attempt to solve them. If there aren’t any look at any unassigned items starting from the part of the board that’s closest to the done column (typically the rightmost part of the board). Then gradually go toward the beginning of value stream. Start a new item only when there’s literally nothing you can do with ongoing items.

    Kanban Board

    If we took a developer as an example the process might look like this. Once they finish coding a new work item they look at the board. There is one blocked item. It just so happens that the blocker is waiting for a response from a client. A brief chat in the team may reveal that there’s no point in pestering the client for feedback on the ticket for now. At the same time it may be a good time to remind the client about the blocker.

    Then the developer would go through the board starting at the point closest to the doneness. If the process in place was something like: development, code review, testing and acceptance by the client, the first place would be acceptance. Are there any work items where the client shared feedback, i.e. we need to implement some changes? If so that’s the next task to focus on. In fact, it doesn’t matter whether the developer was the author of the ticket but if there are any tickets that used to be his it may be input for prioritizing.

    If there’s nothing to act upon in acceptance, then we have testing. Are there any bugs from internal testing than need to be fixed? Are there any tickets that wait for testing that the developer can take care of? Of course we have a century-old discussion about developers not willing to do the actual testing. I would however point that fixing bugs for the fellow developers is equally valuable activity.

    If there’s nothing in testing that can be taken care of then we move to code review and take care of anything that’s waiting for code review or implement feedback from code review that’s been done already.

    Then we move to development and try to figure out whether the developer can help with any ongoing work item. Can we pair with other team members? Or maybe there are obstacles where another pair of eyes may be useful?

    Only after going through all the steps the developer moves to the backlog and pulls a new ticket.

    The interesting observation is that in vast majority of cases there will be something to take care of. Just try to imagine a situation where there’s literally nothing that’s blocked, requires fixing or improvements and nothing that’s in waiting queue. If we face such a situation we likely don’t need to limit work in progress any further.

    And that’s the whole trick. Instead of introducing an artificial mechanism that yields specific outcomes we can focus on these outcomes. If we can guide the team to adopt simple guidance for choosing tasks we effectively made them limit work in progress and likely with much less resistance.

    Now does it matter that we don’t have explicit WIP limits? No, not really. Does it matter that the actual limits may fluctuate a bit more than in a case when the process has hard limits? Not much. Do we see actual improvements? Huge.

    So here’s an idea. Don’t focus on practices. Focus on understanding and outcomes. It may yield similarly good or better results and with a fraction of resistance.

  • Portfolio Kanban Board

    One thing that I learned quickly when I started experimenting with Portfolio Kanban is that a classic, flow-driven board design isn’t particularly good in vast majority of cases.

    Board Designs

    Long story short, I ended up redesigning the board structure completely and it worked much better. In fact, it worked so well that I started proposing such a design as a starting point whenever working with portfolio Kanban.

    Portfolio Kanban Board

    Interestingly enough, as Kanban adoption of portfolio level progressed I started seeing completely different approaches to visualization. Not that they were worse. They just focused on different aspects of work.

    One that popped up early was two-tier board that addresses different granularity of tasks at the same board. We can track the roots of this design to David Anderson’s time at Corbis. Since then it was picked up to manage portfolios.

    Portfolio Kanban Board

    Another example came from Zsolt Fabok, who was inspired by Chris Matts. What he proposed was a board that stresses expected delivery dates and how an organization is doing against these dates. Again the board design is completely different from the ones we’ve seen so far.

    Portfolio Kanban Board

    Another interesting example that I like is a portfolio board that visualized non-homogenous flow of work. This still is one of the most unusual board designs I’ve seen and yet it makes a perfect sense given the context.

    Portfolio Kanban Board

    By that time it was perfectly clear that there is no such thing as a standard design of Portfolio Kanban board. Each of these designs was fairly optimal if we considered the context. At the same time each of the boards was designed to stress a different aspect of work.

    The design I ended up with in my Portfolio Kanban story revolved around available capabilities and commitments. The two-tiered board design focused on flow of coarse-grained items and breaking work down to fine grained items. The deadline driven board based on an assumption that the most critical aspect of work are delivery dates and monitoring delays. Finally, non-homogenous flow board design addressed the issue of different flows of work in each of the projects.

    Which design is most useful then? It depends. To address that question we first need to answer which aspect of our work is the most important to track on a regular basis. To get that answer we need to discuss risks.

    Risk Management

    Obviously, risk management is a multi-dimensional issue. Some dimensions would be more interesting than others. The word “interesting” typically translates to the fact that we are more vulnerable to a specific class of risks or that we are doing especially badly against managing that class of risks.

    A typical example in the context of portfolio management would be overburdening. We commit to more projects or products than we can chew. We end up having our teams juggling all the concurrent endeavors. As a result we see a lot multitasking, context switching, and huge inefficiencies.

    In such a case the most interesting dimension of risks would be one related to managing available capabilities and ongoing commitments. And that would exactly be information that we’d like to focus on most when designing Portfolio Kanban board.

    That’s by the way almost exactly the process I went through when I proposed capability-focused board design. Of course, back then the thought process wasn’t that structured and it was more trial and error.

    There are some additional aspects of the story, like the huge variability of size of the projects that we typically see. This would affect the details of the board design as well. In this case relative size is visualized as well.

    The most important bit is that we start with the most important risk dimension. This should define the whole structure of Portfolio Kanban board.

    Coming back to different visualizations I mentioned we can easily figure out what was the key class of risks in each design.

    In two-tiered board the biggest concern was smooth flow of coarse-grained items (feature sets). We can also figure out that variability in size of feature sets wasn’t that much of a problem. Given that we’re talking about product development organization and that they are in full control of how they define feature sets, it does make a lot of sense.

    Delivery date driven board stressed how important risks related deadlines and timeliness of delivery were. We may also notice that there isn’t much stress on flow of work and not that much focus on addressing potential overburdening either.

    The design with non-homogenous flow, as its name suggests, pinpoints that most important risk dimension was managing flow. On the other hand risks related to capability management and overburdening don’t seem so important.

    Optimal Design

    The structure of Portfolio Kanban board can show only that much. We can’t visualize all the risk dimensions using the board structure alone. David Anderson in his Enterprise Service Planning talk points that it is common that organizations track 4-8 different dimensions of risks. The board design can address one or two.

    Make it the two that matter most.

    Where would others go? Fortunately we still have items on our board, whatever we decide them to be. We can track information relevant for other risk dimensions using information on index cards. The design of the items on the board is no less important than the design of the board itself.

    Designing Portfolio Kanban board is not an obvious task. We don’t even have a standard approach – something similar to a flow-based design we commonly use on a team level. Understanding how we manage risks is the best guidance that can lead to fairly optimal board design quickly.

    Of course one alternative is to go through a trial and error process. Eventually you’d land with similar outcomes. A quicker way though is to start with understanding risks.

  • Portfolio Kanban and Doing the Right Thing

    There’s an ongoing discussion that I occasionally refresh with Markus Andrezak on usefulness of applying Kanban to manage portfolio and generally to the process of figuring out which products should be built.

    What is Portfolio

    One obvious thing that we can start with is focusing on a specific context. After all portfolio is a pretty loaded word and it is used in all sorts of situations. While my goal isn’t to boil down portfolio discussion to only few available options I see at least three distinctively different cases.

    There are organizations that ore focused on project work. A typical gig they run would be a distinct initiative that is different form all the other initiatives they run. What’s even more important the revenue from that work would be connected to delivering work. This would be a project portfolio case. A classic example would be an offshore web software shop.

    Then we have organizations that, similarly to the previous example, focus on building multiple concurrent and independent initiatives yet they would operate them as products by themselves. In other words they earn money by directly selling their software, or services provided by that software, to the end users. There’s no simple definition when the work is done. This would be a product portfolio case. A classic example would be a game development studio.

    Then there is an alternative version of product portfolio where the whole company is focused on building a single product. In such a case the overarching initiative that everyone contributes to is obvious as there is only a single one. The discussion would happen between either specific goals to achieve or specific big scale functionalities to build. This would frequently be labeled a product portfolio too although for the sake of this discussion I’d go with a feature portfolio label, even if it isn’t precise especially for big organizations. A classic example would be a startup building what they believe is the next world-changing product.

    Of course we can think of a mix of any of these scenarios and rarely only one of them will be pursued by an organization exclusively. What’s more we could go further with a differentiation within these scenarios. We’d see a completely different dynamics of project portfolio in a company that works under time and material terms than from one that build fixed price projects. A very different feature portfolio will be in a startup at an early phase which is still figuring out product-market fit that in an established company focusing on leveraging their user base or staying ahead of competition.

    Where is the Problem

    The discussion about applicability of Portfolio Kanban boils down to defining what is the most painful problem on a portfolio level in a given context. From that perspective there is a clear distinction between project portfolios and the other two scenarios. The difference is in the way revenues are generated.

    In project work the more projects we finish the more revenues we can expect. With product or feature portfolio building software is only an intermediate step in order to generate revenues. In other words we know much more up front about return on investment in project portfolio scenario than we do in other two.

    That doesn’t completely change the bottom line. In each case the choice on endeavors an organization works on is crucial for its long-term health. In each case overcommitment and too much work in progress on portfolio level can decimate the value of any ongoing work, no matter how carefully chosen. There are commonly mentioned reasons for that: long lead times mean long feedback loops and a lot of work in progress results in inefficient work.

    There’s one more dimension that from my experience is at least equally, if not more, important. The constraints provided by work in progress limits change the dynamics of the discussion about starting new stuff, be it projects, products or major features.

    Typically the discussion about economic feasibility of starting a new product or a project happens in isolation. If the ultimate problem that we are trying to solve is choosing the right initiatives to work on it should never happen in isolation. After all most of ideas we come up with make sense… in some context. An interesting question would be whether we are in such a context.

    We may have a bunch of projects that we expect to be profitable. But which of them provide us most monetary and non-monetary value? How starting another one affects the ones that are already ongoing? Given a business hypothesis which we want to validate, which out of all possible experiments would generate most valuable information? Would starting another concurrent experiment obfuscate the outcomes of ongoing ones?

    Of course we can say that each project will provide some value and each experiment will provide some learning opportunities. We don’t have infinite capabilities thus we need to choose.

    Role of Portfolio Kanban

    The way I look at Portfolio Kanban is that is addresses a very common issue of overburden at portfolio level and as a result it drives the discussion about what are the right endeavors to pursue. The latter starts happening when, thanks to WIP limits, we start saying no to new initiatives. What WIP limits create is they underscore available capabilities as a scarce resource. The next step typically is more careful consideration how these capabilities are put in the best use, which ultimately means a discussion about what is the right thing to build.

    Obviously this dynamics is not true in all environments. Startups, especially at the early stages, will likely focus on figuring out what is the right thing to build without any external incentive. Organizations built around a single product, at least to a certain size, will naturally maintain discipline in strategy planning that will provide an answer what are the crucial product goals for them.

    Beyond that it all gets fuzzy. If an organization gets big enough it has capacity to build multiple initiatives concurrently. Each product that grew far enough has a number of potential development paths it can follow and each of them can be promising on its own. If we talk about multiple product organization a temptation to follow a bunch of new goals at the same time is even stronger. And with projects it’s like an everyday issue.

    Of course I don’t say that it’s not possible to start the other way around: nailing down the ultimate purpose, which may mean answering the Spice Girls question, and following up with defining what are the right features, products or projects that serve the purpose. This would likely mean that the number of concurrent initiatives will be limited as majority of activities would be optimized toward pursuing the purpose.

    The problem is few organizations are ready to make this step just like that. And even when they are, there are still a lot of risks along the way. First, depending on how the ultimate goal is defined it doesn’t have to limit the options for what constitutes an attractive endeavor and we’re back to the square one. Second, even if the purpose provides enough focus there’s typically still plenty of options how to pursue the goal and thus overburdening portfolio is still a viable option. Third, and most importantly, in bigger organizations defining a single purpose may be impossible because office politics kicks in or there isn’t enough strategic leadership present.

    In either of these cases as well as in the most common situation where there isn’t enough awareness to even start the discussion about the purpose Portfolio Kanban may serve as a facilitation tool. On the top of efficiency gains, similar to those seen in other applications of Kanban, it would catalyze the discussion about what is the right thing.

    This is, in fact, the most important outcome of introducing Portfolio Kanban that I’ve seen.

    What Portfolio Kanban Is Not

    An argument I’ve heard a couple of times is that Portfolio Kanban doesn’t help to define what is the right thing to build or what is the ultimate purpose. I completely agree with this one. That answer simply isn’t there. Portfolio Kanban, pretty much alike any Kanban application, is a meta method. One shouldn’t expect to get context-specific answers.

    If an organization is ready to look for these answers that’s great. Depending on specific context Lean Startup, Lean UX or other modern product management approaches may be relevant. That’s where awesome guys like Will Evans or Markus Andrezak kicks in with their expertise. That’s where Stephen Bungay’s work will prove invaluable, which Jimdo guys will happily confirm. That’s where Don Reinertsen would provide outstanding guidance for decision making.

    In such cases, usefulness of Portfolio Kanban will indeed be limited. It will be mostly process improvement and efficiency stuff.

    A common case wouldn’t be even remotely as rosy though. That’s why value provided by Portfolio Kanban typically go beyond the process stuff. It would still stop at introducing pressure to start important and difficult discussions. It wouldn’t provide guidance for that conversation. A good thing is that there would be more pressure the more screwed up the situation is. We can expect this catalyzing mechanism to exist continuously till we either solve the problem or give up on limiting work in progress on portfolio level.

    If someone claims that Portfolio Kanban is supposed to provide more than that in terms of defining what is the right thing, well, we may be talking about different things.

  • Lean Kanban Central Europe Leadership Track

    There’s a question I get asked pretty frequently: which conference I would recommend to attend. Of course the answer is always contextual but surprisingly often after some further inquiry I recommend Lean Kanban Central Europe.

    On one hand it’s the content. Even today I remember all the keynotes from the first LKCE three years ago. That’s how much that stuck. Since then the program was only getting better. Then, there is exposure to new ideas. Lean Kanban series of conferences are surprisingly consistent when it comes to bringing to the mix new concepts, models and methods. One can bet that that thing which sounds so fresh on one of big Agile events was covered in extent a few years ago at Lean Kanban tour.

    Then of course there is networking. With three hundred people networking is of very different quality than at the events that attract a thousand people or more. Everyone is more accessible and it’s not an ultimate challenge to track down someone who you really want to chat with.

    The post wasn’t meant as a just an infomercial of LKCE. The conference, as every good event, evolves. One change that we introduced this year are consistent tracks and track chairs. This means that there’s always someone who made final decisions for the part of the program. This also means that there’s even more space for radical ideas as we as the program board aren’t driven by the consensus that much.

    The track I’m honored to lead is the leadership track. One thing I didn’t want to do with it was just to throw a bunch of great speakers and just let them do their magic. What we’ll have instead is a theme and different ideas on leadership evolving around the same theme. Of course we still have a bunch of awesome speakers in the first place.

    This approach means that everyone who will choose to stay throughout the whole track will get a consistent experience, while being exposed to different ideas. In fact, when working on the track I was thinking of it as of a mini-conference on its own.

    The underlying theme for the track is broadening understanding of what leadership is and what approaches and tools we may use to let it emerge in our organizations. Esther Derby will kick off the track explaining that leadership at all levels isn’t just a nice theoretical concept or wishful thinking. At the same time the challenge is that there are no recipes that allow us to easily build such an environment. If there was such a thing as a track keynote it would be this one and I can hardly think of a better candidate than Esther to deliver it.

    With no recipes we aren’t left alone in the wild though. We do have models and methods that, if understood correctly and used mindfully, can help us to shape the organization to steer emergence of leadership. When I think about people who easily mix different models and methods applying them contextually to provide most value Liz Keogh is on the top of my list. That’s why I asked her to cover that part. At least a bit of exposure to systems thinking and complex adaptive systems seems inevitable.

    By that point the balance of the track will have swung toward more systemic approach to leadership. In that context however we can’t forget that at the end of the day it all boils down to people dynamics. That’s where Marc Burgauer will kick in with his message about how trust, connections, blame and fear of shame play pivotal role in building leadership across organization. Marc does an awesome job bringing people perspective into discussion.

    The only missing bit in that mix is a practical story that shows how one may use all these building blocks to create a culture where leadership emerges and thrives. I tasked myself with that. On one hand at that point my job will be super easy as Esther, Liz and Marc will have covered the important parts and I’ll just build the connection between my story and earlier sessions. On the other, matching such a lineup of speakers is a challenge by itself. I guess my inner speaker now hates my inner track chair.

    Of course leadership track will be competing for attendees attention with other awesome tracks. It was never our goal for LKCE to make choice between sessions even remotely close to easy. I do hope though that there will be some people who will choose to stay with us through all the leadership sessions. Especially that it is the shortest track of the event. As you can see though there was a lot thought invested to provide additional value for those who would be at all sessions.

    The track is more than a sum of its sessions, it’s a product of interactions between its parts.

    Have I just brought systems thinking again to the discussion? Oh well…

    I hope this is one more argument to join LKCE this year. I’d love to see you there and I’d love to get feedback about the final outcome.

  • Kanban: The Culture Challenge

    My focus for past months drifted a bit away from the core of Kanban. I either focused on more enterprisey applications of Kanban in the context of portfolio management or on what’s blood of every company, which is organizational culture. Every year though I use Kanban Leadership Retreat as a perfect occasion to reset my focus a bit. It wasn’t different this year.

    Those of you familiar with the method please forgive some of the basics in the post.

    The classic definition of Kanban Method is as follows.

    Principles

    • Start with what you do now
    • Agree to pursue incremental, evolutionary change
    • Initially, respect current roles, responsibilities and job titles
    • Encourage acts of leadership at all levels

    Practices

    • Visualize
    • Limit Work in Progress
    • Manage flow
    • Make policies explicit
    • Implement feedback loops
    • Improve collaboratively, evolve experimentally

    A side note: a super-common observation is that teams would understand and know the practices but would be almost completely ignorant of the principles. This is a pattern that leads to very shallow implementations that don’t yield sustainable improvements and typically stop at just better work management.

    Another perspective we may use to define Kanban is through its values. The approach was proposed by Mike Burrows. What Mike achieved was translating the original principles and practices to more generic values.

    The end result is a following list.

    Kanban Values

    • Understanding
    • Agreement
    • Respect
    • Leadership
    • Flow
    • Customer Focus
    • Transparency
    • Balance
    • Collaboration

    Since the values originated in the principles and practices there’s also an interesting exercise you can do to map one to the other.

    The important part of this perspective of looking at Kanban is that it describes what values should be embraced by an organization so that Kanban implementation will have deep and lasting impact. In other words if an organization doesn’t embrace for example transparency or respect I would expect resistance during the implementation, rather ephemeral improvements and very limited sustainability.

    Now, let me share yet another perspective of describing Kanban, which is Kanban agendas. Just to tease you there are three agendas: sustainability, service orientation and survivability. One nice thing is that the agendas nicely fit the values. Each of the agendas covers a few values.

    Sustainability

    • Transparency
    • Balance
    • Collaboration

    Service orientation

    • Customer focus
    • Flow
    • Leadership

    Survivability

    • Understanding
    • Agreement
    • Respect

    Now we have a frame for further discussion (and some of Kanban 101 in a pill too).

    Why I would bring this up, you may ask. One session that I attended at Kanban Leadership Retreat was about reintroducing an idea of maturity of Kanban implementations in the context of values. The workshop and the exercise we run there is a topic for another story. The important bit in this context is that Mike, who unsurprisingly run the session, decided to put Understanding, Agreement and Respect aside for the purpose of the exercise.

    We may look at it from at least a couple angles. We may say that Understanding, Agreement and Respect, since they all were derived from principles and not practices are much more difficult to assess than the rest.

    We may point that they are some sort of prerequisites for starting with the whole rest and thus we base on an assumption that these values are already in place.

    Both of these points of view are, in fact, valid. I see a big problem here though.

    First, this is a bit like saying that Understanding, Agreement and Respect are second-class citizens in this picture. The whole focus goes to the other six values. Now, let me remind one thing. The second-class values are derived from principles not practices. In other words it means petrifying the situation we have, where we discuss practices all the time and principles are relatively ignored.

    Second, Understanding, Agreement and Respect all belong to survivability agenda, which puts that very agenda at risk. What does it mean?

    If we get service orientation right this translates to doing things right and doing the right thing (at least as far as Kanban covers that part). If we get sustainability right it means that the evolutionary change is feasible. The problem is that without survivability it simply won’t last. We’ll see a pattern that is pretty common across Agile and Lean adoptions. Promising results and early success that is followed by systematic reversal of the change.

    Third, there’s one of my recent pet peeves, which is organizational culture. Obviously the culture relates to all the values by definition. However, Understanding, Agreement and Respect summarize the most common missing bits of culture. Also, these bits are least related to specific solutions we have in our toolboxes which means it is much more difficult to influence the change in these areas than it is in the rest.

    Finally, the assumption that we have Understanding, Agreement and Respect in place before we start with Kanban is simply not true in my experience. We wish it was, but that’s not what I see. Sorry. It is a common case with pretty much any method that reaches a specific level of maturity by the way.

    It all boils down to the challenge I teased in the title of the post. The challenge is to think about methods that aim to change or improve how we work from a perspective of organizational culture. A starting point would be answering a few questions.

    • Do we understand the existing culture of an organization?
    • Is the existing organizational culture well-suited to support the change we want to introduce?
    • Which elements (behaviors, values, beliefs) of the culture are missing?
    • How can we influence the culture so that it evolves toward the expected state?

    Before we can answer these questions in a meaningful way introducing a major change is simply gambling. And the odds are against us. Bad news is that in majority of cases the answer for the very first question would be negative and the further we get the sadder the answers would be.

    A good thing is that, at least as long as it comes to Kanban, we advance our thinking toward better understanding of what it takes to make the change survive. It should help to shift the perception of Kanban from a simple, light-weight tool that can help you with organizing work in one’s team toward deep and sophisticated model that requires understanding of quite a lot of related concepts.

    A word of warning: don’t expect the end results of the latter if you treat Kanban as a former.

  • Portfolio Management: Stop Starting, Start Finishing

    Whenever I end up discussing project portfolios with people representing or knowing specific organizations out of curiosity I ask a couple of questions. How many projects? How many people running those projects?

    Note, most of the time I don’t ask these questions in the context of completely random organizations. The most common case would be asking people who are a part of Agile and Lean community. People who understand the concept of limiting work in progress and its implications.

    Disturbing news is that, even among the most mindful people, the answers I would get are pretty much shocking.

    Kanban Leadership Retreat is an occasion to meet people advancing thinking for a community that painted limiting work in progress prominently on their banners. One would expect that these people, if not anyone else, would be ahead of the rest of the crowd in addressing the issue of too many concurrent projects.

    Well, maybe we are. At the same time the ratio of a number of projects run by an organization to a number of people who work on those projects reported at the last Kanban Leadership Retreat in Cascais is terrifying.

    1.0, 2.1, 4.5 and 6.0. Let me rephrase what this number is. This is how many projects per person an organization runs on average. In fact, it does mean that some people are in a situation that is much worse than that.

    I didn’t gather that data in any consistent manner. I just asked my question any time the context would pop up in a discussion. It isn’t by any means proper research. It shows, however, a very interesting trend. The best result is a project per person, and we are talking here about an organization with a hundred engineers in this case. Few of those projects, if any, require attention of a single person only.

    From that point though we go downhill. I can’t imagine any situation where a single person runs concurrently a few projects and they are at least a tiny bit effective. This means heavy multitasking for those initiatives that get any progress and lots of others where progress is nil. Effectively, they are parked even if management believes that they are active.

    Let me repeat. It wasn’t reported by a random community. It is the community that calls their user group meetings Limited WIP Society. Not Visualization Society or Flow Society. Limited WIP Society. We do care. We do pay attention. Yet still, we do suck at that. Big time.

    Larry Maccherone in his talk at Lean Kanban North America reported that teams that work on a single project are significantly better in terms of defect density. We can use that as a proxy for quality of work. It’s not anecdotal evidence. Larry bases his research on raw data from almost ten thousand agile teams.

    By the way, Larry also reported that team size of 5-9 people is by far the most popular one. In other words, ideally, we should be looking as projects to people ratio of 0.2 and below. Of course it is contextual and shouldn’t be treated as the true north. In organizations that typically run tiny projects that require attention of 2-3 people such ratio may be unachievable. At the same time we do have companies that typically run huge initiatives that involve dozens of people.

    In either case anything above 1 is obviously crazy. In fact 1 is crazy already.

    We can’t make this possibly work.

    The easiest way out is obviously reviewing the portfolio and putting on hold or abandoning a big chunk of ongoing initiatives. This would mean that the active remainder would get more, hopefully enough, attention so that these projects can be completed in reasonable time.

    Sad truth is that I know such an expectation is unrealistic.

    If we understand that potential projects are options that we can execute and once we decide to start them it means commitment we should also understand the consequences. Commitment means that there’s a price to be paid for abandoning an initiative. What’s more that cost isn’t easy to assess. How much would reputation of a company suffer for letting a client down? How much bad word of mouth would be triggered?

    Another way is to go with the theme of Lean Kanban Central Europe conferences: stop starting, start finishing.

    In other words make it hard to start new stuff. Discuss the cost and risks attached to adding one more thing to your plate. I don’t expect an explicit WIP limit. On portfolio level it is rarely a feasible option anyway. The strategy that you can use is WIP limits by conversation.

    There’s not much guidance needed to shift these conversations to a broader context that is frequently ignored. It’s not only how much a new project would cost and how much we are going to get in revenues. It is also about available capabilities: can we staff a project appropriately for its whole lifecycle? What is the cost of delaying the project? What risks are we going to introduce by starting a new initiative both to that initiative and to all ongoing ones? And what is ultimately value of completing the project?

    The value question goes way beyond simple financial outcome. In fact, it is a very deep discussion as one needs to understand the goals of an organization. Otherwise discussion about value is pretty much irrelevant. Also discussion about value doesn’t happen in isolation. Remember how hard it was to let down current clients breaking our commitments to them? Well, that’s clearly negative value for the company. If that’s the cost you pay you better have a damn good reason to do so.

    I do admit that WIP limits by conversation is a concept that seems vague and fuzzy. However, given that people understand what is effect of too much of work in progress I find it a surprisingly powerful tool. It simply shift the focus of a discussion and thus influences how decision making process looks like. It is like a facilitation tool that helps us to use knowledge that we already have.

    Then we stop starting and start finishing.

    If we do that in a continuous manner we evolve toward more effective way of working. Not only does it mean fewer emergencies or better reliability but also choosing the right initiatives to run. It would be a nice situation to be in, wouldn’t it?