Category Archives: scrum

The One Thing: Successful Daily Standups

Do you dread your daily standup? Do you despair of ever getting it into 15 minutes? Do you argue about what’s appropriate to discuss in it, and no matter what you try, somebody’s butthurt and it still takes an hour? You’re probably doing it by the book, and that means you are doing it wrong. Learn The One Thing to make it work.

bsktcase crosspost project

I’m cross-posting selected blogs from Northwest Cadence. Here’s the original post from 17 December 2013.

The traditional standup ceremony is wrong

For years, we’ve said that in the daily standup, each team member should answer these three questions:

  1. What did you do yesterday?
  2. What will you do today?
  3. Is anything blocking you?

Back in the day, my own team noticed that those questions are fundamentally awful. We and our colleagues would drone on about how we spent our time, which nobody cared about, and the meeting seemed endless and boring and our feet got tired. The standup isn’t supposed to be a status meeting, and yet question #1 is almost always treated as a status question; we didn’t mean to, but we did.

The revised traditional standup ceremony is still wrong

Years ago, my team and I came up with what I thought was a clever modification:

  1. What did you accomplish yesterday?
  2. What will you get done today?
  3. Is anything blocking you?

It’s very similar to the most recent changes in the Scrum Guide, which add “… to help the Development Team achieve the Sprint Goal” to the appropriate questions.

It didn’t help.

I think it didn’t help because I think they are still the wrong three questions, they focus the team on the wrong thing, and in so doing they invite the wrong discussion.

How does this happen?

I worked with a client’s team this summer and together we introduced a physical Kanban board into their existing iterative process. Daily, while standing in front of a truly ugly board with way too much Work In Process (WIP) on it, none of which ever moved, that they had no hope of actually finishing, they dutifully answered their three questions and went back to work. On the second-to-last day of the sprint, I couldn’t contain myself any longer. After they’d finished answering the three questions, I blurted out:

“Guys! When does your sprint end?”

“Tomorrow.”

“This stuff!” I pointed at the board. “This! Are you going to get it all done by then?”

They all hung their heads. Actually hung them. They knew. No way.

Why hadn’t they seen it before? Right in front of them! Hell, there was a single story on the board, that only one dev ever worked on, with an estimate written on it of 150 hours. The math on that, in a two-week sprint, is not favorable.

And that’s when I realized: by focusing on the three wrong things, they’d missed the right thing. The only thing that matters. The One Thing.

Why does it matter?

First, the daily standup is an accepted practice in agile, even lean, because it’s so important. It exemplifies, among other things, the lean principle of fast feedback and the agile principle of self-organizing teams. When it isn’t working, at best it’s a missed opportunity; more often it’s a symptom that agile itself isn’t working.

Second, one of the most common arguments that I hear from teams and managers against agile is “meeting overhead”. Introducing frequent meetings for grooming, planning, show-and-tell, and retrospective are worrying enough to teams, but when you pile on a “15-minute” standup that really takes an hour every single day, sirens and alarm bells start going off. Rightly so. Teams who find their productivity clobbered by meeting overhead are likely to abandon agile altogether.

Bad standups are an existential threat to agility.

The One Thing

Jack Palance as "Curly" in City Slickers

The daily standup is not for the “how” or even for the “what”. It’s for the “whether”.

In agile, we define short-term goals. Scrum makes this easy: the goal is whatever work we took into our sprint, and our target is sprint-end. (Short-term goals in Kanban are complicated; I’ll save that for a future post.)

The only question that matters in a daily standup is, “are we on track to meet our goal by our target?”

That’s it. The One Thing.

How does The One Thing help?

The One Thing reminds the team what the standup is for: to ensure that they’re on track to deliver as they intend. That’s what it’s always been for.

When the team is on track, The One Thing ensures they’re rewarded with a smooth, pleasant, mercifully short and to-the-point daily standup.

When the team isn’t on track, The One Thing focuses everyone’s attention on fixing whatever’s jeopardizing their success.

The One Thing exposes smells, too. For example, if the team doesn’t know or can’t agree on what the goal is, The One Thing makes that clear quickly, so the team can address it.

The One Thing in practice

Nowadays, my daily standups always start the same way: with a fist-to-five on the question, “how confident are you that we will meet our goal by our target?”

If everyone on the team is a 4 or a 5, the standup is over. Yes, really. Done. Make it so.

If there are any 3s, the team needs to discuss blockers or risks and prioritize getting them cleared. Identify slow-moving stories and swarm on them. It’s OK to be 3s for a day or two, but the team needs a plan to get to 4 or 5 quickly.

If there are any 2s or lower, the team probably needs to start negotiating scope: “what can we achieve by our target?” Limit WIP to those top-priority items in order to salvage as much value as possible.

How do they know The One Thing?

By visualizing their work, preferably continuously (meaning, don’t wait for the standup to update the board). I like a physical Kanban board for this, but whatever works. Holding the standup in front of an up-to-date board makes The One Thing easy to ask, answer, and validate.

The Rules of The One Thing

What comments are appropriate at the standup? Any that convey information that affects the answer to The One Thing.

What questions are appropriate at the standup? Any whose answers affect the answer to The One Thing.

Who can speak in the standup? Anyone who can contribute something that affects the answer to The One Thing.

Wait, does that mean chickens can talk in the standup? Yes, if and only if they are bringing the team information that affects the answer to The One Thing. For example, a product owner might announce a change in scope or priority. You’d want to know that before you get back to work.

But…!

What if the team is confident of The One Thing… and they’re wrong? Don’t they need to discuss it, to make sure their confidence is warranted?

No. It is not the purpose of the standup to convince anyone outside of the team that the team’s answer to The One Thing is correct.

If the team is struggling to get a reliable delivery cadence, their own confidence votes should reflect their uncertainty. If an honest assessment of progress isn’t happening in the standup, then the place to discuss it is the retrospective. Or a separate ad hoc meeting, if the retrospective isn’t soon enough. But not the standup itself.

Like everything else in agile, The One Thing assumes a self-organizing team of qualified, motivated individuals. If you don’t have one of those, playing around with the rules of your standup will not fix it; stop reading this blog post and consult your HR department.

After The One Thing

Once the answer to The One Thing has been achieved to the team’s satisfaction, the daily standup is over. Yes, really.

Now, take a moment to explicitly end the standup and dismiss everyone. Don’t take it for granted; do it out loud, using words. This is incredibly important for two reasons:

  1. Ending the standup makes clear to the team that the standup is over. :) More to the point, it demonstrates that whatever happens afterward is not the standup’s fault.
  2. Dismissing everyone gives team members permission to decide for themselves whether to leave and get back to work, or stay and talk. Conversation and collaboration are awesome, but after the standup they must be voluntary!

Resist the temptation to treat the standup as a captive audience. The purpose of the standup is The One Thing and The One Thing only. If you need a team meeting, schedule one.

The One Thing summarized: the essential daily standup

Billy Crystal as "Mitch" and Jack Palance as "Curly" in City Slickers

  1. Ask The One Thing: “are we on track to meet our goal by our target?”
    • If the answer is “yes”, dismiss everyone and get back to work
    • If the answer is anything other than “yes”, decide what to do
  2. Explicitly end

Fast feedback

What do you think? Can you envision a faster, more focused, more useful daily standup using this technique? One that maybe 80% of your team look forward to attending because it’s valuable to them and the incorrigible 20% grudgingly admit they don’t hate? Can you see the daily standup actually contributing to the team’s overall delivery success? Will your team celebrate its success by doing one-armed push-ups?

Try it and let me know how The One Thing works for you!

(And send me a video if you do the push-ups.)

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…

Vertical slices and SOA

Even the term “vertical slice”, a common stumbling block in agile adoption, kinda implies a large-scale n-tier application. Modern architectures and agile can play nicer together than that!

“Story sizing”, decomposition, vertical slice of functionality, Minimally Marketable Feature (MMF), Minimally Viable Feature (MVF), and my personal least-favorite, Potentially Shippable Product Increment (POS*). I think it’s the biggest hurdle for orgs moving from not-agile to agile. I think many other problems with initial adoption (estimation, timebox sizing) boil down to this one.

Every dev team I see trying to get started with this initially tries exactly the same wrong thing, usually because it’s how they’ve organized their work in their not-agile process before: they want to split things up by architectural layers, and build, let’s say, all of the database and then all of the business layer and then all of the UI.

Any time I see a sentence with “do all of… and then all of… and then all of…”, what’s that remind me of? Oh yeah: waterfall. There are reasons we devs cling to this in spite of ourselves. Maybe another post another day.

The thing is, “vertical slices” aren’t satisfying either. Every single team I’ve worked with resists and/or struggles with this for basically the same reason: the users asked us for an epic-sized feature because that’s what they want. They don’t want a slice of a feature, they want a feature. One of the cornerstones of agile is that we’re doing these short iterations in order to get feedback from users. That’s hard to do when they’re inherently unsatisfied with these ugly proto-features they don’t want (and they’re deeply alarmed when someone calls them “potentially shippable”)!

I discovered an interesting thing at one of my customers recently, though. We struggled with “vertical slices” vs. Big Database Up Front for like two days, and only then did I find out how much they’ve worked to transition their legacy LOB apps into a SOA model: collections of beautifully loosely-coupled services and APIs with clean interfaces talking to each other to achieve some nice user-interfaced result.

Wow! This was exactly the hook I needed. Because what is a service or an API if not a neat encapsulation of a small logically-contained bit of functionality? I realized that even the term “vertical slice” implies a traditional n-tier architecture in kind of a large-scale sense. Today’s SOA (is that still what we call it?) has already broken down those giant tiers into little slices. The team didn’t even realize they were already doing it. Each service might have its own little n tiers, but on a much smaller scale. Small is exactly what we need!

My customer got stuck trying to decompose from the epic feature level, still thinking about all the little services they’d need to assemble (plus BDUF) in order to hook up a UI and show a “vertical slice” to the user. They didn’t see their services as value in themselves, but I think the value is right there. APIs don’t have a user interface, but, um, the “I” stands for “interface”. They encapsulate something someone finds useful, and they are independently testable. Better yet, they almost demand automated testing, a practice we already wanted to reinforce. Imagine: at the iteration review, sure, the team should demo UI mockups early and often to get feature-related feedback from users… but can’t they also “demo” individual APIs (that implement underlying business capabilities and algorithms that the users do care about) by reviewing the acceptance criteria for the service and showing off a suite of automated test results to prove that the logic works?

I guess my point is that, as it always has, agile practice goes hand-in-hand with what we know about how to architect high-quality, maintainable software. I was just pleased to understand this in a new (to me) way.

* j/k. But I do hate that term.

Seattle Scrumpocalypse 2012

Are there any conditions in which a Sprint’s timebox can legitimately be extended?  I think I might have found one.

In my Scrum-damentals webcast I’m pretty strict in advising that teams should not extend the timebox of a Sprint, even when things go pear-shaped.  Why not?

You and your team have certain goals as you’re getting ramped up with Scrum:

  • Learn your true velocity based on real-world measurements
  • Improve your estimating and forecasting capabilities through regular feedback
  • Refine your story sizing and task breakdown skills
  • Develop a comprehensive definition of done (e.g. don’t overlook needed work)
  • Over time establish reliable metrics for future forecasting

Extending a Sprint in order to complete all of its deliverables undermines all of those goals.

Besides, there are better alternatives.

  • With the Product Owner’s approval, you can reduce the scope of the Sprint at any time for any reason
  • I personally like a Kanban WIP (work in process) limit to be in place from the start of the Sprint, because if you need to cut scope mid-sprint, it’s a lot nicer to have some completed stories (credit!) and some unstarted stories than all half-finished ones (no credit for any of them!)

This week one of my Scrummy friends presented me with an interesting challenge and got me to reconsider—or rather, refine.

You may have heard that we had a little weather up here in the Northwest.  Being the tech city that we are, nearly everyone (who doesn’t already do this full-time every day) retreated to work from the comfort of their living room and their fleecy pajama pants.  I won’t speculate on what this does to teams’ productivity, but we can safely say that widespread power outages that started on Thursday knocked out all but the most hardcore workaholics (running their laptop on battery, tethered to their 4G smartphone, recharging off the Prius in the driveway, you know the type).

My friend spent his week trying to salvage a Sprint which was scheduled to end on Friday.  He phoned in each day to his daily Scrum.  Standing up isn’t prescribed by Scrum, but lots of teams appreciate the value of a standup and he indeed stood up, pacing the kitchen during the requisite 15 minutes.  They lost time to and were blocked by the storm in various ways that I don’t know all the details of, and on Wednesday he lamented to me that, with all they’d have to cut from scope, they were facing a “failed Sprint” because you “can’t” extend it, not even to account for the weather.

I gave this a little thought and asked, “didn’t you determine your Sprint backlog based on your team’s capacity?”  Of course, he said.  “If a federal holiday fell in the middle of your Sprint and your entire team missed a day, would you count that against their capacity or would you plan around it?”  Don’t be silly, you wouldn’t count a federal holiday as a team Sprint day any more than you’d count a weekend, he said.  (Neither one of us is the tethering/Prius type.)

“So, if nature drops the equivalent of a federal holiday into the middle of your Sprint, why not move the Sprint around it?  If you move the Sprint end date by one day, aren’t you just keeping the Sprint the same length it was before?  The same duration your team had in mind when it accepted the scope?”

So, in my mind, this is a legitimate reason to change the end date of a Sprint.  I’m not sure it even counts as “extending”—the point is to keep the capacity constant.

I also told him that I don’t remember seeing “failed Sprint” in the Scrum Guide

Finally, if you think a little snow is a bad reason to lose productivity during a Sprint, Seattle sportswriter Art Thiel and I invite you to shut the hell up.

Keep warm, Seattle!  And don’t run your Prius inside!

Scrum for One

My customer is a team of one, which means that by the Scrum Guide he can’t be “doing Scrum”.  Whatever.  Scrum still has a lot to offer in his situation.

"Same procedure as every year, James."

My sächsische (Saxon) friends introduced me to the traditional New Year’s programme Dinner for One, in which elderly Miss Sophie’s loyal manservant James, due to personnel constraints, must attend to every detail of her 90th birthday party himself.

Last month, I visited a customer to perform NWC’s first official Scrum Health Check, a new offering I stole adapted from my colleague Martin’s blog post (“Are you doing Scrum? Really?“).  I sent lots of advance-prep materials and brought a beautifully-crafted checklist that I planned to use to determine their Scrum baseline.  But all that went out the window when I arrived onsite and found that my customer was a Scrum Team of One!

And then I tripped over a tiger

Me: First question.  Do you have Development Team(s) of 6±3?

Customer: Um, no.  There’s one other guy, sometimes, but we had this re-org and he reports to another manager now so… yeah, it’s pretty much just me.

Me: All righty!  Our Scrum Health Check is finished.  You are not doing Scrum.  Now, let’s talk about how you can use Scrum to make your… er, team… most effective in your situation.

And that’s what I’m about with Scrum.  Instead of throwing the entire Scrum Guide out the window, we kept it around and talked all day about the other Scrum practices my customer could use: in particular, we identified an ordered backlog and proper structure and focus for the biweekly Sprint Planning and Reviews/Retrospectives, to provide transparency and improve management buy-in.  These were his most urgent needs and we both agreed that Scrum could help—that’s why he picked it in the first place!

"Well, I'll do my very best!"

I consider myself fortunate to have arrived on the Scrum consulting scene right at the time when Scrum is making changes to become less rigid, less religious, and more widely useful (without diluting the structure that makes it so effective).  It would be a stupid waste (for all of us) to turn my customer away from Scrum just because he isn’t canon.

Scrum Renaissance

Are you sick and tired of rigidity and attitude in the Scrum community?  Me too.  So is Scrum.org.  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 Scrum.org 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 Scrum.org 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 Scrum.org 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 Scrum.org 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 Scrum.org 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, Scrum.org 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!

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!

Before

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 scrumdamentals.eventbrite.com!) 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?

This:

THE CAKE IS A LIE

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.

See?

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.

WWKD?

My Scrum knowledge was out-of-date.  The new Scrum guidance is streamlined to essentials and I like that.

Last Friday I was privileged to serve as a guinea pig for my colleague Martin‘s Professional Scrum Master course.  The afternoon prior, he asked me and my colleague/classmate James to read the Scrum Guide and take the Scrum Open Assessment, specifying that we should score at least 75% on the assessment to show our readiness for the level of the course.  James did exactly as asked, posted a fine passing score, and thoughtfully generated this blog post which instantly became the most-viewed in Northwest Cadence blogging history.  Meanwhile, I flunked the assessment and wrote a blog post about how my new USB adapter has googly eyes.

Not the best student, me.

On Friday it was time to double down, literally.  As a practice run, Martin condensed the two-day course into one long day.  With only the three of us, we had lots of opportunity for discussion and debate as we worked through the PSM material.  Martin’s insights, having used this stuff in the real world, are invaluable too.

Mid-morning, our new social media guru Laura asked us to live-Tweet or Facebook our thoughts about the course… a request she may swiftly have come to regret, as we were feeling feisty and immediately began Tweeting helpful suggestions such as marketing “WWKD?” beaded bracelets.  (Hmm… chicken & pig Bandz!  Calling patent office…)

At the end of the day, we took me up on my (frankly self-defensive) suggestion to use our prior scores as a baseline and take the Open Assessment again to see how Martin’s teaching had helped us to improve.  Both of us had higher scores, but if mine is to be believed, Martin’s definitely the best Scrum instructor out there:

My score on the assessment, after a great class

Didn't just ace it... did so in 4 minutes, 49 seconds

No, I didn’t cheat.  Yes, I’m kind of one of those annoying good-test-takers.  (Which, as with SAT and the like, should not be confused with “knows the subject matter any better than a non-test-taker”.)

But let’s get serious for a moment.  The questions that tripped me up the first time were, in fact, meaty and interesting.  Scrum has evolved and simplified in recent years.  Before joining Northwest Cadence, I spent nearly three years on a reasonably effective Scrum-but team (which I guess really does make me a Scrum-but Master), and as I spent the day learning new insights about the Product Owner role and its responsibilities, the Scrum Master role and its limitations, I recognized so many nifty little practices – some we used, some I wish we’d used – that either solved or might have solved real issues we faced in the wild.

My favorite part, by far, is the way in which well-defined roles in Scrum empower the development team.  Martin recently posted about the Rolled Up Newspaper Method of bringing developers around to Scrum.  I understand it makes me a filthy tree-hugging hippie, but I don’t believe in the rolled-up newspaper for dogs or developers.

As it happens, I train my dog at Ahimsa in Seattle, an amazing place with fantastic results, run by a rock star genius mathematician who left academia to train dogs and their owners to get great results using positive methods that empower the dog.  Hmm!

(Those who know how much I adore my dog, and how much I adore my former development team, won’t blink at the comparison of developers to dogs.  Also, Martin started it.)

My lovely little dog, peeing outside like he is supposed to

Dogs, like developers, can be trained to pee outside using exclusively positive methods.

For at least the last three years, I’ve said that if developers understood how much Agile, and specifically Scrum, helps them with problems they care about, they’d demand it. That’s exactly what I did, although I understand that as a “developer” I’m a bit of an odd duck.  (Odd pig?)

Anyway, here are a couple of specifics I find intriguing:

  • I like the way the Product Owner has absolute control over the Product Backlog and its sequencing.  I like how “prioritization” has been changed to “ordering” to emphasize that it isn’t just the stakeholders’ priority or preference that drives the sequence: any number of other criteria may be used, and the Development Team is free to negotiate with the Product Owner on this matter.  The Product Owner is accountable to the stakeholders for satisfactory results, let’s say for delivering value, but the stakeholders don’t control the details of how this is accomplished.  I like how this gives the Development Team opportunities, e.g., to propose knocking out valuable low-hanging fruit, or to request re-sequencing to smooth out architectural or infrastructure dependencies.  A strong, positive relationship between the Product Owner and the Development Team (and the stakeholders) will yield great results and a better quality of life for developers.
  • I like how the Scrum Master’s job is to get the hell out of the Development Team’s way.  I like the emphasis on Servant Leadership in this role.  Over and over again, Scrum training questions and scenarios beat this point into the student’s head: the Scrum Master doesn’t solve problems or make decisions.  The Scrum Master only preserves the Development Team’s autonomy and provides them with any structural assistance needed for them to solve the problems or make the decisions themselves.  This is exactly what we devs say we want – hire us to write great code, then leave us alone while we do it.

On my former team, I was simultaneously Scrum-but Master and Technical Lead.  This was ill-advised for at least two reasons: Dev Team members shouldn’t have titles, and my combo-role seems like a conflict of interest.  But looking back on it, I can see the beginnings of some really nice practices: as Lead, I had the opportunity to participate directly in Product Backlog grooming throughout each Sprint, giving the team’s technical feedback on complexity, dependencies, and quick wins.  Two successive Product Owners were great to work with and did a great job of synthesizing technical recommendations with our stakeholders’ priorities – no small feat, considering how stakeholders proliferate and conflict with each other in higher ed.  Even struggling with Scrum-but, we did some amazing things as a team and delivered some really cool software in the federal compliance space.

  • I like the way Scrum is a framework, within which the Scrum Team has total freedom to write PBIs, decompose requirements, and develop, test and deliver software in whatever way works for them.  It doesn’t prescribe the SDLC: it fosters an environment in which an SDLC can happen reliably, because they can adapt and grow one that works well for them.  In this sense I’m seeing similarities to Kanban but with a lot more structure.  I don’t mind structure and neither do developers generally, if it’s a good one!

I came to Northwest Cadence expecting to be a defender of Scrum-but, which might yet occur, but for the moment I’m really fascinated by the framework itself, straight up.  I’m excited to dig in and put my public-sector experience to work with a more diverse clientele. I have some cool things I can teach already, but test scores notwithstanding, I also have a lot to learn.

Look for me to test and grow these Scrummy ideas in our upcoming public events!  I haven’t heard back yet on my idea for a bracelet giveaway…