The Daily Question

You start your sprint thinking you can get the work done.  But as soon as the sprint starts, new information comes your way: stories are harder than expected, someone is out sick, a blizzard knocks a day out of your team’s schedule, etc.

When do you deal with this new information? Daily standup.

Standup is of course a chance to commit to each other what you will accomplish during the day.  But it is also a chance to replan the rest of your sprint as necessary.  From the Scrum Guide:

Every day, the Development Team should understand how it intends to work together as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment by the end of the Sprint.

Part of that is answering: are we still on track? If not, what are we going to do about it? Unfortunately, I have found that teams don’t do this naturally. Here is the best trick I’ve found for building and maintaining this important habit:

• At the end of every standup, ask this question: On a scale of 1-5, how confident are you that–as a team–you will complete the Sprint Goal by the end of the sprint?
• Count 3-2-1 and then everyone vote with their fingers (5=very confident)
• If anyone votes 3 or lower:
  • Ask the voter: Why are you concerned?
  • Ask the team: What can we as a team do to get this back on track?
• Repeat this for anyone else who voted 3 or lower.

In my experience, the hardest part about this is just asking the question.  Teams naturally leap into action trying to help each other and problem solve; they just need the information brought to the surface.  The voting takes virtually no time, and it forces the team members to look from the team/sprint perspective as opposed to the me/today perspective.

I now recommend this practice for every team, old and new.  I hope it helps your team!

---

A few other things:

1. This doesn’t work very well if you start mid-sprint.  It’s actually best if you ask the question before closing sprint planning, to ensure that you are actually starting your sprint from a position of confidences (4s and 5s).
2. If you aren’t using Sprint Goals, change the question to ask whether you will complete all stories by the end of the sprint.
3. Here’s a PDF of the daily question you can print and put on your team’s scrum board as a reminder.

Advertisements

When OKRs Attack: A Framework for Reviewing OKR Problems

You may have heard the reminder that the daily stand-up meeting in Scrum is not a status meeting, it’s a commitment meeting.  It’s a chance to pick a focus for the day, share it with your team, and push everything else to the side.  I like to think of it as giving yourself the gift of focus.

A few years ago, I was reflecting on failures with my own personal daily commitments.  Thought I wasn’t on a scrum team, I was setting out my tasks at the start of each day.  Rather than saying them out loud to my team, I wrote them down.  I found a few frequently recurring categories of problems.  Later, doing retrospectives on OKRs, I was reminded of these categories.  The timescale was different, but the problems were largely the same.

There are seven categories.  The first six are typical problems that trip us all up, especially in the first two to three quarters of OKR adoption.  Once we can routinely manage those six hurdles, we run into the seventh, which is a catch-all: execution.  It’s a good thing when your main failures (if any) come from execution.  It means you have made routine of evading those other pitfalls, and you can dive into fine-tuning your performance.

Sometimes you will fall short of a commitment for a combination of these reasons.  The value of this framework is not in perfectly assessing which category was to blame; it’s in helping you pick apart what could otherwise be a confusing jumble of conflated problems.  Do your best to pinpoint the biggest reason you failed to hit each Key Result, consider what you would have done differently if you could do it again, and keep this in mind as you head into your next set of OKRs

Underestimation
The work was bigger than you expected.

• Examples:
  • A known step took longer than expected.
  • You discovered unknown steps along the way.
• Remedies:
  • Roughly plan the sequence of events for quarter.  Backwards planning can be good here.  Careful not to overdo it.  If you do, it will be harder to respond to new information as it comes.  Even if you manage to throw away your plans when things change, you will have lost that planning time forever.  So keep the planning rough/high-level.
  • Do more up-front risk/dependency analysis.
  • Write outcome-based OKRs that give you more latitude to adjust.

Overcommitment
The work was about what you expected, you simply took on more than you could possibly achieve.  We all do this.  Remember: there is no virtue in taking on more than you can possibly accomplish.

• Examples:
  • Too many OKRs.
  • OKRs too big/ambitious.
• Remedies:
  • Don’t overcommit!  Easier said than done, of course.  But if you have 2-3 straight quarters of data telling you that you took on too much, it will be a little easier.

Blocks
You felt unable to proceed at some point.

• Examples:
  • Had to wait 5 wks for department X to send material.
  • Development environment databases down for five days.
• Remedies:
  • Is the block really, completely out of your control? We often take too passive a stance in response to blocks.  Don’t let them defeat you!  What have you tried? Could you have acted sooner or gone further?  Could you have escalated or sought other assistance to unblock yourself?
  • Before the quarter starts, take ownership of identifying all critical needs and gaining commitment from others on meeting them.
  • Write outcome-based OKRs that give you more latitude to adjust.

Distractions
You focused on something other than the OKRs you set.  Death from a thousand cuts of distraction is one of the most common problems, and one of the hardest to avoid.

• Examples:
  • Prioritized other work over OKRs.  This often happens unconsciously: something else comes up, and you do it without considering the negative impact on your prior commitments.
  • Went an extra mile on a given OKR.  Going the extra mile is often seen as a good thing, but you have to consider the impact of that extra work on other priorities.  Remember that every choice to do something is also a choice not to do something else.
• Remedies:
  • Strictly check impact on OKRs whenever other work shows up.  Will doing the work jeopardize your chance of success with OKRs?  If so, is it higher priority than the OKRs?  If so, what is the likely impact on your OKRs?  Share that that impact with all stakeholders before proceeding.
  • If you’re about to make give something an extra touch, ask yourself what impact it has on other OKRs. If you are taking extra time, it has to come from somewhere!

Poorly Written OKRs
OKRs were too task-oriented or too vague about what done would look like.

• Examples:
  • I finished the task-oriented Key Results, but missed the spirit of the objective.
  • Partway through the quarter, I abandoned the Key Results because I realized it was the wrong approach.
  • I had Key Results like “Start initiative X” or “Make progress on project Z”.
• Remedies
  • Remember: Key Results aren’t what you do (tasks/outputs); they are what happens as a result of what you do (outcomes).
  • Remember: Key Results show what you will finish, not what you will start.
  • When setting a Key Result, imagine yourself scoring it at the end of the period.  Will it be easy to tell whether or not the work is done?  If not, rewrite the Key Result with a more definitive finish line.

Mid-Quarter OKR Change
If at all possible, you should avoid doing this.  But sometimes you have no choice. Two examples:

• A new demand appears out of the blue, taking priority over your OKR.  A big demand, not a dentist’s appointment.
• After some progress, you learned that the entire OKR should be scrapped.  Could be due to a change in the business environment, a major technical miscalculation, etc.

If you must make such a change, clear it with all stakeholders first.  Then, at the end of the quarter, make sure you look back to figure out what happened and how to avoid such changes in the future. If this happens to you more than once or twice a year, you definitely need to re-examine what’s going on.

Execution
If the problem is not in one of the six categories above, congratulations! You’ve avoided the common pitfalls.  You are likely operating with a much higher degree of focus and alignment than you were before adopting OKRs.  But the work continues: without the confusion of those common pitfalls, you can now start fine-tuning your approach to maximize achievement of your outcomes.  Good luck!

Up Periscope!

“Inspect and adapt” is a key phrase in Scrum.  Many parts of the framework ask you periodically to check in on something, see how its going, and modify your next steps as appropriate.  One of the inspect-and-adapt meetings is Sprint Review, where you inspect the product increment (Scrum’s fancy way of saying “what you built in the last sprint”).  There are a bunch of important things to check, but here I’d like to focus on this one:

• How are we doing toward our longer-term goals?

During sprints, we are cruising along, focused on the details in front of us.  It’s incredibly important to look up from what you are doing and make sure you are still headed where you meant to go.

Here is one particularly effective way I’ve found to connect this inspection question to adaptive actions.  It assumes that you are using OKRs (Objectives and Key Results) set on quarters, but you can easily swap in whatever mechanism/time period you are using to set goals beyond those of the sprint.

1. Bring up the OKRs on a shared screen.
2. Read out the first key result.
3. Ask the question: “Are we on track to complete this key result by the end of the quarter?” If people aren’t ready to vote, discuss.  Otherwise, on the count of three, everyone votes as follows:
   • Thumbs up = Green: We are on track.
   • Thumbs sideways = Yellow: We think we will complete this, but we have some definite risks
   • Thumbs down = Red: At present, it doesn’t look like we will complete this.
4. Discuss differences between the votes.  Revote as necessary.  Once you have a consensus, if the consensus is yellow or red, discuss two follow-up questions:
   • Why is it yellow/red?
   • What specific actions can we take to get it back to green?
   • Write the answers somewhere everyone can see.
5. Repeat until you’ve gone through all key results.  (Note: I don’t find it as useful to do this for the objectives, but if you want to do that, knock yourself out!)

A few common questions about this technique appear below.

If we’re behind, can we really afford the time to have a conversation about risk?
A frequent mistake is to stop after step 3 and say, “Oh, boy, we’re in trouble! We’d better get back to work!” It’s very tempting to do this!  You just identified that you are behind, and it is counterintuitive to think that the right action is to not jump right back to work.  Think of it this way instead: you have identified that you are on a course to failure; why rush getting back on that course?  Instead, take a moment to look at the risk in more detail as noted in step 4.

Why write the answers about risk somewhere everyone can see?
As a general rule, it’s a great practice to record the conclusions of a conversation in a shared place.  It greatly reduces the risk that participants come away with different memories of the conversation.  In addition, you can refer back to it, and if you make it fully public it can help communicate status to people outside the team.

How detailed should my answers be?
Only as detailed as is useful for your team. For example, you might write something as simple as: “Concern over content being ready for us in time. Juniper escalating to Max.”

What’s the Hippopotamus?

Me: I think the big bites can burn your mouth more than small bites, because there are more molecules–those little balls bouncing around–that can bump into your mouth and warm it up than there would be in a smaller bite. At least, that’s my guess.

My young daughter: That’s your hippopotamus?

Me: Yes.  That’s my hippopotamus.

In my last post, I wrote that teams past the prototypical startup phase should still use the approach of validating hypotheses, highlighted in Eric Ries’ The Lean Startup.  I left off with the question: where should teams find hypotheses to test?  See the answer in my full post on the Amplify Engineering blog.

 

The Lean Grownup

Eric Ries’ The Lean Startup holds a lot of great advice for prototypical startups, as well as for innovation efforts within more established companies.  But some on more established teams might think this book has nothing for them.  I suggest they think again! Although a couple of the lessons are a little less applicable later in the product lifecycle, much of the core thinking of Ries’ book is not only still usable, but crucial to understand.

I explain why in my full post on the Amplify Engineering blog.

Measurement Patterns for OKRs

In writing key results for OKRs (or generally trying to find measurable goals), I have noticed several patterns of measurement.  I find this list useful when I am trying to brainstorm ways to measure a given initiative.  I can ask myself, “Hmm, is there a Symptom measure I could use here?”  Gives the imagination a little kick.  This is especially useful when I am stuck with a bunch of output-based key results and I am trying to convert to something outcome-based.  Will post more about that later; for now: it’s basically about trying to avoid the trap of measuring what’s easy to measure as opposed to what’s important to measure.

• Milestone
  • Binary result; you do it or you don’t.
  • Example: Achieved XyZAB Certification.
• Metric
  • You change some measure by some amount.
  • Example: Sales up 35% over same quarter last year.
• Pioneer
  • You do the first of something, forcing you to learn and solve problems along the way.
  • Especially useful when you are moving into a whole new area.  Lays groundwork for future work.
  • Example: Produced first Department podcast.
• Canary in the Coalmine
  • You measure the whole by measuring a predictable outlier.
  • Example: Perennially dissatisfied customer said some form of “very happy”.
• Symptom
  • You measure the true (and difficult-to-measure) outcome you actually want by detecting a symptom it creates.
  • Example: true outcome is “increase customer knowledge of topic x”; symptom-style measurement is “20% fewer help desk calls on topic x”.
• Stepping Stone
  • You believe that by achieving a given result, your true outcome will follow.
  • Especially good for cases where the outcome significantly lags the work you do.
  • Example: true outcome is “people enter key data in SalesForce”. You believe they don’t because your SalesForce implementation is a clutter of unnecessary fields. Stepping-stone style measurement is “Number of SalesForce fields cut in half”, based on the theory that sometime after the cycle, people will as a result start using SalesForce more regularly.
• Straight Face
  • You make an assertion that you cannot currently say with a straight face.  Your goal is to get to the point where you can say it with a straight face.
  • Good where quantitative measures are impossible.  However, it’s squishy.  Use with caution.
  • Example: I am in good shape.

Agile & OKRs: Achieving Harmony

I just gave a talk at AgileDC 2016 about my experience over the last year implementing OKRs for a bunch of Agile teams.  For now, this post is just a placeholder for the presentation.  When I get around to it, I may fill out the posts with the relevant thinking.

AgileDC 2016 Presentation: OKRs & Agile: Achieving Harmony

Resistance is in the Eye of the Beholder

Before I start, I have to give credit to Esther Derby for nearly 100% of the value of this post. She does a free (free!!) monthly Q& A conference call.  During one such call a little over a year ago (“Reframing Resistance for Positive Outcomes”), she opened my eyes on a critical point.  Here’s the very first sentence of Esther’s discussion that day (not verbatim, but close): What resistance really means, if you look beyond the frustration, is a person not going along with your suggestion as enthusiastically or quickly as you would like.

Just this sentence sparked a major perspective shift for me.  The last four words put attention on the part the initiator of the change plays in the feeling of resistance.   Think of it like Newton’s third law: if I punch someone in the face, their face pushes back on my hand.  My hand might really hurt, but would it be fair of me to think ill of them for pushing back on my knuckles with their cheek?  I’m obviously heightening my role as aggressor in this situation, but even in this extreme example, I might have good intentions (e.g., it looked to me like they were about to hurt my friend).  Regardless: I took part in creating the pain I felt in my hand.

While this analogy is silly in some ways, I really like that it highlights something huge that I used to overlook when complaining about resistance: how does the other person feel about it?  Just as focusing on the pain in my hand is unfairly ignoring the pain in the other person’s cheek, complaining of resistance is ignoring the position that I have put the other person in.  They very likely don’t like pushing back, but I am forcing them to do so.  (Of course, they have the option of just giving in, but neither of us does well in that outcome.)

Esther went on to cover some very useful techniques for working through how to approach perceived resistance.  These techniques both involved shifting ones perspective: in one case re-framing the perceived resistance to find its potentially positive components, in the other case seeking an understanding of the other person’s perspective.  Doing the exercises really drove home the truth of her opening statement. Every example of resistance I could think of fit that definition.

One might consider this massive self-deception: if I always slide around to the other person’s perspective, am I simply explaining away resistance that actually exists?  Well, if my interest lies with progress that respects people for who they are, and if understanding their view helps me achieve progress, I don’t think I really care.  Regardless, I truly have come to believe that–in all but very rare cases (e.g., deep personal animus)–resistance is just one’s own view of the feelings one creates by pushing on someone else too fast, too hard, or too insensitively.

The tools Esther shared that day are great, but the really cool thing she did was helping me see the futility in fussing over so-called resistance.  Since then, I’ve stopped using the word in this context.  That’s a pretty damned good result for a free Q&A call.  Thank you, Esther!!

Re-Organizational Agility

At the beginning of this year, I had a discussion with some folks at various companies about organizational issues at scale. At one point we touched on our individual experiences with high-level company re-organizations. As we went around the circle talking about frequency of change, we learned that the represented companies re-organized about once every 18 to 36 months. This struck me as interesting because the language typically used to communicate such changes not only fails to communicate predictable fluidity, but on the contrary implies permanence. I don’t recall explicit claims of permanence, but the old ways are usually cast as simply wrong, the new ways as the solution to a problem. Not one of the many re-orgs I’ve been through is billed as what it truly is: an approach aimed at solving current problems, which is therefore likely to cease being useful when the primary problems change.

In the call, I suggested the idea that the architects of such re-orgs might recognize this and take a different approach. I’ve thought about it a lot since then, in part sparking my thoughts on all management as a support function. If you accept that management serves a support function, it follows that management should constantly adjust to the needs of the org it supports. How would this in turn change the periodic re-org?

I imagine that announcements would make clear that re-orgs are explicitly temporary attempts to respond to the current set of support needs. To prepare for future re-orgs, management could establish an ongoing process to assess the fit of management structure to needs. I think of this as a sort of product in development. Just as the Product Owner attempts to fit a product to the needs of their customers, the Re-Org Owner would attempt to fit their product (management) to the needs of their customers (development teams). As with product release, you could then adjust the frequency and breadth of release to get the appropriate level of feedback on your changes. In any event, you would work to move away from the typical pattern: big announcement, months of figuring out what it means, months of learning to do it, months of learning the problems with it, months of attempting to fix those problems, and finally abandonment for the next approach. This would help de-emphasize any sense of permanence in the re-org. In turn, this would hopefully help defuse a typical response to many of these re-org announcements: “Humpph. More management bullshit.”

It’s possible that this thinking just flows from my bias towards typical Agile team structure. What I’ve observed, though, is that the structure of those teams rarely seems to change based on the high-level re-orgs. In short: the small team structure seems to work more or less indefinitely; you just need to modify the support structure around it to adjust to changes over time.

Regardless, there doesn’t seem to be much here that is too controversial: Why not just be honest that things are going to change again? Why not be thinking ahead about the next re-org to avoid waiting too long and starting too jarringly? Why not try out those changes in smaller measure to validate your decisions?

Thanks to Simon Marcus, Anders Ivarsson, Mac Fowler, and Erik Schon for the very interesting conversation that inspired this thinking!

Inverting the Org Chart

“Hierarchies evolve from the lowest level up…The original purpose of
a hierarchy is always to help its originating subsystems do their jobs better.”
—Thinking in Systems: A Primer, Donella Meadows

You and your friend Kelly have an idea for an internet application. You dream it could be the next big thing. You’re a code wizard and Kelly’s good at telling a story. You gather enough money to get started, find a couple of like-minded builders, and dive in.

You decide to use Scrum, because that worked pretty well for you in your old shop. Kelly is the obvious choice for Product Owner, and you act as Scrum Master. Both of you still actively write code.

Things start going pretty well. You have enough users to attract investors, and the app starts to expand. As it does, your team of four grows to six, then seven, and then jumps to 12. You have plenty of work, and great talent to do it, but the team is getting too big, so you split into two development teams. One of the team members has a knack for keeping the team focused and engaged with each other, so she takes on the SM role for the other team.

Kelly does okay for a while as PO for both teams, but as the teams start to grow further, it gets to be too much. The two of you barely touch code any more. There are greater dealings with investors, payroll is getting to be a real burden, and there is less and less time for focusing on vision. You decide to hire an office manager to deal with daily overhead. Under Kelly’s mentorship, two new POs will guide the teams. Kelly officially becomes CEO and shifts primary focus to higher-level, longer-term strategy. You become CTO, mentoring the senior members of the teams.

You can imagine how this continues. As you continue to add members to the development teams, you continually need to add people to handle work that you used to be able to spread through the team. In a small organization, people can handle these functions themselves. As you grow, it becomes inefficient to spread those functions across everyone, requiring consolidation of the functions under specific people in new roles.

You didn’t need a CEO and CTO when there were four of you. You may have worn that badge, but it was just your specialty within the team. You only needed to spin off management as its own role when the company grew.  You spun off other things typically referred to as support functions–HR, facilities, IT, administrative assistance.  Is management any less of a support function?  The vision, strategy, and leadership they provide are sexier than the stickies, coffee, and toilet washing handled by other support roles, but they are nonetheless things that the teams need to get their work done.  I call that support.

Put differently: management exists to support the managed. Shouldn’t org charts then look like this?

Am I just quibbling? A little. But it’s interesting that org chart templates don’t even provide this as an option.  To build the above, I couldn’t use the Visio template, because it assumed that an Executive square had to be above a Director square.  The arrows came out all wrong.  Maybe always looking at the image with the CEO at the top affects our perception?  In the physical world, supporting something is usually associated with holding something up from below.  Looking at the typical org chart, then, who is supporting whom?

One might worry that the inverted pyramid would give management big heads: “I support the whole company!” Well, if they are actually operating from a position of servant leadership and effectively supporting the whole company, then I say they deserve big heads. They also probably deserve the big salaries, because effective servant leadership is a rare skill that takes enormous effort to refine. Regardless, I prefer Atlas-like claims to the image standard org charts promote: monarchy carried on the shoulders of those below.

To be honest, I think the org chart should depart from pyramidal hierarchy altogether to represent the symbiotic organism it is intended to model, but flipping it upside down is a start. If we invert it, what shifts in our mindset?

Note: the later post Re-Organizational Agility discusses one change this might yield.

Update: I completely forgot a very important credit!  The thinking in this post was sparked by the Meadows quote above.  It’s especially embarrassing given that its only correct placement is right at the top of the post.  My apologies for the oversight.