The only 2 questions to ask in your daily standup

Leave a reply

Stop statusing and start standupping with the only two questions that have any business being asked in your daily standup. Take back your team’s time and its sanity—and more importantly, put the standup to work helping you deliver!

bsktcase crosspost project

I’m cross-posting selected blogs from Northwest Cadence. Here’s the original post from 24 March 2015.

In 2013, I wrote that the traditional “three questions” in the daily standup are wrong, and contributing to a plague of bad standups, and that focusing on The One Thing would help teams get the value they want from those dreaded 15(+) minutes per day.

Well, I’ve never been accused of being great at arithmetic. After more than a year of coaching teams on a new approach to the standup, they’ve taught me that The One Thing is exactly right, but in practice there are actually Two Things. Two One Things.

I recently taught a Scrum team The Two One Things, and I could tell by their reactions—even just facial expressions—that we were onto something. Previous client, in 2013, discussing The One Thing: “huh?” This team, in 2015, presented with The Two One Things: “oh! wow!”

In fact, this recent team took The Two One Things so deeply to heart, and they so reliably ask these two questions and only these two questions at every daily standup now, that they engaged the five-year-old son of one of the team members to create artistic representations of The Two One Things, which are displayed prominently in their team room and serve as a focal point and a daily affirmation of their awesome new habit!

Tragically, the images of Conner’s artwork were not captured by the Wayback Machine and have been lost.

The first only question to ask in your daily standup

The original One Thing and still the best.

“Are we on track?”

If you’re doing Scrum, you might ask, “are we on track to meet our commitment within our sprint?” (If you’re doing the new lame Scrum vocabulary, you might substitute forecast for commitment, except don’t do that, because it’s lame.)

If you’re doing Kanban, or something else continuous that doesn’t feature timeboxes or commitments, you still need goals, short- and long-term. So you might ask, “are we on track to meet our goal by our target?”

If your team doesn’t know what its goal is, don’t you think they might oughta?

The second only question to ask in your daily standup

The new, improved, Second One Thing.

I’m an adherent of Patrick Lencioni’s Death by Meeting: A Leadership Fable, in which he posits that the purpose of a meeting is to make a decision. One and only one decision! In this case, the purpose of the daily standup is for each team member to make this decision:

“What is the most valuable thing for me to do today?”

The One Thing, “are we on track?” is, of course, not a decision. But it satisfies the Death by Meeting Rule because we ask it in service of the decision. If the team is not on track, there’s a good chance that the most valuable thing for me to do today, to help us salvage and deliver as much value as we can, is something different than I expect. And that’s certainly the most valuable thing for us to talk about!

What’s really wrong with those three questions?

“Well, that’s fine in practice, but does it work in theory?”—Steven Borg

As I said in 2013, the traditional three questions (whether in their original or revised forms) focus the team on the wrong thing, and almost inevitably turn the daily standup into a status meeting. If you’re familiar with Principles of Product Development Flow by Donald Reinertsen (and you should be because it’s the sacred text of lean product development which is why agile even works, but I digress), you’ll recognize an important framework we can use to understand why the what-did-you-do-yesterday standup is so fundamentally flawed.

By orienting the daily standup around the people on the team, we’re emphasizing utilization. Utilization is the enemy of flow.

That’s certainly borne out by my frustrating experiences with the traditional three questions, which I watched team after team dutifully answer while simultaneously failing to even notice that their sprint was collapsing right in front of them—often literally in front of them, totally visible and obvious on their Kanban board!

By re-focusing The Only Two Questions around the work the team has undertaken to complete, we’re emphasizing delivery. This dovetails nicely with lean concepts, especially work in process, and it enables flow.

Even without formally introducing new terminology like “WIP limits” or “swarming,” we can point out that the most valuable thing for me to do today is to help get a near-complete item across the finish line. That’s true whether the sprint commitment is in peril or not!

A gentle reminder

Don’t forget: just because the team is all in one place at that time doesn’t make the daily standup an appropriate place for other announcements or discussion. If you really need to have a 15(+)-minute team meeting every single day for administrivia (hint: you don’t), by all means schedule one, but give it another name and hold it at a different time. Don’t hijack your standup.

And if members of the team want to collaborate together after the standup to solve a problem that arose during the standup, that’s awesome! collaboration is awesome! but don’t forget to let the uninvolved members of the team leave if they choose. Their most valuable thing to do today may be something different!

Do the two one things work for you?

Now that you have The Two One Things, and you can make your own awesome artistic renderings of them, how do you find your standups? Are they still boring? Do team members show up late and/or mentally check out during? How do you find your sprints? Are you catching problems early and salvaging more value delivery even when a sprint starts to go wrong?

Let me know what you try, and what you learn!

Unsolicited feedback and a pony: the view from inside an Agile2016 track team

Leave a reply

When I was a struggling aspiring speaker at the Agile Alliance‘s annual flagship conference, I was frustrated and wished they would tell me more about how to make my proposal conference-worthy. Now in my second year as a track team member, I understand better why they didn’t.

The conference

The Agile20nn conference has been happening, as best I can determine, since 2002 and today it’s one of the largest of its kind. Agile2016 in Atlanta will attract about 2,500 attendees and dozens (hundreds? not sure) of speakers and volunteers across 17 tracks. Size makes it easy to offer something for everyone. Managing an event at this scale is non-trivial!

The outside

I’m still waiting for the pony.

I made my first session proposals to Agile2014, and received pleasant form rejection letters at the end of the selection process. I was frustrated, and wished for several things: feedback to know why I hadn’t been chosen; coaching to improve the quality of my future proposals; and a pony.

The inside

As a track reviewer for Agile2015, I initially wanted to be more proactive about providing feedback to submitters, and I was confused and a little frustrated when program chairs and track chairs asked us not to. The good news was, they’d added a new Help queue/coaching option which allowed interested submitters to request more detailed guidance from dedicated volunteers. But I still didn’t understand why we were so strongly cautioned against providing feedback to submitters who hadn’t specifically asked for it. Why shouldn’t we offer to be helpful?

This year for Agile2016, I’m track co-chair for Leadership. Now I’m one of the big meanies asking my new track team volunteers not to give unsolicited feedback to submitters who don’t use the Help queue/coaching option. Based on last year’s experiences, I think I understand better why we don’t.

The numbers

I served on two tracks for Agile2015: Leadership, with 13 team members evaluating about 100 proposals, and Collaboration, Culture, and Teams, with 16 team members evaluating about 200 proposals. We try to ensure that at least 3 team members provide a detailed evaluation for each session. (Evals are private, shared only within the track team.) The majority of proposals come in right at the submission deadline, so it can be a scramble to get everything read and scored and evaluations written in the 4 weeks before our teams’ decision deadline.

Bottom line: sustainability. It’s really tempting to want to give detailed feedback early in the submission window, when proposals are coming in at a trickle and there’s plenty of time to read and ruminate. Later, as we get busier, we won’t have time to offer unsolicited help.

There’s an element of fairness as well, because if we give detailed unsolicited feedback to some submitters who haven’t asked, we really ought to give similar attention to all.

The quality

The entire submission system is open, so if you create an account you, yes you, can read all of the proposals that have been submitted to the Ready queue. I’m going to go out on a limb and suggest you’ll find that not all submitted proposals merit serious consideration. There’s a minimum quality bar that some don’t meet, and there’s evidence every year that some submitters didn’t read the instructions.

Bottom line: discretion. As a reviewer, honestly, if I think a proposal is irredeemably terrible, I don’t feel great about saying so to the submitter, and I’m not sure it’s a kindness for them to know when they haven’t asked.

Also, redundancy. When the submitter didn’t follow readily-available advice, there’s no sense in typing those same advices again, and certainly not if they haven’t asked.

The expectations

Each of my tracks ultimately approved just under 2 dozen sessions, out of 100 and 200 proposals. This means there are a great many proposals, even decent ones, that won’t be selected no matter what the submitter does.

Bottom line: realism. It doesn’t make sense to invest so much of our volunteers’ time giving feedback that wasn’t asked for and won’t change the outcome.

I also worry that unsolicited feedback would create incorrect expectations for the submitter—”if I do this I’ll be selected” or worse, “they must really like me”—and make them even more frustrated later when they still don’t make it.

The people

Track teams are made up of passionate human agilists, which means we have great diversity of opinion and often score the same session quite differently. The track teams’ selections are recommendations to the program team, who have the final say. There is no single person who knows the truth of why a proposal was or was not accepted, and there’s no single piece of feedback that could guarantee acceptance this time or next time or ever.

Bottom line: variability. To be meaningful, we couldn’t provide feedback from just one reviewer—we would need a diversity of opinions from a few reviewers, a track chair, and perhaps a member of the program team too! Now we’ve got conflicting feedback. What’s a submitter supposed to do with that?! And because track teams change every year, it might not be an accurate representation of what they should do next time.

The alternatives

If you care about becoming a speaker at this conference, there’s actually quite a bit of advice already out there, and there are some solid resources for you to help you give your proposal its best chance at success.

Read the program team’s guidance. All of it. Then read it again.
Read the provided sample successful proposal. Is yours as robust?
Choose your track thoughtfully. Read your track’s description and goals. In your proposal, clearly spell out how you align with those goals—don’t make the team guess.
Look through previous years’ successful proposals. Go to the submission system for past years, locate the Tracks page (Agile2015, Agile2014), select an individual track, scroll down to see the list of their accepted sessions for that year, and click any session to see its complete proposal—the published abstract and the submission-system-only program team info.
If you want help, ask for it! That’s what the Help queue is for. Use it!

I’m thinking about another blog post describing my submitter journey, and some of the other stuff I tried and figured out that helped my proposals. Stay tuned!

The One Thing: Successful Daily Standups

Leave a reply

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:

What did you do yesterday?
What will you do today?
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:

What did you accomplish yesterday?
What will you get done today?
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

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:

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

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

Kanban boards: physical or virtual?

Leave a reply

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!

TL;DR

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.

Features

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.

Avatars

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:

it takes < five minutes a day, and
team members can update their own items in both places as they complete them, and/or
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!

Engagement

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.

Conclusion

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?

Accidental credibility

Leave a reply

It isn’t accidental at all. I just accidentally forget I have it. Sometimes I get reminded.

I don’t read work books. Never have. (I read a lot; not for work.)

It took Steve, my semi-boss, voracious consumer of all information media (he still listens to podcasts!), whose photo should be in StrengthsFinder 2.0 under “Learner”, nearly two years to persuade me to read Getting Naked, our company’s raison d’incorporation. I finished it in about two hours, and it changed my life. I still don’t read work books.

Especially lately, this has caused me some consternation and discomfort when I show up at a client site (or Microsoft TechEd) to train and consult on enterprise agility. There’s always some smarty-pants in the group who reads work books. I don’t mean they heckle; they’re perfectly kind. But those innocent questions that expose that I have heard of such-and-such seminal work and I obviously don’t know what’s in it? Awkward.

And so, for example, I showed up at my latest client site to help tackle their problems with ineffective agile retrospectives. I brought a ziploc bag of Sharpies (hard to find in Europe for some reason), a stack of sticky notes, and a naïvely cheerful attitude. Imagine my dismay to find that several of the thought leaders in the organization were carrying around a book called Agile Retrospectives and wanted to know my thoughts on it. Oops. I’m pretty sure Steve has been trying to get me to look at that one.

In the true spirit of Getting Naked, I swallowed my pride and asked to borrow my client’s copy of Agile Retrospectives, and I read it poolside at my hotel overnight. Quick read, incredibly valuable insights, did I mention I don’t read work books?

Interestingly, when I skimmed some of the exercises in the book, I noticed that I’ve done and used several of them without knowing their names. Simple stuff that I hadn’t thought of as “exercises”, like having everyone write down their thoughts first in order to make sure the quiet ones get heard. It’s likely I picked them up from managers and colleagues—many of whom were surely Learners—and added them to my toolbox over the years.

This afternoon, as I departed my client’s office, the owner of Agile Retrospectives stopped by to thank us for our time with them, and because he’s awesome, to share some feedback. I didn’t expect what he said.

“The developers on our team, when they heard a consultant was coming to train them on agile, they were expecting—well, it seems like anybody can read four books and say they’re a consultant. But the books don’t take real life into account, and the books make everything sound so easy.

“You’re different. You have fifteen years’ experience as a programmer, and it shows. They were really surprised. You created a lot of trust, because they know that you know what you’re talking about.”

Praise doesn’t get any higher than that. Here I was preoccupied with embarrassment that my clients—many of whom are in fact Learners—might be judging me because they’re so much better-read than I. In reality, what I have to offer is so second-nature to me that I sometimes forget everybody else doesn’t have it or know it already.

I’m not saying I don’t need to read a bit more. I clearly do. But I’m never going to be voracious with the work books, and I’m always going to encounter clients who naturally read work-circles around me. What I realize now is, neither one of those is a bad thing. I have skills and knowledge that clients need me for, and I need their skills and knowledge, too. Those motivated Learners will be the ones to help keep enterprise agility going long after their consultant has moved on!

Our complementary strengths are what makes us a great team. It’s what I teach to them. Let’s see if I can teach it to myself. :)

I spoke at TechEd!

Leave a reply

Pre-conference seminar #12, “Enterprise Agility Is Not an Oxymoron”, all day on the Monday, in Madrid, BY MYSELF. That’s right, no Steve-shaped security blanket.

The worst part about giving the same pre-con twice with different speakers is having to compare the (insanely competitive) speaker and session rankings afterward. The good news is, I did OK! by myself. Not amazingly great like we did together at North America, but genuinely OK!

If you’re interested in learning more about how I teach Enterprise Agility, check out my Events page for upcoming webcasts and live workshops, or contact Northwest Cadence to request one. Cheers!

I’m speaking at TechEd!

Leave a reply

Pre-conference seminar #12, “Enterprise Agility Is Not an Oxymoron”, all day tomorrow (Sunday).

I don’t know which is more terrifying: that, or Speaker Idol, which I foolishly agreed to enter which starts Monday at lunchtime.

Either way, wish me luck… and if you’re here, come say hi!

Care and feeding of your T-shaped individuals

2 Replies

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

Leave a reply

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.

Vertical slices and SOA

Leave a reply

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.