Category Archives: kanban

Kanban boards: physical or virtual?

Physical vs. virtual kanban board: which is best? What are the options? How do you choose?

bsktcase crosspost project

I’m cross-posting selected blogs from Northwest Cadence. This is the first installment, and it turns out I found all kinds of opportunities to update the content as well.
Here’s the original post from 15 October 2013.

Which type of Kanban board do you prefer? A couple years ago now, I found myself in the middle of a huge enterprise agile engagement with a global corporation, and we focused a great deal on Kanban boards to improve their Scrum capability. I started out with a clear preference for physical boards, but as some teams pushed back, or just plain ignored me and self-organized around virtual ones, I developed a broader perspective.

Spoiler alert: my preference for physical over virtual still hasn’t changed, but I continue to fine-tune my appreciation of the tradeoffs. I don’t tell my clients’ teams what to do, but as a result of this analysis and in the years since, I’ve taken greater initiative and have asked many of them nicely to consider the advantages of a physical board.

Researching this post in 2013, I looked around the consultosphere for a complete overview and didn’t find one, so I have taken the liberty of presenting my version here. I have limited experience with online boards (see: preference for physical ones), but I looked up a few and they’re included here superficially. I have a fair amount of experience with TFS/VSO, so it’s included here with a bit greater detail.

Have I overlooked your favorite virtual board? By all means, clue me in in the comments!


Pros of physical boards

  • Engaging
  • Passive radiator; unavoidable; information is always available without the team having to intentionally open it
  • Visible (and unavoidable) beyond the immediate team
  • Tells a story from a distance/in aggregate
  • Go viral, generating enthusiasm and buy-in throughout the organization
  • Fun; team can own the board and play with it (fun avatars and other art, beer column, etc.)
  • Engaging
  • Flexible, easy to make incremental process change
  • Can display definitions of done per column and elsewhere
  • Can display column and aggregate (system-level) WIP
  • Can support blocked flags in any column/state
  • Can support sub-states
  • Can support split/parallel states
  • Can easily indicate multiple team members working on one backlog item
  • Can easily limit a team member’s WIP (e.g., to 1) by limiting number of avatars per person
  • Can easily hold the daily standup at the board (if collocated)
  • Team members appreciate the physicality of moving a sticky across the board
  • Moving stickies focuses the team on the right things in the daily standup
  • Engaging

Pros of virtual boards

  • Provide equal access to distributed team members
  • Can enforce WIP and workflow rules
  • Can calculate cycle time and other metrics
  • Can populate CFD and other reports
  • Can track history of items
  • On a large monitor (esp. touchscreen), can provide many of the benefits of a physical board

Pros of TFS/VSO boards (to date)

  • Linked to check-ins, traceable
  • Linked to test cases, builds, documentation, other artifacts
  • Can drill into backlog items for more detail
  • Easy to decompose backlog items into tasks and visualize both on separate boards
  • Easy to aggregate backlog items to a portfolio (features, epics, etc.) and visualize each level on its own board
  • Easy to aggregate items from multiple teams onto a project board
  • Team-level customizable columns allow flexibility while mapping to consistent enterprise workflow states
  • Touch support out-of-box
  • Can display definitions of done per column! Thanks Gregg Boer!
  • Can support basic doing/done sub-states
  • Can support horizontal swimlanes (e.g., expedite)
  • Can color-code tags (e.g., blocked)
  • Can color-code columns (including cool dynamic query-based conditions)

Visual Studio Online has been rolling out new capabilities on its boards much faster than I can keep up, so this post is sure to be out of date by the time you read it.

The issues

A slightly deeper dive into some of the bulleted claims above.

Flexibility and placement

I’ve heard it said that physical boards are less flexible and harder to tear down to change. That can be a challenge, but I think there are tricks we can use to make physical boards more adaptable.

Magic Whiteboard won BBC Two’s Dragon’s Den, and no wonder: it’s brilliant. It’s 20m of whiteboard surface, on a roll, for £33. It static-sticks to hard flat surfaces. You can make a Kanban board of any size on any wall (or window, and it comes in clear), flow stickies across, and modify columns easily, with no hardware and no damage. In one of my clients’ offices, we were able to route their Kanban board around a wall-mounted clock on their only available wall, without losing the clock!

In the Northwest Cadence Kirkland office, we used layers of magnetic paint, chalkboard paint, and washable chalk to make an amazing Kanban wall. The size and location of the wall were fixed, of course, but the layout of the board could be changed at any time to accommodate any process. Stickies and avatars were laminated, erasable/rewritable, and mounted on magnets.

In open-plan offices I’ve used rolling whiteboards, which have the added advantages that they’re two-sided, and you can roll them into conference rooms for meetings. Clarus Mobile Xpress portable glass boards are gorgeous and functional. Quartet Motion, Wilson, MOI, and others have simple rolling whiteboard divider panels that work and look great.


Tagging independent of state

Items can become blocked in any state. You want to remember the item’s state and count it against your WIP limit for the state it’s in.

On some electronic boards, you can customize the color of individual stickies, which works just fine for this. In TFS, you can now apply any free-form tag and color-code multiple tags—”blocked” and beyond!

LeanKit, AgileZen, Silver Catalyst, and others also support custom tags and/or icons so you can make other facts visible about your items.

Sub-states, split/parallel states, swimlanes

LeanKit handles complex board designs, second only to dry-erase as far as I’m concerned. (Steven Borg‘s fancy circular Kanban boards are still going to require a wall and some markers.)

TFS/VSO now supports doing/done sub-states (configurable per column) and horizontal swimlanes (I don’t normally use these).

TFS/VSO doesn’t currently support the concept of parallel states (e.g., “coding” and “authoring test cases”) which both need to be completed before moving to the next state (e.g., “ready for QA”). If you think this practice smells a little bit siloed and waterfall-y anyway, I am inclined to agree.


Most electronic boards use image avatars. Their uncreative sales demos show these as team members’ security badge photos, or whatever. Obviously you’d want to use something more fun than that. :) Whether electronic or laminated, I enjoy a custom South Park avatar or custom Lego minifig avatar, but I have to say I was won over by one of my clients’ teams who had every team member bring in his or her choice of refrigerator magnet to use. We had fun and learned a bit about everyone in the process!

Touch screen

These might almost be good enough. I still miss the total ownership, fun avatars, and the impromptu doodling, but I think team members love moving stickies on a touch screen even more than they love moving physical stickies, which focuses them on keeping work moving, and that’s a big win.

There’s mild annoyance around putting a touch screen/browser into kiosk mode. Somebody’s got to be logged into the thing, and since the whole point is that it’s editable on-screen, now the logged-in user shows up for all the edit history. Even if you create a special kiosk account, you lose visibility into who actually made the change. Of course, edits on a physical board don’t track history in the first place.

I saw a blog suggest that a single shared touch screen is a good solution if you have “limited wall space” for multiple teams. Don’t do this. If teams have to fight for airtime on the big screen, you’ve thrown away the key benefit of the wall-mounted board: being a passive, unavoidable information radiator that engages teams (and bystanders) without anyone having to dig to find it.

There’s a big temptation to justify the expense of the screen by repurposing it for other organizational data. That’s manageable if the display automatically rotates, like a slide show, so the team’s board still shows up regularly.

Distributed teams

This is a tough one for me. As you’ll read below, my preference for physical boards is all about what they do for teams, that virtual boards just don’t. And yet, with a distributed team you end up having great benefits for the ones who are collocated with the board, while the distributed minority of the team are pretty much screwed: many of the “pros” aren’t available remotely. Pointing a webcam at the board, taking a smartphone photo of the board, or synchronizing to a shared virtual tool, are clunky and poor substitutes for having the board in-person.

Here’s why I don’t consider this a deal breaker, quite:

  • The disadvantages of physical Kanban boards for distributed teams are closely tied to the disadvantages of having distributed teams in the first place. Agile methodologies teach us that teams should be collocated, and one of the original Twelve Principles for Agile Software states that “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” Kanban boards are meant to supplement in-person interaction, not replace it. Don’t blame the board.
  • Even when one team member is screwed, the benefits for the collocated portion of the team can sometimes be so great that they make up for the extra effort needed to keep the distributed folks in the loop. If your team are unwilling to do this, that’s another problem to not blame the board for.

Yeah, it’s a stretch. When teams don’t have any control over whether they’re collocated or distributed, no, it isn’t fair to blame them for the difficulties distribution can cause them. When I find this at a client, I leave the distributed teams alone and attack the issue two ways: I turn up the charm and try to persuade any collocated teams to use physical boards, and then with senior leadership I point to those teams’ success (along with the agile principles and a wealth of other supporting information) to get the organization to value and build collocated teams.

Bad reasons

I hear some #facepalm-inducing arguments against boards in general, especially physical ones.

Sync: the best and worst of both worlds

My client’s teams are typical engineers: they’re allergic to the faintest perception of redundant effort, like having to sync information from a physical board into a virtual tracking tool. Ever. I’m continually surprised by the virulence of their reaction when I suggest that:

  1. it takes < five minutes a day, and
  2. team members can update their own items in both places as they complete them, and/or
  3. the team can rotate the update responsibility among all members.

To me, it’s a no-brainer: the benefits of a physical board are well worth this paltry extra effort.

(If syncing the board and the tracker takes any longer than five minutes, it means you’re tracking way too many things on either your cards or your tracking tool or both. I’d confidently bet you a fresh kürtős kalács that nobody’s even using all that data. If your process is too heavyweight, don’t blame the board.)

In the spirit of my typical engineers, who delight in finding complicated tool solutions for simple people problems, I fully disclose the existence of Agile Cards for JIRA, which purports to allow you to snap a photo of your physical Kanban board, e.g., with a Smartphone, and promises to parse the photo and update your JIRA tracking automagically for you. I do not have experience with this plug-in, so I have no idea whether it even works, but my typical-engineer heart (yes, I still have one) finds the cool factor highly appealing…

Feeling the pains

One of my mostly-collocated teams put up a physical board, after weeks of cajoling, but abandoned it after just one-and-a-half iterations of use. The team reported that having a Kanban board was great, they loved having the information easily accessible to all team members and found it extremely valuable to know the project’s status at any moment at a literal glance.

“Really? Why’d you stop using it, then?”

“A physical Kanban board is just too much overhead to maintain. I mean, when the business interrupts us in the middle of the sprint and tells us to drop all the work we have in process, and start over with a huge amount of brand-new work, the effort to tear down the entire board and rebuild it with all brand new stickies is totally unreasonable!”


Any Kanban board, physical or virtual, is just a messenger. The whole point of visualizing work as step one in a Kanban adoption is to identify bottlenecks and pains, so the team can work toward solving them. When the Kanban board exposes a team pain, if your solution is to get rid of the board so you don’t have to face the pain anymore, you are Doing It Wrong. Don’t shoot the board!


To me, the Kanban board has one purpose above all others: to bring the team together. Technical folks have a habit of valuing individual (perceived) efficiency over fluffy crap like team spirit and morale and trust, which I think is why a physical board can be an uphill fight and is also why I keep fighting it.

I’ve seen physical Kanban boards transform teams.  They improve communication, foster a spirit of ownership over the work, and create active engagement in daily stand-ups (which were previously dull and seen as a chore). I’ve seen physical Kanban boards transform organizations. They go viral and inspire non-delivery departments within organizations: I’ve been invited (begged!) to teach agile principles to HR, finance, and receptionists.

I’ve seen a lot of virtual board adoptions and a virtual board is just another tool. Even when the team likes it, there’s no transformation. There’s no energy. It’s a fine tool but nothing more.

How do you get buy-in from senior leadership in a large organization for the changes needed to transition to agile? If your CEO’s executive assistant is able to show her real-time status updates of major work using a physical Kanban board, and when asked where that idea came from can answer, “oh, it’s a technique I learned from your agile software development teams, it comes from Lean,” um, how far does that get you? Or the CFO finds that productivity and traceability in accounting have noticeably increased and they’ve got your physical boards to thank for it?

At one of the locations of one of my clients, their CEO was in town for an office visit, and he stopped to take a look at the physical Kanban board for a high-profile project. Several of the team members engaged him directly in conversation about the board, which represented a level of access they didn’t normally get at all, and as a direct result of pains he saw on their board, the team was able to get senior management support for key solutions they had been asking for for months!

You won’t get that kind of organizational participation by burying your process on the corporate network in some tool.


Get a board. I prefer physical, but if that’s a blocker for your team, then by all means get a virtual one. Visualizing the work any way you can is better than not. And then, engage the team around whatever you’ve chosen. Don’t fight with your board; focus on the work it represents and the problems you can solve now that you’ve exposed them.

What did you choose, and how did it go?

Care and feeding of your T-shaped individuals

How do you make sure you’re rewarding, instead of punishing, your utility players for their versatility?

Managing variability is a key agile practice and it’s one where many teams stumble.  Some feel the pain in “story sizing” or “estimation”; teams doing timeboxed iterations may encounter it when they scramble to finish what they committed or struggle to interpret and apply their velocity metrics.

There’s also variability in work types and roles, whether that’s the balance of code vs. test or specific coding skillsets like data vs. business logic vs. UI.  I blogged about it a while back as How Flexible Should an Agile Team Be?  A preferred way of managing variability while still allowing the specialization and deep expertise teams need is to cultivate T-shaped skillsets: deep in a few areas, with meaningful breadth across a range of others.

This carries the implication that the T-shaped individuals on your cross-functional teams will cooperate, flex, and share workloads.  That’s the point.  That’s what you have them for.

It also implies that at least some of the time, your T-shaped individuals will be working in their areas of breadth rather than depth—what Myers-Briggs would call out-of-preference.

That’s where a lot of teams hit a wall.  It turns out, just because someone on your team can do something in their breadth areas doesn’t mean they want to.  Doesn’t mean they love it.  I think we need to handle this situation carefully.  T-shaped individuals can be quite valuable and we don’t want to burn them out or alienate them.

In talking through this challenge with my current customer, I came up with two things that any T-shaped individual needs to know when you’re asking them to work on something that isn’t their depth:

First, they need to know and believe that you don’t expect them to work in their out-of-preference zone forever, or even very often.  They need to see a light at the end of the tunnel.  If breadth work takes over the stuff they actually love doing, you’ll lose them, which sucks for everyone.  If you find it necessary to drag them out-of-preference too much of the time, your team has a resource problem which you should solve with HR.

Second, they need you to fully understand, appreciate, and accommodate the fact that they’ll be slower and less effective in their out-of-preference areas than an expert in those areas would be.  If you have perfectionists, this’ll drive them crazy: they’ll hate delivering less than the theoretical best, and they’ll need reassurance that their effort is not wasted.

What do you think?  Have I missed something that you look for from your management team?

Update 4th April: Thanks, commenters!  Y’all’ve got me thinking about another principle.  I assert that it is never possible for the team or management to dictate someone’s depth skills.  They have to love a thing in order to get to be any good at it.  And can the team define someone’s breadth skills for them?  They can try, but they probably shouldn’t.

When we talk about how valuable T-shaped individuals are, we mean people who have natural strengths and interests and are flexible in how they help out the team at any given time… not minions who get assigned crap work because “somebody’s got to do it”.  (If you’re a sincere T-shaped individual who’s getting all the crap work, you’re insanely undervaluing yourself.  Go update your résumé.)  On the flip side, if your team members refuse to do out-of-preference work, maybe they’re not T-shaped at all; maybe they’re one-trick ponies…

A3 Management and Stock Issues

There are zillions of ways to make an effective A3. I needed to find a way I could understand intuitively, so I could get past trying to figure out the technique and move quickly on to using it for actual hard problems.

This week, Steven introduced us to the A3 management system and specifically the A3 format for delivering recommendations to our customer.

This is based on a Lean book, Managing to Learn (one of many books Steven lugged all the way across the Atlantic not on his Kindle). The deal is, the A3 is a paper size (approx. USA 11×17), and there are two columns with particular formats for presenting the nature of the problem and the proposed recommendation to fix, in a concise and collaborative manner.

As I was struggling to understand the mountain of A3s (all different) that Steven had brought along as examples, I noticed a pattern to them that meant something to me:

  • Harms
  • Significance
  • Inherency
  • Plan
  • Solvency

The A3 fits the outline of a very old-school stock-issues high school policy debate case. Of which I’ve written more than a few. (Cool kids don’t debate this way anymore, I’m told.)

  • Harms: the problem
  • Significance: what is the extent of the problem, and what metrics can be used to assess it before and after?
  • Inherency: what structural or attitudinal factors are reinforcing or worsening the problem?
  • Plan: the recommendation
  • Solvency: how will the recommended action steps resolve the problem, and which metrics will be used to measure success?

And here’s what it might look like in practice:

  • Harms: four teams are developing working software, but their integration and stabilization phases are trainwrecks and they have all come to dread their merges.
  • Significance: Team A has burned a week of their latest two-week iteration just on merging. Many of Team A’s changes from their previous iteration were lost when Team C merged over the top of them, and this will take at least another week to fix. Meanwhile, Team C’s release, which seemed tested and ready, has been delayed by nearly a month fixing bugs discovered after merging.
  • Inherency: the root of the problem is team branches. All four teams are working on the same product, and following a similar release cadence. All four teams easily decompose their work into small increments of working software that they are able to test and release every few days at best, every two weeks at worst. Isolating the teams doesn’t benefit anyone, and has led to the bad habit of isolated test and last-minute merge. No one team or role has responsibility for post-integration testing. Teams can’t easily understand or resolve merge conflicts found after weeks of isolation, so instead they tend to delete the changes they don’t recognize. Minor repairs to their process (many tried and failed already) won’t solve the fundamental problem that needless isolation causes harms. Only a comprehensive new branching strategy will solve.
  • Plan: implement a branch by quality strategy whereby the four teams, who are, after all, all working on a single product which is ultimately totally integrated, do their primary development together in one Dev branch.
  • Solvency: combining team branches into one will actually eliminate most code conflicts, and make any remaining conflicts smaller, simpler, and quicker to resolve. Earlier integration will force a number of additional practice improvements they are currently avoiding, most especially teamwork and coordination upon each checkin. Bugs caused by integration can be detected earlier. The teams will experience pain at first, especially because they have limited automated testing and regression will place new demands on their testers, but it will expose better data about their specific testing priorities, leading to better fixes in the long term. Finally, the early and frequent integrations should instill a sense, currently missing and sorely needed, that they are ultimately all one product team and that their success is measured not by the achievements of any one sub-team but by the value of the finished product.

So there you are. If you were a traditional-style high school policy debater in the USA in the late 1980s and you now want to know a key Lean management practice… yeah, OK, I’m the only one, aren’t I? Well, I’m good to go now.

And that’s my message here. I’m geeking out a bit about my modest debater past, but the real takeaway here is that sometimes I let learning get in the way of my learning. My new A3 trick is probably sub-optimal in lots of ways, but it’s superior to the A3s I wasn’t going to write at all because I didn’t know how.

Underpants Gnomes in Kanban

… or, no good joke goes unpunished

Kanban offers a lot of potential for targeted, specific, incremental change, but you will need to have or create a problem-solving culture to avoid stalling out.

Earlier this year I made the wisecrack around the office that my problem with Kanban is, it feels too much to me like the Underpants Gnomes:

  1. Visualize work
  2. ???
  3. Process improvement!

Northwest Cadence just got cheekier. You're welcome.

Steven, who thinks I’m funny, ran with it just a bit.

Last night at the ALM Summit, we had a great breakout (“Open Space“) session at which some serious agile luminaries held forth on the theories underpinning both Scrum and Kanban and process improvement in general.  Steven outed me and my joke, so now I think the heat’s on.  Can I unpack this idea and turn it into real learnings, or was it just a cheap shot?

Well, let’s put the obvious out there first.  Although Kanban does literally mean just “visual card” or “visual board”, Kanban in the context of software development process improvement doesn’t just say visualize work.  That’s only the first step.  There are supposed to be other steps after that.  Right?

Aren’t there?

This is where, for me, we start to run into issues.  I’m not being theoretical or cheeky here.  In my former organization, my team ran Scrum (-but) for 2.5 years; another nearby team made the decision from the executive level to implement “Lean-Kanban” instead.  They expressly agreed with something I’ve heard Kanban proponents advance as a strength: unlike Scrum, they could adopt Kanban without changing any of their existing process.  (They seemed awfully excited about that.)

They got great, in-depth training (which they kindly invited me to sit in on).  The following week, huge Kanban boards went up to visualize their entire portfolio.  The first thing they “learned” (unnecessary quotes because everybody on the team already knew it) was that they were massively overloaded: at least three times more work underway than they could possibly complete on time.

When a 12-person team’s Kanban board fills all the walls, floor-to-ceiling, of a 40-seat conference room, it’s covered in 3×3 post-its, and each team member needs four to six laminated South Park avatars to identify all the work they’re doing at any one time, they don’t need a high-priced consultant to tell them where the dysfunction—sorry, “opportunity”—is.

And how’d they address the dysfunction?  As far as I know, they didn’t.

Why not?  Honestly, I don’t know.  Kanban calls for teams to limit work in process (WIP) and it’s a fairly obvious next step in this case, in some form.  I know they learned about limiting WIP, because I was in their training classes.  It was easy for my friends on the dev and BA teams to blame upper management and stakeholders for failing to act, but I don’t know if they really fought for WIP limits or just rolled over.  I’m certain no one at any level sought out or embraced the pain of significant change.

A year and a half later, the Kanban-wallpaper was still up, and the team still said they were “doing Kanban”.  At a local Lean-Kanban conference, I got a chance to sit down with some of them during a break and asked how the process was going for them.

“It’d be fine if the BAs would quit dragging us developers into their ATDD meetings.  It takes up all our time and we can’t get enough code written.”

“Hey!  What do you expect when you’re so slow delivering code that we have nothing to UAT?  We don’t have anything else to do but work on future requirements.”

I gather that they still haven’t implemented WIP limits, at least not properly, and they’re not managing their queues in or out.  We’re sitting at a Kanban conference and these attendees are still near the point of food fighting because they’ve decided the dysfunction is each other instead of their process.

And that’s why I think the Underpants Gnomes are not just a one-liner in Kanban, but a real risk that should be taken seriously and planned for.  What happens when…

  • the team doesn’t know how to find the root cause of a dysfunction?
  • the team can’t agree on what the dysfunctions even are?
  • the team identifies a dysfunction, but doesn’t know how to solve it?
  • the team tries to solve a dysfunction but just replaces it with another?
  • the team’s organizational culture doesn’t support problem-solving?
  • the team isn’t empowered to make the changes they think are needed?

A team full of highly motivated problem-solvers with great communication and teamwork skills will probably get good results with Kanban, but honestly aren’t they all too busy building carbon-nanotube space elevators while curing cancer?  Or writing the book on process improvement?  Seriously, teams that natively possess awesome diagnosis and problem-solving skills, are they even having this conversation?

... and it's a Big Visible Display, too!

The rest of us need to pay attention to the Underpants Gnomes when we’re getting started in Kanban.

What’s your plan for Phase 2? Can you do it on your own or do you need help getting there?

Note: if you are/were on the team I’m talking about and I’ve gotten any of the story wrong, please send me additions or corrections or perspectives so I can update!

How Flexible Should an Agile Team Be?

There are different tricks to balance skill sets on a team for long-term performance.  Relying on pure “generalists” isn’t the only option.  (Some folks think Scrum demands this, but it doesn’t.)

In a recent blog post my colleague Steven asks the question, “Do Teams of Cross Functional Individuals Hide Dysfunctions?”  This grows out of some conversations we’ve had around the office about the intended meaning of “cross-functional” and whether it’s a virtue or a vice.

When I joined Northwest Cadence, which as we’ve established was not so long ago, I found earlier training materials referring to the need for “generalists” in Scrum, and some diagrams showing how team members might shift to other types of tasks during a Sprint.  But since my formal training in Scrum has been more recently, I recalled that the Scrum Guide calls for the team to be “cross-functional, with all of the skills as a team necessary to create a product Increment” (emphasis mine).  As I read it, this means the Development Team should have all the skill sets represented that it needs to complete the work of the Sprint, but it doesn’t say a thing about every team member needing to possess every needed skill, or even multiple needed skills.  (What if what the Development Team really needs in a Sprint is a specialist?)

Anyway, around the office we’ve started making the semantic distinction between “cross-functional individuals” (generalists) and “cross-functional teams” (generalists or specialists or a combination of both who provide in aggregate the needed mix of skills).

In our Scrum vs. Kanban Smackdown on Friday, Steven and I dug into the issue a bit more, and he mentioned that while single cross-functional individuals are less productive than specialists, he found it curious that the opposite is true in teams: teams of cross-functional individuals are more productive than teams of specialists.  (Source: Capers Jones, Applied Software Measurement.)

Fantastic Four's Mr. Fantastic, a.k.a. Stretch

It seems to me that there’s a delicate balance to be achieved between focus (preventing context-switching) and flexibility.

Particularly in Scrum, it’s critical to have a cohesive team, and one of the strengths in Scrum is that the team learns to work together more efficiently over time.  A Scrum team’s membership should strive to stay stable.  But given that the Product Backlog and the Sprint Backlog’s contents are variable, how can the team maintain a stable membership while ensuring it has all necessary skill sets for any work that may be thrown at it?

In Kanban, of course there’s no prescribed process: the first step is to visualize the existing flow of work, identify bottlenecks, and then address bottlenecks to promote flow. Again the question is, how should the team address them, especially over time as a variety of development items enters the work stream?

I think there’s no simple answer, but I have a few ideas, and I think they’re potentially equally applicable to Scrum and Kanban.

  • Swap Out Team Members.  I think this is a non-solution for both Scrum and Kanban.  If we weren’t trying to build more effective teams, we wouldn’t be here, right?
  • Balance the Backlog.  Items in the backlog or queue should already be right-sized and should represent standalone stakeholder value.  If the team works from a consistent Definition of Done, then it should be possible to figure out what skills are needed to deliver a particular item – and to break down an item if any stage of its delivery is too big for the team’s capacity.  However, this won’t always be perfectly possible: for example, some features may lend themselves to more test automation, while others demand more manual test, and these call for different skill sets on the team.
  • Negotiate.  In Scrum, the Product Owner and the Development Team work together to select the Sprint Backlog and they don’t always have to select the stakeholders’ highest priority items.  If it makes sense, they can pull a different mix of items into the Sprint to keep the workload balanced to the team’s capacity. Similarly, a Kanban team can pull new work into the work stream for any reason at all, and can choose to pull items that balance better with work already underway. However, this must not be used to mask dysfunction, especially because it risks taking the team too far afield of the stakeholders’ priorities.
  • T-Skills.  Team members who have needed depth in a few areas, but breadth and willingness to help out in others (“T”), can give the team the flexibility it needs to accommodate shifting Work In Process loads.  I think this is what most people really mean when they say “generalists”.  This can be effective when role-based bottlenecks are occasional and temporary.  However, this must not be used to mask dysfunction; if team morale is affected or the team resists seemingly reasonable calls to “swarm”, that’s an indication that their willingness to flex is being overused or abused.
  • Expose the Pain.  If the team’s skill sets are out of whack due to external constraints, it may be to the team’s advantage not to solve or compensate for this problem.  Instead, making the effects of the imbalance transparent to decision-makers and stakeholders may be what’s necessary to get a real lasting fix.
The Incredibles

Elastigirl rocks, but she still values her team.

In all cases, the entire team needs to be involved in and accountable for the solution, and as you see from some of the ideas above, the solution may need to start well before the work hits the dev/test phases of the team’s process.