Author Archives: bsktcase

Scrum Renaissance

Are you sick and tired of rigidity and attitude in the Scrum community?  Me too.  So is  Let’s get over it together so we can get some work done.

Stuff has been brewing in the Scrum world this autumn, and two big events aligned last month: the Professional Scrum Trainer global meetup followed by the ALM Summit.  I’m not a PST (yet), but the impact of the meetup was unmistakable as fired-up PSTs stormed the Summit and they and rolled out both conversations and official sessions with some of the new messaging around Scrum.

My PST colleague Martin is tackling a number of the substantive changes in his blog (“Are you doing Scrum? Really?” and others).  I think he captures well what I’m most excited about: the new language and the new approach do a lot to undo the rigidity and religious warring around Scrum.

To me, the first big hint of changes to come was when David Starr joined back in July.  In his announcement, he pointed out that he’s “more pragmatist than zealot” and wrote favorably about a long list of practices that many folks in the process community have made out to be “competitors of” or “incompatible with” Scrum for some reason.  I know David’s been involved in the world for a long time, but it struck me as potentially a big deal to have him officially on board.

Bringing a measure of tolerance to the process wars

In October, we got more evidence from that change was coming: “Scrum is Open for Modification and Extension“.  A coder might initially say “open to extension, closed to modification”, so it’s interesting to think about why they didn’t.  It’s gutsy for to put itself out there as willing to change the framework itself in response to community feedback.  Modification is formalized, which means it does not seem to be an invitation for immature teams to pick and choose and throw out and make up practices willy-nilly and call them “Scrum”.  I’m interested to see where that goes.

It had a good run

That brings us to the really big news: the death of Scrum But.

I have no doubt that Scrum But, as a concept, was intended to be helpful. I know this because I just finished co-authoring a slide deck built entirely around Scrum Buts: why your rationales are legitimate reactions to the difficulties of Scrum practice and should be heeded, and why a more thorough understanding of Scrum principles is almost always a better solution than a Scrum violation.  I am certain I was trying to be helpful.

Seriously, in the space of two weeks I went from “the trouble with your Scrum But deck is that you keep refusing to spell it with two Ts” to “you’re gonna have to throw out that Scrum But deck”.  Two weeks!  Is this a Renaissance or a Revolution?!

Scrum But is dead.  Long live the Scrum Curve!

The Scrum Curve: no buts about it

I stole this from Martin because it’s awesome and it’s a much more useful way to illustrate the point that matters: Scrum isn’t a boolean, it’s a continuum.  Teams may be doing Scrum to greater or lesser degrees.  Yes!  There is room for variability in practices that we can still call Scrum!  Now, instead of clucking (get it?) at teams for being “Scrum But”, we can help them refine and improve their Scrumminess to improve their performance. Instead of all or nothing, we can fully support incremental adoption and growth over time, including extension practices (like from Kanban) that working together take teams to Scrumfinity and beyond.

Update: It’s a good day for a Renaissance!  By delightful coincidence, rolled out their new front page today.  I’m excited to be engaged with what’s coming next!

Just look what they found space for!

ALM Summit: devgrrrl Evolution

I’m working on a blog post wrap-up of the 2011 ALM Summit experience, so today I did a little bit of white-glove research in the archives.

I can’t find archaeological evidence of my attendance at what was then still called p&p summit in 2006, but I know I was there because that’s where Peter Provost & Michael Puleio gave their “Agile Talk on Agility” which blew my mind and changed the way I do software and public speaking and made me a loyal Summiteer for life.

I did, however, find some real treasures: my p&p 2009 and 2007 (!) adventures in liveblogging.  They’re essentially my scribbled notes, so a lot of the actual content is completely unintelligible now, even to me, but they provide a window into my growth as an attendee and as a professional in this field.

Even at the time I was writing them, I knew perfectly well that those blog posts were an outlet for my insecurities as a dev and a #devgrrrl, so you’ll see lots of that in there (see also the posts in between, from TechEd 2008).  If you read them in chronological order, I think you’ll see a growing level of experience and confidence.

I switched to livetweeting the rebranded #almsummit in 2010.  By then, I was fully aware that the great value I get out of conferences isn’t the received wisdom from a speaker in a lecture hall and never has been and I’m not sorry.  (See also: my college, with an average class size < 20 and a high degree of informal access to faculty.)  In 2006, 2007 and 2009, it was clear that I learned more by talking with colleagues about the previous hour during the 15-minute coffee breaks than I did in the hour itself.  That’s why I always worked so hard to recruit a good group to come with me.  The other big change in 2010 was that I quit being afraid of the broader community, and I put myself out there to engage with them.  Maybe the interactivity of the Summit’s little Twitterverse helped: I started to see that highly skilled professionals struggle with the same issues as I do, or even struggle with issues my team had already, in our way, solved.  I even got retweeted!  In other words, I might have something to contribute!

Plus, I was thrilled to witness the impact of the community’s livetweeting on the entire 2010 Summit.  We stopped talking about Agile in a waterfall way (top-down, planned in advance) and started actually putting Agile Talk About Agility into practice (self-organizing, continuous feedback)!  It was like our collective lightbulb moment!  And, as Agile techniques are wont to do, it left me feeling smart and empowered.  I can do this!

The other big event in 2010, not recorded anywhere, was my chance meeting with Linda from Northwest Cadence during one of the aforementioned coffee breaks.  We hit it off, which set some slow-moving wheels in motion throughout 2011 and landed me where I am today.  It’s a good thing I’m not (too) afraid of the ALM community any more, because I’m up to my neck in it!

Stay tuned to the Northwest Cadence blog, where I’ll talk more about making the transition from acolyte to Platinum Sponsor at this year’s Summit…

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!

Getting Personal with LIVE Events at the Microsoft Store

Come to the Microsoft Store in Bellevue and let me talk at you about ALM.

It’s impossible for me to talk about our new Coffee Talk LIVE series without also mentioning how much I love my little brother.  He’s been in retail management about as long as I’ve been in IT, and he’s really (objectively, I swear) good at it.  So last fall when he joined the team of the soon-to-be-opening flagship Microsoft Store in Bellevue, I knew they’d picked a winner and I hoped he had, too.

(I’m still getting used to the fact that he’s got a blue badge and a address and I don’t.)

I loved learning all about the Store from an insider’s view.  I turned out for the festivities on that crazy opening night in November, with Dave Matthews playing outside the front doors and the mall overrun with geeks.  You definitely don’t see that every day.  My house filled up with handy, reusable Microsoft Store shopping bags in all four colors.

The day I had my job interview with Northwest Cadence, I swung by the Store afterwards.  My brother was just getting off-shift, and he let me decompress over sangrias at the Bellevue Azteca.  (Don’t judge.)  Then I waited, and waited, and waited for things at NWC to settle down long enough for them to call back and—by then, honestly, unexpectedly—offer me a position.

Fast-forward just a bit to my first assignments here at Northwest Cadence: delivering our ALM Catalyst series of webcasts on a variety of Visual Studio 2010 topics.  Perhaps some of you reading this newsletter heard some of my sessions.  Hi!  How’d I do?  Studying up for the series was tough, since so many of the topics are new to me.  I’m grateful for the support of the team who helped me prep, shadowed my sessions, and helped me field questions!  I’m starting to get the hang of things now, and I’ve also taken on some of our biweekly Coffee Talks focusing on process and Agility.

But, from the beginning, one of the key things that frustrated me about the webcasts was the one-way nature of the LiveMeeting format.  Even with audio and a phone conference line, I find it really limiting that I can’t see any of you.  Are you nodding in agreement or furrowing your brows because I’m not making any sense?  Am I going too fast?  Too slow?  Is the content too advanced or too basic or just right?  Where should I skim over because it’s no use to you, and where should I dive deeper because you’re eager to know more?  Here I am teaching about awesome tools and techniques to get real-time feedback on your software development processes so you can make a better product… but I’m stuck with waterfall content delivery and a QA feedback cycle that doesn’t start until after I’ve deployed myself to production!  That won’t do!

And that’s when it hit me.  The Microsoft Store has a theater space!  Non-profit organizations and small businesses can sign up to use it for their events at no charge; my brother had told me about a “girls in technology” event series that one of his colleagues helped organize.  There’s no requirement to tie in with Microsoft products, but I figured the fact that we’re a Microsoft Gold Certified ALM Partner talking about their developer tools would make it an even better fit.  The store is bright and engaging and fun, just like Northwest Cadence.  Why not put on some of our events there?

My brother put me in touch with their Community Engagement Manager, and we confirmed that the Store is a perfect place for exactly what we had in mind: Coffee Talk LIVE, an all-NEW series of highly engaging, highly interactive sessions covering a variety of ALM topics.  We’re creating all new content for this series, so even if you’ve attended our webcasts before, we hope we’ll be able to show you something new.

As the name suggests, we’ll serve coffee, and we’ll do live demonstrations of Visual Studio features on the theater’s big screen.  You, yes you, can interrupt us with questions any time.  If we catch you yawning, we’ll either offer you a refill or open up for group discussion or otherwise re-focus the content so you always get something fresh and relevant to you.  We’ll have special giveaways and door prizes to make it even more fun, and when we’re finished you’ll have plenty of time to get to the office, or stay a little longer and play in the Store before it opens!  There’s Xbox, Kinect, Surface, Windows Phone demos on the giant video wall, and lots more.

Real coffee and real ALM talk at the Bellevue Microsoft Store on October 13

I’m really excited about this new series, and I’m thrilled that Northwest Cadence picked up my little idea and ran with it so thoroughly!  We did a dry-run of sorts this week, and four intrepid early-risers joined us at the Store for a totally customized presentation on Visual Studio and, as it turned out, Scrum, with lots of Q&A.  Just what we were going for!

At our next event, you’ll see the Bellevue debut of my new extended presentation on Test Professional, heretofore given only in Tempe, Arizona (my roadshow event last week) and as a webcast that I did for just one company in Florida.  It’s 90 minutes of serious hands-on testing techniques from manual to automated, tester to developer, with just the right amount of soapbox thrown in.  I promise to live up to the new Coffee Talk LIVE tagline: “Less Deck, More Demo”.

Register here for Testers Get Professional on Thursday, October 27 at the Microsoft Store in Bellevue.  50% off if you enter discount code earlybird before Friday, October 21!

Now that my little brother’s been promoted and relocated to help open the new Microsoft Store in Santa Clara, I won’t be able to use these events as an excuse to hang out with him… unless y’all show up in droves and make it a huge success and I get to take it on the road…!  Either way, hope to see you there!

Agile Project Planning: The Cake Is a Lie

We cling to old-fashioned long-term plans because they are familiar and we think they provide certainty, but they don’t.    We shouldn’t sabotage Agile by trying to bolt on a (dishonest) long-term plan; we should understand and embrace what we’re getting in place of the plan.

I’m blogging this from 35,000 feet, almost entirely just because I can.  I’m coming home from two things I’ve wanted to do for a long, long time: [1] travel on business and [2] get paid to talk.  Yes, it was as good as I hoped!

Plus I got two states I needed!


After! (It is ON, North Dakota.)

Anyway, tomorrow I’m slated to deliver the inaugural session of our “Scrum-damentals” Coffee Talk (free! register at!) and I’m taking advantage of Alaska Airlines’ in-flight wi-fi to put my personal touches on an awesome slide deck created by our in-house Scrum Authority, Martin.  Scrum-damentals will cover common Scrum adoption challenges and the dreaded ScrumButs.  One of the Buts that Martin wrote up is the tendency to try to do long-range scope and release planning in spite of the Scrum directive to plan only the next 3-ish Sprints in any detail.

In fact, this is one of the clearest commonalities between Agile and Scrum.

And my former team did it.  I helped.

So why’s that bad?  We know upper management is often uncomfortable with Agile, and a little release planning is necessary to keep them happy, right?  What’s the problem?



When we succumb to pressure to project-plan, we’re giving upper management false hope.  We are lying to them.  We know it.  They probably know it, too.  We have absolutely no way of predicting accurately what we’re even going to attempt to deliver in a Sprint a year from now, much less what we’re going to accomplish in that Sprint.  It’s insulting to everyone’s intelligence to pretend otherwise.  And we, the team, participate in our own downfall when we play along.

In tomorrow’s Coffee Talk, I’ll cover some strategies we can use to push back against the demand for the plan.  Bottom line: we have to speak up and we have to educate our upper management about the benefits of Agile.  When they start to understand how much they gain by doing Agile honestly and transparently and fully, they’ll have a much easier time giving up the dream of the delicious cake.


Multi-Monitor for Cheapskates

The Kensington Universal Multi-Display (USB) Adapter is a good alternative to getting a whole new graphics card, but my installation of it wasn’t without peril.

When I arrived last month, Northwest Cadence provided me with a Dell pLatitude and a very nice ViewSonic widescreen HD LED monitor.  My officemate brought in his own Dell dock and a second (huge) external monitor for a total of three displays.  I hate to be outdone, and it just so happened that a surplus monitor found its way onto my desk, so I set about trying to get it configured for a wraparound display experience.

At first, because I’m completely dumb, I assumed I could just pick up a splitter cable, plug both monitors in, and call it good, because that’s how all the workstations at my former employer have worked for as long as I can remember (desktop machine, 2 monitors, splitter cable, magic).  Steven pointed out that this would only duplicate the same display on both external monitors, not extend it as I obviously wanted.  I didn’t believe him, so checked with Google/Amazon.  Ugh.  I don’t mind when other people are right… as long as I agreed with them to begin with.

$3 splitter cable option == fail.

Next, Steven offered me a couple of different Matrox adapters, a TripleHead2Go and a DualHead2Go, that we had sitting around the office already.  These are very fine products and do what they say on the tin.  However, and a hearty thank-you to Matrox for documenting this so well on their site and saving me a bunch of time, they require that both external monitors have identical screen resolution/ratio.  Otherwise they default to the worser one.  (It’s because they simulate an extended display by tricking Windows into thinking the two monitors are just one really really wide screen.)  My scrounged extra monitor wasn’t nearly as nice as my new official monitor, and it’s just morally wrong to display 1680×1050 on a monitor that’ll do 1920×1080.

Already-paid-for Matrox adapters, for my purposes == fail.

My laptop has a variety of ports out, including an HDMI, so Steven ordered me an HDMI-to-DVI cable and I plugged it in (alongside the other monitor using VGA) with high hopes.  No worky.  When I finally located and dug into the nVidia control panel, it was pleasant and clear in its documentation that my laptop’s graphics card would support either VGA out to an external monitor or TV out via HDMI port, but not both at the same time.  One external display out, not two.

$12 HDMI-to-DVI cable == fail.

At this point, most sensible geeks just install another graphics card.  But I haven’t been a consultant very long, so I haven’t yet learned to think of my time as money, so I was determined to find a “less-expensive”/less-invasive option.  (I’m perfectly capable of taking a laptop apart and reassembling it, but this is my only work machine and that’s a whole ‘nother kind of downtime, that I can’t afford.)  Also, it felt like giving up.

New graphics card in laptop == deferred.

My colleague Martin has, on his laptop, a super-cool 1G graphics card and a DisplayPort. We argued for a while about whether my DisplayPort would work along with the VGA without a new graphics card (he was certain it would) or whether it would go the way of the HDMI (my position).  I conclusively won this argument when we discovered I don’t have a DisplayPort. (The thing on my laptop that I thought was it is actually an eSATA port.)

DisplayPort, for my purposes == fail.

Steven offered to order me a Dell dock like my officemate’s, which I don’t even know how much those cost, but by this time I was on the hunt for a cleverer solution.  I hope docks are expensive.

Dell dock == deferred.

On Amazon, I discovered an intriguing gadget.  SPOILER ALERT: the word “gadget” should make it clear to you how this story will end.

The Kensington Universal Multi-Display Adapter seemed like the perfect solution. Relatively cheap ($56), USB, and more than 100 reviewers almost unanimously agreed it was quick and painless to install.  I read the description lots of times to be sure it met my two acceptance criteria: extends the display to an additional monitor regardless of graphics card capability, and supports monitors of differing resolutions.  Additional coolness included ability to hub up to 6 of them (!) and a general consensus that the video quality doesn’t degrade through the adapter.  Sold!  Santa Steven kindly ordered me one.

And then, it arrived!

And then, I attempted the install.

OK, let’s be honest here.  When an installer tells you to shut down all other running programs, who really does that?  Right?  It’s 2011 and besides, I’ve ignored that warning lots of times before and it’s been fine.  Until this time, when I forgot about DisplayFusion (a multi-monitor wallpaper and windowing utility) and left it running while attempting to install display drivers.

Pro tip: don’t do that.

For my trouble I got a Blue Screen of Death and a bunch of missing/corrupted graphics drivers when the machine came back up.

Since I’ve already gone on long enough and I think I’ve been cute and funny enough for one blog post, I’ll skip the entertaining saga of the entire next week and go directly to the end where, just as I promised my colleagues I would do, I finally got everything working!

Windows 7 boot, after things went badly wrong:

  • Uninstalled the failed DisplayLink drivers
  • Uninstalled DisplayFusion entirely just to be safe
  • Reinstalled nVidia drivers
  • Rebooted a bunch of times
  • Installed latest DisplayLink driver from DisplayLink website per Kensington support person’s recommendation
  • Skipped the Kensington install CD and just plugged in the USB adapter which promptly installed its own proper drivers
  • Rebooted more
  • Success!
  • P.S. Reinstalled DisplayFusion, which works fine

Windows Server 2008 R2 boot:

  • Uninstalled DisplayFusion entirely just to be safe
  • Attempted the Kensington install CD, which failed saying DisplayLink couldn’t be installed on Server and referring me to DisplayLink website; DisplayLink website gives no indication that Server is supported
  • Downloaded latest DisplayLink driver anyway, what could go wrong?
  • With trepidation, rebooted after apparently-successful DisplayLink install
  • Plugged in the USB display adapter which promptly installed its own proper drivers
  • Success!
  • P.S. Reinstalled DisplayFusion, which works fine
My three monitors

Victory looks like this: panoramic, with a single image spanned as wallpaper (photo by me)

Update, November 2011: Occasionally—not every time, but often enough to be irritating—when I try to view a video on the Windows 7 boot, it bluescreens.  Doesn’t matter which monitor the video is on, doesn’t matter if any external monitors are even in use.  Investigation forthcoming.

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.