Sprint Planning start well, end better.

Posted on July 18, 2023 by Silverback

Photo Credit: Pixabay- WOKANDAPIX

“Plans are worthless, but planning is everything.”
Dwight D. Eisenhower

Has any of this happened to your Scrum Team?

The team regularly takes on more work than they can complete in a Sprint.
Work is removed from the Sprint because it could not be completed.
The quality of the final work is low, with many issues found after the Sprint.
Stories grow in size during the Sprint as more work is discovered.
Arguments erupt on the right approach to getting work done.
Sprints looked successful, only to have the stakeholders say it doesn’t meet business needs.

These challenges and more can be traced back to poor Sprint Planning.

The Basics of Sprint Planning

Sprint Planning marks the start of each Sprint. It sets the overall tone for Sprint. Good Sprint Planning leads to a good Sprint. A Sprint that doesn’t generate value is creating waste.

Let’s start with a quick primer on the five Ws of Sprint Planning:

What? (Definition)	A planning event to create the Sprint Backlog, which answers the questions: “Why are we doing the Sprint?”, “What work will be done?” and “How will the work be done?”.
Why? (Purpose)	To create alignment on the purpose and work needed to deliver on the Sprint Goal.
When?	Sprint Planning is the first event inside the container event of the Sprint. The Sprint starts when Sprint Planning begins.
Who?	The Product OwnerThe DevelopersThe Scrum MasterStakeholders and SMEs as needed
How long?	Two hours per week of Sprint

Now we’ll unpack some of these to understand better and learn how not doing them could impact your Sprint…

Unpacking Sprint Planning

Why do we do Sprint Planning?

We do Sprint Planning to create alignment and purpose around the Why, What, and How of Sprint Planning.

Why is it valuable? (Creating the Sprint Goal.)
What can be done in the Sprint? (Populating the Sprint Backlog.)
How will the chosen work get done? (Breaking down the work)

If we don’t answer all three questions, we don’t have true transparency of the work and how it connects to the whole.

The most common places I see Sprint Planning, and by extension the Sprint, fail is with the Why and the How parts of Sprint Planning.

There is no Why: No Sprint Goal.

The Scrum Guide defines the Sprint Goal as “the single objective for the Sprint.” To this definition, I add it is “a concrete stepping stone towards the Product Goal.”

If your Sprint Goal does not connect to your Product Goal, then you are not “maximizing the value of the product resulting from the work of the Scrum Team.” Without value, you can’t be profitable. Without profitability, you can’t be a sustainable business.

Defining a Sprint Goal at the beginning of Sprint Planning is critical. Defining the goal upfront allows all the work pulled into the Sprint to support the Sprint Goal, enabling the output and outcome of the Sprint to contribute towards the Product Goal.

There is no How: The work is not understood.

One of the reasons for Sprint Planning is to create alignment between the Product Owner and Developers. Alignment is not just between the Product Owner and the Developers. It is also between the Developers. Does the database expert know how the business logic person will implement their work? Is everyone clear on how the end product will be tested? How will we demonstrate this? If the team is not asking these questions in Sprint Planning, you are headed for rocky waters.

Who attends?

Many Agile teams treat the Events like secret Star Chamber meetings requiring a password to enter. Scrum works on the fundamental pillar of Transparency. Without transparency, everything else in Scrum will suffer and eventually fail.

With Sprint Planning, transparency is essential as it is the last chance to refine and understand the team’s work in the Sprint. Inviting the business stakeholder to provide greater context, or the Architect, to work through some design questions can be the difference between a Sprint Review where everyone says, “That was awesome!” and one where you hear, “That’s not what I wanted” or “You realize that’s not security compliant and you need to redo it?”

How long?

The Scrum Guide says:

“Sprint Planning is timeboxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.”

Eight hours? That’s an entire day! Are you serious?

Let’s do a little math here. A one-month Sprint is, on average, 20 days or 160 hours. Eight hours is just five percent of the total time of the Sprint. Five percent!

Now let’s look at a typical waterfall project. Twenty years ago, the projects I managed were typically 12 months long. The first three months of that project were back and forth between product management and development on precisely what would be built with no code being written (for this release) for at least two months. Plus, the product managers had previously written requirements documents for at least two months.

Twelve months, with two months spent in “planning.” That’s 16 percent of the release spent on planning. And let’s be honest, that’s probably on the low side by a generous margin.

So, yes, two hours per week of Sprint is not only reasonable, it’s responsible. We’ve already looked at the two common failure patterns above. Lack of sufficient time is not only our third failure pattern, it also causes the first two.

And let’s remember; the Scrum Guide says “a maximum of.” If the team finishes before the timebox, no one will complain and demand you all stay until the timebox ends. Schedule the time so you have it. Nothing is worse than having a two-hour meeting and finding out you needed two hours and fifteen minutes.

In the next section, I’ll show you my agenda for a two-week Sprint.

Agenda for an Effective Sprint Planning Event

The following is a recommended agenda flow for a two-week Sprint and has a four-hour schedule.

Phase	Activity	Timebox
Set the Stage	Welcome attendees and set expectations	~5 min
Why	The Product Owner describes a possible Sprint Goal and then discusses it with the Scrum Team	~10-20 min
What	Final Refinement and Estimation occur on Product Backlog Items (aka stories) that the Product Owner desires for the Sprint	~15-45 Min
What	The team reviews their availability and past performance to determine their potential capacity for the Sprint	~10-15 Min
What	Populate the Sprint Backlog with the Product Backlog Items that will meet the Sprint Goal	~15-30 Min
How	The Developers plan how they will complete the items in the Sprint Backlog	~2 hrs
Close	Take a final confidence vote, thank the team, and end	~5 min

1. Set the Stage: In their book Agile Retrospectives, Esther Derby and Diana Larsen say, “Setting the stage helps people focus on the work at hand. It reiterates the goal for the time the team has together in the retrospective.” The above is good advice for all the Scrum Events, and I start Sprint Planning by thanking everyone for their time and reminding them of the purpose of Sprint Planning.

2. Establish a Sprint Goal: We’ve already discussed how failure to create a Sprint Goal or even creating a Sprint Goal after deciding what to do is one of the top reasons Sprints fail. If Sprint Planning sets the tone for the Sprint, the Sprint Goal sets the tone for the planning.

The Product Owner should come prepared with a recommended Sprint Goal. This Sprint Goal can result from the Sprint Review the day before or based on other strategic work. To be effective, the Sprint Goal connects directly to the Product Goal. The team then discusses, refines, or changes the Sprint Goal.

3. Final Refinement and Estimation: You should already be doing regular Backlog Refinement to keep your Product Backlog topped off with regular work. That said, Sprint Planning is the “last responsible moment” to do refinement. Check out the Scrum Alliance article linked above for more on Refinement.

Generally, I see three kinds of refinement happening during Sprint Planning. From most common to least, they are:

Reestimation of work
Updated Acceptance Criteria
New, usually urgent, work

Reestimation can happen at any point up to when the team starts working on the item. Say that the last refinement session was the Thursday before. Since then, Sunil has been rummaging around the data layer and has discovered several new connections to other processes. Sunil returns to the team and says, “I think we underestimated the complexity.” The estimate for the item could change right there in Sprint Planning.

Acceptance criteria are how the Product Owner can shape the value of the work. The PO may want the new login page to be 25% faster than the last one. Martha has been looking left, right, and sideways at the code, and she doesn’t think the team can squeeze more than 15% out of the current system. The PO then decides if getting the new login page now is more important than getting it to load faster. The PO wisely decides now is better and agrees to change the AC to a 10% improvement.

And finally, remember that the Product Backlog is dynamic and emergent. New items can shoot to the top of the backlog overnight. The Product Owner may bring a brand new item to the team and ask them, “Can we refine this and include it in this Sprint?” While this should be uncommon, it should also be possible.

4. Determine Sprint Capacity: How much work can the team do on average? Will anything impact the team’s ability to work this Sprint? A great example is what to do when a major holiday falls in the Sprint. Instead of the team shortening the Sprint, they consider how this will impact them. If the entire office shuts down for a week, then the team’s capacity is 50% of what their velocity says they can do.

5. Populate the Sprint Backlog: Once you have a capacity guide for the Sprint, the team can fill the Sprint Backlog with work that supports the Sprint Goal. There are many ways to do this. Just remember that the Developers pull work into the Sprint. The Product Owner decides if the work to do has value and contributes to the Sprint Goal; the Developers decide how much work they can do in a given Sprint.

6. The Developers plan how they will complete the items in the Sprint Backlog: This is the most frequently forgotten — and therefore problematic — part of Sprint Planning.

Here’s how I explain this to students:

“When Sprint Planning starts, you are coding! Not all coding is hands-on keyboard typing. There is whiteboarding, design conversations, coordination, and more.”

If the developers need to look at the code to determine how they will build something, then look at the code. Scrum Masters, this is one of the places you are most needed. Ask questions, and seek clarity. Does the team understand what they will do, or are they planning to “just figure it out as we go?” That’s not Agile; that’s just lazy.

The How phase is the most time-consuming part of Sprint Planning. Done well, it prevents rework and conflicts (people, process, and product). It allows for a greater chance the team will deliver a usable increment of value (AKA done work the customer cares about) at the end of the Sprint.

Here are some things Developers should be doing in Sprint Planning:

Break work down “into smaller, more precise items.”
- AKA create individual tasks that represent the technical work needed to complete the Product Backlog Item. (UI work, DB work, code review, create automation tests, etc.)
Whiteboarding the design
Sketch the user interface
Review existing code
Anything required to plan how to complete the work

Breaking work into tasks is vitally important and should never be pushed out with a “we’ll figure it out later.” Tasking allows for:

Remembering the work: Five days from now, will you remember what you discussed in the Sprint Planning meeting? And if you didn’t even talk about it at Sprint Planning, do you remember when you did talk about it?
Alignment: How will the UI work fit into the Business Logic work?
Track Progress: If you break work into tasks of no more than four hours, your burn-down charts will reflect progress toward the Sprint Goal more accurately.
Create stronger teams: When the team breaks work into bite-size pieces, it often allows someone with less skill to pick it up and complete it. This benefits the team in creating more cross-functional members and benefits the individual who gets to improve their mastery.

The Product Owner during the How

What does the Product Owner do during the How part of Sprint Planning? Unfortunately, the typical pattern is “See you all later; let me know how it goes.”

“The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team.”

– The Scrum Guide.

The work is still all about value. If the Product Owner isn’t present, important questions might go unanswered, acceptance criteria can’t be tweaked, and problems not detected until too late.

The PO should be present and available. Their presence will ensure a continued alignment to value.

7. Close: Closing can be an under-appreciated part of good Sprint Planning. In Agile Retrospectives, the authors say, “End the retrospective decisively: don’t let people (and their energy) dribble away.”

Remember the maximum timebox. If the team is still going strong at three hours and fifty minutes, the Scrum Master can ask the team what’s needed to wrap up. Maybe they didn’t get all the work planned out. What will they do about that? Do they need to de-commit some work before the Sprint starts?

One of the things to do here is to collect a confidence vote. Now that the Developers have planned the work, how confident are they that they can complete it all in the Sprint?

Using the Fist to Five consensus framework is an excellent way to check on confidence.

Working with multiple teams

What happens when a Product Owner is supporting multiple teams? This is not immediately a bad thing. The Scrum Guide even has a suggestion:

“If Scrum Teams become too large, they should consider reorganizing into multiple cohesive Scrum Teams, each focused on the same product. Therefore, they should share the same Product Goal, Product Backlog, and Product Owner.”

The critical point here is that to be effective, the Product Owner must only have one Product Goal at a time. The next question will be, “How many teams can one Product Owner support?”.

My answer is 2

There are other answers and arguments, and we’re stepping into scaling conversations now. My experience is that a Product Owner becomes exponentially less effective beyond two teams. Once you move to four teams, you need to insert a scaling practice to have someone focused on the longer term while Product Owners continue to be sleeves rolled up and engaged with no more than two teams.

In practice, the way I’ve coached Product Owners supporting two teams is as follows:

Shared Backlog Refinement
- Not everyone has to be in refinement sessions. Ensure you have representation from both teams and that all skills needed to complete are represented.
Shared Why and What Sprint Planning
- This allows alignment, horse trading of work, managing dependency, and more.
Individual How
- Do these at the same time with the PO floating between both teams.
Individual Daily Scrums
- Stagger them so the PO can go to both
- A representative from each team should go to the other Daily Scrum
Individual Retrospectives
- The PO rotates attendance every Sprint
- Every quarter or so, do a combined retro on overall ways of working.

A good Sprint Planning Event creates Value and Quality

The concept of “Starting on the right foot” is not just a trite saying. If you want to improve the quality of your work, improve the quality of your Sprint Planning.

Metrics: Third Rail of Agile Adoption

Posted on August 28, 2017 by Silverback

“Am I good or what?” The question was, of course, rhetorical, I was alone in my office. I

Photo Courtesy of: https://www.flickr.com/photos/bike/

couldn’t help it though, I was pleased as punch and nothing was going to ruin my great mood.

“Or what?…”

Not even an 800-pound invisible gorilla.

“Go away, Hogarth, you can’t ruin my mood today. I’m on top of the world.”

Ignoring me, Hogarth ambled into my office. Spotting my new fichus, he plopped himself down and tore a branch from the tree. Around a mouthful of leaves, he asked: “So, agile adoption going well?”

His question instantly dispelled my annoyance at his assault on my plant. “Yes, yes it is.” I turned the monitor around so he could see. “Just look at these velocity trends! Every team is hitting or exceeding their velocity targets and we’re only three sprints in. It’s absolutely fantastic!”

Hogarth leaned in and intently studied the flat screen display. “Impressive. That’s got to be one of the fastest velocity growths I’ve ever seen. What did you do differently this time?”

“Hey, I’m just good. Awesome training, great coaching. Oh, and I bet the incentive program really helped out.”

Hogarth cocked his head to the side, “Incentive program?”

I leaned back smugly, “Oh, yeah. If the teams hit the velocity goals then they get a cash bonus and we’re going to hold a huge party at Humdingers Resort.”

Hogarth nodded, making some appreciative sounding grunts. I’d finally gotten to him. He was speechless.

After a long gaze at the monitor, he turned to me and gave one of his brilliant white smiles. “Sounds like a real Goodhart moment.”

It was my turn to cock my head in confusion. “A Goodhart moment?”

My gorilla nodded at me, “Uh huh. A well known British economist has an economic concept named after him. The layman’s version of Goodhart’s Law states, ‘When a measure becomes a target, it ceases to be a good measure.'”

I looked at Hogarth. I looked at the velocity reports. I looked at Hogarth. “You mean…”

He nodded, “Yup, those velocity metrics are about as useful as wheels on a speed boat. They look good spinning, but they are not really doing anything.”

Metrics- Can’t live with them, can’t live without them.

“Metrics are not bad, managers using metrics improperly is bad.” was a quote I sent out on Twitter (@JBC_GC) during Agile Open Northwest 2017. The session was “Why do metrics get a bad rap?” and it was a lively conversation with some surprising outcomes.

I’ve had a lot of success with the healthy use of team metrics. I’ve used the afore mentioned Goodhart’s Law as a conversation starter on the good use of metrics many times. And despite my success with team metrics I had never really articulated, to myself or others, what the disconnect between team metrics and management’s desire to set goals on those team metrics was. Turns out it is rather a simple thing.

Managers don’t actually care about metrics. They care about success.

Managers want to know if the product will ship on time or with the promised features or with the promised value, or all of the above. They end up using team metrics because it’s all they have. And in the classic square peg in a round hole scenario, they were hitting the square peg with the hammer to make it fit.

And how’s that worked out for us? Even in the well run agile project, the ability to tie team estimates and metrics to actual shipping dates is a highly mixed bag. We are horrible at estimating, to the point that the #NoEstimate movement is gaining traction through being right. This, however, is not a rant about how bad we are at estimating, using no estimates or even bad metrics. It is instead a look at what we can do about this disconnect between Team Metrics and Management need.

Step 1: Recognize managers need better forecasts, not better metrics.

Step 2: Stop using Team Metrics for forecasting.

Step 3: Give managers the tools to let them forecast.

Step 1: Recognize managers need better forecasts, not better metrics.

The best use of metrics is “as a lagging indicator of if we might want to talk to the team and see if they need help.” This is the coaching advice I give to management and teams, usually shortly after quoting Goodhart’s law. Metrics will not tell you when a team will get done without the risk that the metric will run afoul of the wisdom of Mr. Goodhart.

Just as you want to know if you should pack an umbrella tomorrow (or wear sunglasses, or get your snow blower ready), management wants to know if the project will be successful. A totally and perfectly valid request. Only you don’t use team metrics for this. Even when metrics are used as the source data, they are still being used to forecast. We look at velocity trends to estimate when a team will be done. That’s forecasting, not metrics.

Step 2: Stop using Team Metrics for forecasting:

Performance based on incentives doesn’t work. When we try and use metrics to drive performance we get Goodhart’s Law. The example I like to give comes from the book Freakanomics.

To summarize: India was having a problem with cobras. To address the problem the government came up with a great idea. They would give a bounty on every cobra head turned into the government. The program was a rousing success, just not in the way the government intended. People started raising cobras just so they could collect the bounty. In short order, India’s cobra problem was even larger than before the bounty was put in place.

If you tell a team they must make a March 15th release date. They will very likely hit that date or come really darn close. And then the company ends up dealing with bugs for the next five years. “When a measure becomes a target, the measure is no longer valid.” If you’re struggling to get your message heard, you might try showing them Dan Pink’s RSA Animate video to reinforce that knowledge skill teams don’t work best from incentives, they work best from Autonomy, Mastery, and Purpose.

Of course, not everyone is going to listen, even when they pay us for our advice. Which is why I advocate limiting the metrics used and make them interlocking. Game one metric and the others will react in the negative. My four metrics are based on Jeff Sutherland’s three recommended metrics and a fourth I’ve had a lot of success with. They are:

Cycle Time
Escaped Defects
Happiness Metrics
Planned to Done Ratio

If you game cycle time so it’s really short, quality will almost certainly suffer. Let quality slip and you see an increase in cycle time and escaped defects. If planned to done is too high, then quality is probably suffering. And if metric 1, 2 and 4 are all really great and happiness is suffering then you have a strong indicator that you’re burning out your team.

Step 3: Give managers the tools to let them forecast.

This one is really easy. Stop reading my blog and go to FocusedObjectives.com. Troy Magennis has crossed the streams of mathematics, classic project management forecasting and agile to come up with a tool that allows managers to forecast when a team(s) or feature(s) will either be done or if it will hit the desired schedule.

I’ve seen this tool in action and heard stories from several users of Troy’s Forecasting approach. With this tool, the managers no longer need detailed metrics from the team. They can build forecasts based on as little as a half dozen data points, which can even be made up for initial forecasts. With just cycle time data points, you can run massive Monte Carlo simulations to get 80-90% accuracy on your forecasts (note, anyone who claims 100% accuracy is also gaming the system, or in denial).

So keep team metrics focused on improving the team. Give management their own tool for forecasting schedules and/or capacity. Then watch as the results of this is the teams getting, even more, work done, with greater predictability, and greater happiness.

Just say “No” to Gorilla Debt in your Teams

Posted on November 17, 2016 by Silverback

Debt Free by ccPixs.xom

You’d think with the amount of time I spend hitting my head on my desk it would have a permanent dent by now.

My most recent forehead abuse was brought short by the one thing I hated more than coaching a team that thought they we’re already perfect. The deep, rumbling bass of my personal gorilla cut through the sound of my head hitting the desk. “The SPFA called, they are filing a restraining order against you for furniture abuse.”

I blinked and looked up at the hulking form of my conscience in physical form. Why couldn’t I have a little cricket like Pinocchio? It would be so much easier to lock him in a jar and toss him in the ocean. “The SPFA?”

Hogarth nodded, “Yep, the Society for the Prevention of Furniture Abuse. Their motto is ‘Desks Have Feelings Too’.”

“Go away Hogarth, I’m busy.”

Hogarth broke a branch off the nearest office plant and plopped into a chair next to my desk. “Pretty sure, destroy desk with forehead isn’t the most important thing on your backlog. What’s up?”

I sighed, he wasn’t going to go away so I might as well get this all over with. “The team didn’t take into account planned vacations and the product owner used their expected velocity to promise a feature to sales. Half the team was out and the other half was almost totally consumed by blocker bugs.”

Hogarth asked, “Didn’t they have this issue the last three months ago?”

I nodded.

“And I seem to recall it was raised after the first sprint, over six months ago. Right?”

I nodded again.

“Well,” Hogarth said. “Sounds just like that problem you had with the original login server not being able to scale beyond 1000 simultaneous logins.”

“Don’t be silly, Hogarth” I snapped. “You know very well we already fixed that issue two sprints ago.”

Hogarth was smiling, I hate it when he smiles like that, it usually means I’m about to be setup. “That’s right, we did didn’t we? How is it we took care of that?”

I didn’t know where he was taking this and I couldn’t just leave it alone, “We identified it as Technical Debt. We put it into the product backlog and worked with the product owner to prioritize it alongside new feature work.”

Hogarth nodded, “So we had a problem with the product architecture, we recognized it and put it into a backlog with everything else to be prioritized?”

“Yes!” This was starting to get annoying since he was just reviewing what we all knew. Where was he going with this?

“So where is the backlog for the problems with the team? ” Hogarth asked.

Backlog for the team’s problems, like we do for Technical Debt? Team Debt?

And he’d done it again…

Team Debt is just as destructive as Technical Debt

If you have any doubt that we are worried about the effects of Technical Debt, just Google the term. I get just over one million hits when I do. With the concept of agile development now considered in the mainstream, for software development if not all product development, the recognition that we can’t build our way out of technical problems with new features is taking firm hold. While how we approach it may still be an area of wide debate (TDD, BDD, dedicated legacy teams, rip and replace architecture, etc.) we are coming to a fundamental agreement that we need to slow down and deal with the problems we’ve created before we can speed up and build the next wave.

What about our teams though? It can be very easy to forget that agile is not just a new product lifecycle process (PLC). We have been so ingrained that PLC process is about what we are building that we often forget that agile is as much about “who” is building something as “what” we are building.

“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done” –Principle 5 of the Agile Manifesto

Team Debt is the term I use to describe the impediments, issues and blockers that prevent the team from improving. Where testing and product usage will generally uncover your products Technical Debt, it is the Team Retrospectives, manager one-on-ones and coaching observations that will uncover the Team Debt. On the whole, something we are getting pretty good at doing in most agile organizations. Thanks to Scrum, we have built in the concept of the retrospective at the end of every sprint which gives us the mechanism to uncover our impediments.

Of course knowing the problem is only half the battle. We see this with Technical Debt all the time. Sure we know that our infrastructure can’t handle over a 1000 simultaneous logins, or that our core server has legacy code no one even remembers who wrote. We’ve known this for years and we’ve never done anything about it because we were too busy build the next new, wizbang, feature instead.

So just as we need to put Technical Debt into our product backlog and actually prioritize it to be fixed, we need to discover, track and address Team Debt.

The Impediment Backlog

Here, at AOL (Yes, AOL, they are still around and doing cool stuff in 2016), I’ve been experimenting with the concept of creating an Impediment Backlog. Just as the product has a backlog of everything we want to do with it, we need a backlog to track the issues impacting the teams. I’ve started coaching my teams to create an impediment backlog and include items from it into their Sprint Planning right alongside items from the Product Backlog. I’m also advocating for the creation of an Organization Impediment Backlog where we track cross and multi-team issues that cannot be solved at the team level.

By making the issues visible and putting them into the same formats as our Product Backlog, we can more easily understand and fit them into our day to day processes. If it looks like a duck, and we’re in the business of making ducks, then it will fit right in. If it looks like a fork and we’re in the business of making ducks then we’re likely to ignore it.

Ask me in a few months how we’re doing, it’s an experiment in the making.

How Agile Coaches are Like Vampires?

Posted on September 22, 2016 by Silverback

By Screenshot from “Internet Archive” of the movie Dracula (1958)

“For the love of!!!” I bit off my oath before it could move into not safe for work territory. Resisting the urge to slam the door I walked into my office. It had been another banner day in the world of agile coaching and I was ready to collapse into my chair so I could drown my sorrows in Facebook.

“Shhhh…. this is the best part”

I did a double take as I realized my chair, heck my entire desk was occupied. With his size gargantuan feet propped up on my desk, Hogarth the Gorilla was watching a video on my monitor screen.

“Hogarth, what the heck are you doing?” Only after speaking did I realize I probably didn’t want to know the answer.

“Watching a movie” he said. His hands were crossed over his chest so only his finger moved when he pointed to the screen and continued, “Bloody revenge of the Nosferatu Clan, awesome 1930’s era flick.” Turning his head towards me ever so slightly he then asked “How’d the coaching go today?”

“Huh, what?” I was thrown by his sudden change of conversation and quickly forgot all about his misuse of my computer as I recalled my day. Tossing myself into the guest chair I sighed, “Lousy, absolutely lousy.” I started ticking off my fingers. “One of the teams is in a tailspin after a disastrous planning meeting, to which I was not invited.” I ticked my second finger, “Another team can’t get anything done in a sprint and seems to think they don’t need to do retrospectives they just need to work harder, and they won’t listen to any of my advice.” I ticked a third finger, “I held a story splitting workshop for the scrum masters and product owners, only no one showed up. Too busy they say.” I started to raise a fourth finger when Hogarth raised a hand to stop me.

“You know?,” Hogarth began. I knew this lead in. His next words were going to be some brilliant epiphany that even though I’d want to deny it, he’ d be right. I just sipped my coffee, waiting for the gorilla to drop.

“Agile coaches are really a lot like vampires.”

“What?” I spluttered coffee across the desk in my shock. There was no way this was some brilliant epiphany. Hogarth had finally cracked. “How on earth is my job like that of a blood sucking soulless demon? I am not an attorney!”

Hogarth waved to the monitor screen. On it the vampire was thrashing about in an open doorway unable to reach his intended victim who was only just inside the door. “Vampires have to be invited in.”

Invited in? Hogarth was relating me to an evil creature of the night and how it couldn’t cross the threshold of your home if you didn’t invite it. As long as you didn’t invite it, it was powerless to do anything.

Oh…

And once again, Hogarth had hit the crux of the issue.

How are Agile Coaches like Vampires?

We have to be invited in.
Our greatest power lies in influence.
We need blood to survive.
A stake through the heart destroys us.

We have to be invited in: Fans of 90’s era Buffy the Vampire Slayer will know this one very well. Vampires can’t cross the threshold of your home without your permission. So long as you don’t invite them in, they are stuck outside throwing taunts and jeers at you.

Whether you’re consulting or a full-time coach, if you don’t have an invitation you are not going to be effective. Something you learn in life coaching is that success requires something akin to a ‘rules of engagement’ with your client. You can’t just show up and start telling them what to do. If your coaching client doesn’t want your help, or doesn’t want it in a certain way, no amount of talking or prodding is going to make you successful.

It’s the same thing for agile coaching. Even if the CEO personally hires you, and anoints you as the holy expert of agile, if you don’t get buy in from the teams, you won’t be effective at all. You can’t force yourself on the teams, you have to make yourself valuable to them. Start by asking questions, gathering feedback and observing what is happening with the teams. The act of doing this will help to build trust with your teams. You won’t be able to do anything without that trust.

Our greatest power lies in influence: If you ever watched the 1990’s Dracula, with Gary Oldman and Keanu Reeves (You can be forgiven if you didn’t ), there was a big emphasis put on this aspect of a vampire’s power. And no wonder they have these power, when sunlight kills you, holy objects burn you and common garden herbs make you recoil, it’s hard to use the direct approach to get to your victims. So vampires use their mental powers to lure their victims into their deadly embrace.

Like the vampire, the agile coach can’t bull their way through a transformation. In order to be effective, they need to use personality and influence. We’re talking about “soft skills” here. You know, those things that have been made fun of for the last three decades, only suddenly now people are realizing they really matter (thanks to influencers like Sinek, Pink and Gladwell). The agile coach has needs to ask what the team think instead of trying to tell them. You have to let the team find the answer, not push it in their face.

We need blood to survive: Okay, bit of a stretch so stay with me. Vampires need life force to survive. They get this through the blood of their victims.

Agile Coaches need energy as well, the energy of interaction. If we are locked away in a tower, with no interaction, we are not effective, we will fade away. If a motor is not used, it will stop working. Having really smart coaches sitting in some central office, writing blogs, giving remote advice and the like is a waste of good assets and won’t make your teams better.

A stake through the heart destroys us: Well, yeah wouldn’t a stake through the heart kill you too?

So yes, Agile Coaches are a lot like vampires. We need to look to be invited, we need to build trust with the teams, we need to be a light in the dark and we need to wear sunscreen outside.

Have you invited your agile coach in lately?

The Gorilla asks: “To FTE or not FTE? That is the question.”

Posted on January 25, 2016 by Silverback

Or why I choose to be a full-time coach.

“Explain to me again why we’re going to be renaming projects ‘missions’ and our teams are now ‘squadrons’?”

My boss waved his hand vaguely, “It’s the new consultants we brought in. Bunch awesome hot-shots. Their workshop was totally eye opening. I mean the military has been running fast projects for decades. Why didn’t we think of it sooner?”

‘Because we’re a data processing company with absolutely zero to do with the military’, I thought.

“Anyway,” he continued, “I think we should roll their recommendations out. You’re the coach, what do you think?”

What did I think? I tried to fathom the depths of his question and failing that I went with the obvious. “Well it’s hard for me to say. I didn’t go to the training so all I have is this promotional flyer you just handed me.”

My boss nodded gravely. “Yeah, that was unfortunate. But you’re a contractor so the company can’t send you to training.” He clapped his hands on the desk, and pushed himself to his feet. “Tell you what, spend some time Googling it and give me an assessment tomorrow. I’ve got to get to the strategy planning meeting.”

I started to open my mouth only to have my boss wave me to silence. “I know, I know. It would be so much easier if you could be in the meeting. Confidential company data and all though. I’ll brief you on what you need to know tomorrow.”

And with that he was gone, leaving me in his office staring at the flyer of some consultant, who I didn’t get to talk to, that I was supposed to give my opinion on how to implement. I buried my head in my hands and contemplated becoming a beat farmer.

“Hey,” the voice was deep and earthy “was that your boss I just saw walk into a conference room with those Fly Right Consultants?”

Oh my day couldn’t get any worse. Not only was my own personal gorilla here to torment me, he was telling me even the consultants get to go to the meeting I should be running. “Go away Hogarth, I’m not in the mood.”

“Yeah well how do you think I feel. You try explaining to the security rhino why you need a security pass when you’re just the figment of a contractor’s imagination. You’d think a fellow hourly guy would have some sympathy for my plight.”

I hadn’t sufficiently tuned out Hogarth and what he said pierced into my brain, jumping me into action. “Holy …., I forgot to put in my time card!” I started to jump from my chair only to be stopped by Hogarth’s massive hand in front of my face.

“Don’t worry, I turned it in for you this morning?”

I blinked. “This morning! It’s 6:00 pm how can you know how many hours I worked today?”

Hogarth gave a dismissive shrug. “It’s not like that matters, you know they’ll only pay you for forty hours no matter how many you actually work.”

Not for the first time I came to the conclusion that being a contractor sucks.

Agile Contractor, Agile Consultant, Agile Coach, the continuum

There are several paths to becoming an agile coach (leader, champion, guru, insert your adjective of choice). The most common path starts first with being a scrum master and then moving up into being an agile coach. A less common path is doing program management in an agile organization and moving from there into agile coaching.

What about once you are an agile coach? What then? How will you collect your paycheck? What is your place in the organization? As I see it, there are three paths one can take as an agile coach. Coach, Consultant, Contractor. Let’s review how these work, their pros and cons.

Full Time Agile Coach: A full time coach is perhaps the rarest form of agile employee you will find today (2016). While full-time scrum masters are not uncommon, the coach is more often a consultant or contractor with a sharply limited engagement. And I see this as a tragedy. The full-time coach is perhaps the most effective and cost-efficient solution a company will find. Sure, being a full-time coach does not offer the short-term satisfaction that consulting does. What it does offer is stability, trust and the ability to make real changes.

Benefits of being a Full-Time Coach: Longevity and trust. As a full-time coach you are not under the tight time windows so often imposed on consultants. And being full-time means you have the time and position to build trust with your teams, manager and company. In a good company (life’s to short not to work for good companies) you have the time to get to know your teams and build up relationships and trust before you start getting into the deep work of agile coaching.

Downsides of being a Full-Time Coach: You’re in the system. When you are inside of a company, reporting into the management structure and working within the politics, you lose a certain amount of authority and power. You can’t call on the “hero for hire” aura to push through your ideas. You may know the exact right thing that needs to be done. That’s great, now you have to convince your management. It can be a frustratingly teeth gnashing feeling to know and not be able to do. You also have to get used to change moving slower. Your company isn’t losing you at the end of the contract and working hard to push everything through.

Consultant Agile Coach: As a consultant you can feel like one of the Magnificent Seven (either the Samurai or Western version). You are hired for your specific expertise and when you come into an organization your word carries a voice of authority that can sway the course of CEOs much less the rank and file employee. You need to speak that authority fast though and you need to make it stick because you won’t be around for long.

Benefits to being an Agile Consultant: The “Expert” aura. Companies pay good money to hire consultants. Something about investing lot’s of money in you means you’re listened to; given access to people, meetings, and information; even given a certain amount of authority to make changes. It’s a really big advantage. It is however pretty much your only advantage. Yes, it is common for consultants to know a lot and have a deeper set of experiences than your average Full-Time or Contract Coach. This is not a benefit though, it’s just a recognition that currently the consultant space draws a high percentage of the top tier coaches. The other advantage of being a consultant is shared with contractors, that being “control of destiny”. A consultant, particularly the independent consultant, gets to pick and choose their clients and can choose to work or not work. A full time coach doesn’t get to say “I don’t like this team, I’m not working with them.” A consultant can do this (though if they do it too often they find their phone stops ringing).

Downside of being an Agile Consultant: The agile consultants are heroes, therefore they are expected to work miracles. The miracle they are usually expected to work is to make a difference in a vanishingly short time window. Ninety days in not an uncommon duration for a consulting engagement. Ninety days is a brutally short time window to get anything done in. In, The Ninety Day Gorilla, I talk about how a full time employee should practice the mantra “Do no harm” in their first ninety days. For a consultant the money often runs out by the time ninety days are up and if they haven’t made some kind of impact, they won’t be asked to come back again. Worse yet, the client will talk to their friends and those friends are no longer potential clients. If you can’t hit the ground running, cure world hunger, make the client happy, all in three months, consulting may not be for you.

Consultants also come in two major flavors, Independent and “Firm”.

The independent contractor is the ultimate in self-determination. They hang out their shingle on the power of their name alone. You hire that one person and bring them in for their expertise. If you’re lucky and wildly successful (Jeff Sutherland, Joe Justice, Mike Cohn) you can afford a staff to help you. Otherwise you are coach, bizdev, bookkeeper, scheduler and receptionist all in one. You’re also always chasing the next paycheck. Even while helping profitable client A, you’re actively working to land client B, D and C.

“Firm” consultants work for a larger organization. In agile some of the big names are SolutionsIQ, Leading Agile, and Thoughtworks). Agency consultants have some more security than the independent and much more than the contractor. If you’re good, the firm will take care of you. You will probably get benefits, bonuses and a certain amount of immunity from the “what’s my next gig?” panic. You might even end up on “bench time” where you are being paid to do mostly nothing (write training, blogs, help with BizDev).

Contractor Agile Coach: Where as the Consultant is hired “hero”, a contractor can often feel like they were picked up at the local “Henchmens ‘r Us” outlet. A contractor is hired as an hourly employee that works within a company’s normal organizational structure. They are contracted through an outside agency who issues their paycheck and benefits (if applicable). They report to a manager within the company they are contracted to. Thanks to past legal cases, contracts are always for a fixed term so as to not ever imply the contractor is an actual employee. Depending on the company the max term usually ranges from twelve months to two years. Since this is not a fixed law, smaller companies tend to pay less attention to this and I’ve seen five plus year contractors at post startup, pre-IPO companies.

Benefits to being an Agile Coach Contractor: Honestly, not a lot. Like an independent consultant, the greatest benefit is you are in total control of your destiny. You interview with a “client” on your own merits. You decide when to work and when not to work. The advantage over independent consultant is that the contracting agency handles all the pesky paperwork for getting paid, benefits and the like. If you’re not ready to hang out your own shingle and don’t want to work for an established consulting firm, this is the greatest path of independence you can find.

Downside of being an Agile Coach Contractor: You’re getting the short end of the FTE and Consultant sticks. Contractors are considered “Staff Augmentation”, so they are treated as part of the organization they work for. They report to a company employee and are almost always the “junior” person in any department. Staff Augmentation means you don’t have the aura of being a hired “expert”.

And as a contractor you have the same fixed time window of a consultant. Last year I interviewed with one of the old enterprise players in Silicon Valley (you know the companies that were the big guns until Google and Facebook came along and Apple started their “i” wave of products). They were trying to engineer an end-to-end agile transformation of a core business unit. Only they were looking to hire an agile coach on a three month contract and expecting significant results in that three months.

So without the mantle of “expert” given to a consultant, a contractor has a doubly hard time being successful in the short time window given. That company I interviewed with last year is on something like their seventh agile coach contractor and no closer to real change than they were two years ago.
So… (Conclusion)

I’ve worked as a contractor, a consultant and a full time employee. While few would support contractor as the preferred way to earn a paycheck, the “Consultant or Full-Time” question is common.

For me the answer has become clear. I find it much more fulfilling to be a full-time coach. I’m not saying I won’t consult again in the future. What I am saying is that being a full-time coach I believe is the best combination of pros and cons of all the options.

Of course an even bigger question is what should companies hire?

You’ll have to wait until the next blog for that answer.

This blogs is a prequel to my upcoming Agile Coaches Playbook series. This blog is specifically inspired by my session at Agile Open Northern California on Oct 9 and 10. Special thanks to Mike Register, Sam Lipson, Ravi Tadlwaker, Arielle Mali, Eric Johnson, and Gautam Ramamurthy for their great contributions.

The Gorilla Pareto: Agile Adoption Anti-Pattern

Posted on June 22, 2015 by Silverback

It seemed like a good idea at the time. That’s what I kept trying to tell myself and I dragged my way up the hallway to my office.

When the VP had come to my office and told me he wanted me to go help the Perseus team, kick off an agile transformation, I was thrilled. We’d been having some really good luck agile on the Icarus project and the VP wanted to see if we could extend that farther. The guys on Icarus we’re awesome, true rock stars all of them and I know that helped a lot. Still I saw no reason why the Perseus project couldn’t get some benefit from agile.

I felt like a Spartan who came home without his shield. Not only did I fail, I was massacred.

“You’ll be more motivated, more empowered,” I said.

To which someone on the team replied, “We’re plenty motivated, we are doing the work we want to do.”

“The scrum master will be tasked with removing your impediments, making work easier,” I said.

To which someone on the team replied, “If the company doesn’t fix blockers, then we work on something else.”

“You’ll be recognized for your expertise.”

To which someone on the team replied, “So? We must be recognized, the company hired us. We gonna get paid more if we do agile?”

“You get to decide how its built, instead of being told.”

To which someone on the team replied, “Seriously? We don’t listen to product management anyway. We’ve been building it our way for years.”

“Status reports practically write themselves. The burn down is your status.”

To which someone on the team replied, “Project management writes the status reports. Besides, it’s not like anyone pays attention to them.”

I slumped against the door to my office and gave a deep sigh. Of the entire team I think only one or two showed any real interest. One was a smart kid probably no more than three years out of his masters and the other was the overwhelmed and frustrated development manager.

“Hey,” a voice called from inside my office. I looked in to see Hogarth abusing my office chair with his bulk. He was holding up the banana I’d picked up from the fruit bowl this morning. “You don’t have any Lady Finger bananas? Heck, even a Goldfinger or Lacatan would be great.”

I strode into my office, extremely not in the mood to deal with my gorilla conscience today. “Hogarth, it’s a banana. You can have the yellow kind or the green kind that’s not good unless cooked.”

“Plantain”

I stopped, “What?”

Hogarth got a professorial look, indicting a teaching moment was coming. “Plantain, that’s the green kind and not technically a banana. It’s Musa paradisiaca, while dessert bananas are Musa sapientum.” He held up the banana, “This Musa sapientum is a Cavendish, a Robusta to be precise. Your generic everyday banana. Okay for putting on cereal or peanut butter and banana sandwiches, just not the connoisseurs’ banana.”

“You’re telling me bananas come in more than big, little, green and yellow?” I asked.

He nodded “Yeah, I think it’s like the parrot principle or something. Eighty percent of the bananas produced and exported are a variety of Cavendish.” He held up the banana by way of demonstrating.

I blinked in confusion, “You mean the Pareto Principle?”

Hogarth shrugged, “Yeah, that’s it. Some Italian economist right?” Hogarth cocked his head, “too bad they don’t have some Pareto rule for people.”

Yeah too bad, that would explain a lot of things….

Hey, wait a minute!?!
Why do some developers hate Agile?

Note: The goal of this blog is to generate critical thinking on this subject, not to point fingers.

A lot of the popular agile marketing pumps up how much developers will love agile. How your development teams will be the ones fighting for it, championing for it or even doing it behind management’s back. Sure, I’ve met these people. Most of them work for boutique shops or start-ups. Unfortunately I find in enterprise software companies that these agile champions are often in the minority.

This has long created a cognitive dissonance in me. I know and understand in my soul that the values and principles of agile promote not only a more effective and productive workforce, it also produces happier, more engaged people. In short, I support agile because I think it will lead to a better world.

So why is there so much resistance from those it was intended to directly benefit? Then it hit me. I had a realization, an epiphany even. Agile is only revealing the underlying truth, one that many in the work force would love if it had never been undiscovered.

In Traditional Development, the majority of the work is being done by the minority of the people

The Pareto principle (also known as the 80–20 rule) states that, for many events, roughly 80% of the effects come from 20% of the causes.

Anyone whose spent even a couple of years in high tech will have heard of the 80-20 rule. I hear it most often in the “80% of our calls are from 20% of our customers” or “80% of our business comes from 20% of our customers. Reaching to Wikipedia we find that the Pareto principle has several common business corollaries.

80% of a company’s profits come from 20% of its customers
80% of a company’s complaints come from 20% of its customers
80% of a company’s profits come from 20% of the time its staff spend
80% of a company’s sales come from 20% of its products
80% of a company’s sales are made by 20% of its sales staff

From <https://en.wikipedia.org/wiki/Pareto_principle#In_business>

Notice the one I bolded? Well yeah, I bolded it so you would.

What happens if you replace “sales” with “code” and “sales staff” with “development staff”, what do you get? The Pareto principle is arguing that 80% of the code developed is coming from 20% of your software development team. Those rock star coders? The ones management frets about what will happen when they leave? Yeah, they should worry. Because these rock starts are not just good at their job, Pareto argues they are probably doing much more work than the majority of the team.

Then along comes agile to shine a bright scary beacon on this reality. Suddenly bringing the coders into the light and making in crystal clear who is doing the work and who is not. When the team is reviewing work every day, and planning every week or two it quickly becomes apparent who is doing the work and who is not.

This is a tough subject and not likely to be wholly popular. No one wants to be told “hey, you’re a slacker!” I know, I’ve been exactly in the shoes of an agile resistor. I once told a room full of people “you’ll pry waterfall from my cold, dead hands.” And reflecting back now, I can say one of the things I feared was how much attention it would put on my own work.

So I can first hand the feeling of that scrutiny on your work is not unlike being a cockroach caught in the light. Close to twenty years ago I was in a job where I was doing okay, just okay. I wasn’t a rock star by any means. I was, however, the only person with a specific skill set and for a variety of reasons I didn’t work as hard as I could have. Then a new person came along. They knew my special skill set and tackled work with a wild abandon. The person was also incredibly nice and personable which meant it was hard to even dislike them. They were just doing their job and doing it well. I still felt like a cockroach caught in the open.

There are plenty of hard workers out there, that are not in the theoretical 20% of the people doing 80% of the work. And the painful fact is there are also a percentage of those workers who are knowingly under performing. The 2014 Gallup poll again found more than 15% of workers are actively disengaged in there jobs.

Want another interesting thought exercise? Let’s reach into the agile bag of data for a second. A common statistic you hear, agile proponents, is more than 60% of product features are used rarely or not at all. So if 80% of the work is done by 20% of the people and only 40% of features are ever used, does that mean our teams are 80% too big? I have seen some blogs of late that argue a super-star team of ten can build any product a team of 100 can and do it better and faster. Taking the Pareto principle into account, they may not be far off the mark.

What’s the call to action?

As I noted at the start of this section, I am not seeking to point fingers. I’m seeking to generate thought. I don’t have a call to action, I don’t have a solution.

I think I know a reason why some enterprise software coders are resistant to agile. However if they don’t want to be more productive, shining a bright light on them isn’t exactly going to make them happy.

I suppose we could use this data to convince executives to adopt agile more. If we can show them who are the real producers, they can either shrink their work force or hire more of the 20% who do the work. I’m not sure that’s going to be the best use of this data by an agile coach. It might be useful for agile consulting firms in their sales cycle.

As an agile coach, trying to find a way to encourage teams to adopt agile, it’s not immediately helpful. I’ve got a symptom now. What I don’t have is a cure.

How do we make everyone part of the 20%? Can we?

A Gorilla is more than the sum of its parts. So is Agile.

Posted on June 12, 2015 by Silverback

“Agile is failing, can you believe that, he actually said that to me?”

You know you’re having a bad day when you willingly engage in a conversation with an 800 pound imaginary gorilla. I was striding down the hallway fairly vibrating with emotions. Hogarth lumbered along beside me uncharacteristically quiet. Which I guess should have been my first clue as to the rabbit hole I was being led down.

“How can he say that?” I looked directly at Hogarth, “I mean we’re doing standups every day now. I even got them down to 30 minutes.”

Hogarth finally chose to speak immediately making me wish he hadn’t, “What about the backlog?”

I threw my hands up “What about it? The backlog is being pulled straight from the PRD and we got the product manager to rank order them instead of the stupid P0 stuff. I mean how much more agile do you want us to get?”

Hogarth nodded sagely, or so I thought and I turned to walk into my office. Where I promptly stopped.

“Hogarth, where’s my fichus?” The pot that held my latest incarnation of my favorite fichus was empty. Not just denuded of leaves and branches, empty. Even the dirt was gone.

“Oh, that” Hogarth said. “Sorry, about that. I did replace it though. Here.”

Hogarth reached under my conference table and started laying several objects on the table. A sack of dirt, a trunk, several loose branches and a sack of leaves.

“Hogarth…. What’s that?”

Hogarth smiled cheerfully at me. “Oh that’s your new Fichus. Well at least it’s all the parts to a fichus, you just need to put it together.”

“HOGARTH!” I put up with a lot from my imaginary gorilla. His eating my plants wasn’t the end of the world, they made for a nice tax deduction. But this… This was going too far. “Do you think I’m some kind of Dr. Frankenstein? I can slap this all together with some glue, yell ‘IT’S ALIVE’ and suddenly I’ll have a fichus?”

I stared at Hogarth, my eyes blazing with a demand for an answer.

Only no answer was forthcoming. Hogarth and retreated to the corner of the office and was sitting in his ‘happy budda’ pose with his hands clasped happily over his hairy belly. He just kept staring at me, as if he’d already answered me and was waiting for that inevitable moment when all the pieces would crash together making whole the monumental idiocy I’d….

Pieces… Made whole… Sigh…

Putting my head in my hands I said “and we’re so focused on doing the artifacts of agile we’re completely missing the spirit and purpose which would make it whole and successful ?”

“Pretty much,” said Hogarth.

A pile of parts does not Agile make

“We’re doing stand ups, we must be agile.” Admit it, how many times have you heard this? Honestly it’s grown to internet meme status and is one of the go too jokes for mocking a company that has failed to “get agile.”

That doesn’t mean it isn’t hitting the truth smack dab on the head.

Yes, the practices of agile are incredibly important. So is structuring your organization with interactive support from all tiers of the company. If you only do the motions though, you’ll end up with an organization that is a soulless automaton not unlike Frankenstein’s monster. The monster was “alive”, but lacked a purpose and drive, a soul if you will. It at least had the intelligence to know it lacked something and spent the story trying to find acceptance and love.

In some organizations they are just like the monster, in that they know what is missing, but their efforts to find the missing is stymied. This can be the teams own roadblocks or barriers imposed by the company or even external partners and customers. These organizations are almost sadder than those oblivious to what’s missing in their agile transformations. They know they are not getting what they should out of agile while being forced to go through the motions of agile every day.

The same cannot be said for all attempts at agile transformations. They muddle along doing the practice of agile, without the purpose of agile and they either gain minimal benefit from agile or fail completely. Often blaming agile they then fall back on whatever they were doing before because it has the comfort of familiarity. These organizations then face an even greater challenge in improving because “we tried it already and it didn’t work.”

An agile transformation is more than just predictability, stability, shipping early, or even transparency. Agile is a tool that can lead an organization from being extrinsically driven to intrinsically driven. From unengaged to fully engaged. From passive process following to active innovation creation. In short all those things we are hearing about from such modern luminaries as Steven Denning, Dan Pink, Eric Ries and past visionaries such as Peter Drucker, are things that an agile transformation can help with.

If you truly set out to do it and not just pick up a couple of pieces and expect to be able to have the value of the whole.

Gorillas use the 5 Whats not the 5 Whys

Posted on February 26, 2015 by Silverback

“Can someone tell me why I just spent two hours on the phone with a screaming client?”

“They dropped a server rack on their toe and it really hurt?” asked Greg.

I glared at Greg until he went back to studying the dirt under his finger nails. The I turned to Jake, our development manager. “Jake, why can the client only load half their user base into the DB?”

Jake gave a shrug. “No clue, why didn’t QA test that?”

Vinnie jumped forward in his seat, “That’s not even in our test cases, why on earth would we test that.”

The room seemed to pause for a moment and then all eyes slowly turned towards to Tully, our junior product manager. With Bob visiting a potential customer, Tully the product management representative.

An hour later I walked into my office, tossing my coat on the conference table chair. “Poor Tully” I muttered.

“Why?”

I jumped. Turning to look where my coat landed I saw instead Hogarth holding my coat in one hand and looking at me with a questioning gaze.

“Why? Because Tully got torn to pieces in that meeting.” I said.

“Why?”

I blinked at my Gorilla. It wasn’t like him to not know everything. After all wasn’t he just a figment of my imagination? “Because Bob wasn’t there. And Bob is the one who made the requirements that didn’t address the customer’s number one need.”

“Why?”

Now I glared at my gorilla, was there a point to all of this? “So do you have a point with the annoying string of ‘why’?”

Hogarth nodded, “I do. What do you think would be a better way?”

“What?” My brain started spinning, how was this an answer? What did he mean? What was the right answer? Wait, wait, What?

And Hogarth nodded, “Exactly.”

Why the 5 Whys should be the 5 Whats.

Unless you’ve been living under a rock, you’ve almost certainly heard of Sakichi Toyoda, the founder of Toyota. He calls it Five Whys. Unless the rock was really heavy, you’ve also no doubt heard Simon Senek’s “Start with Why” TED Talk.

The Five Whys:

5 Whys is an iterative question-asking technique used to explore the cause-and-effect relationships of a problem. The goal is to get to the root cause of a problem, because all too often the first cause is not the true cause. Doctor’s call this “treating the symptoms, not the disease.”

An example the 5 Whys :

Why did our service go down?

Why? – The servers lost power. (first why)
Why? – The backup power supply didn’t work. (second why)
Why? – It couldn’t handle the load. (third why)
Why? – A replacement hasn’t been bought that can meet the power needs. (fourth why)
Why? – The DataCenter budget was frozen last quarter and we haven’t had the money to perform upgrades. (fifth why, a root cause)

Starting with Why

Simon’s talk is an incredible exploration of how companies can be inspirational and change the world. His Golden Circle places the question “Why” directly in the middle of the circle and What is placed at the edge. As Sinek pounds home, “People don’t buy what you do, they buy how you do it”

The danger of “Why”

“Start with why” is an excellent for a company exploring how they can better market their products. It can help them to better connect with their end customers and provide greater value.

And “why” is completely the wrong word to use when trying to get to the root of a problem.

What makes me say that? Professional coaching has a key concept of using powerful questions. These questions are deigned to help the coach guide the coachee to the answers they need. The coach doesn’t give the answers, the coach doesn’t even guide the answer. The coaches job is to ask the powerful questions that will allow their client to get to the solution. Examples of powerful questions are:

What is important about that?
What is stopping you?
What is the lesson from that?

What you won’t find in powerful questions is “Why”. What is the reason for this?

“Why” questions rests on the popular belief that « to succeed, one should understand how one has failed ». In other words, to learn how to swim, one must carefully analyze how one has almost drowned. In effect, why questions only let clients meander within their same-old limited past frame of reference. A good coaching process needs to gently lead the client out of their box.” (quoted from www.metasysteme-coaching.eu)

The question “why” carries a lot more emotional content than it’s cousin “what”. When you ask someone “Why didn’t you take out the trash” you are essentially putting them on the defensive and laying blame. Even saying “why is the trash still here?” creates an adversarial space.

This is “Why” is not used in coaching. You don’t want the client to get defensive, or wrapped up in the “why” of the problem you want to ask them “what” they need to do to get out of the problem.

Why 5 What’s is better

You see, Toyoda’s 5 Whys could get to the root cause, but all too often I find they side tracked by the personal agendas, defensiveness and the tragic corporate blame game circle. The 5 Whys can so easily go wrong, let’s look at the example above again, this time with real people involved.

Why did our service go down?

Why? – Because we lost power. (umm duh)
Why? – Bob hasn’t replaced the damn UPS yet, I’ve been on him for weeks. (the buck is passed)
Why? – Don’t look at me, I’ve been trying to get the UPS replaced for weeks, finance won’t approve the PO. (the buck passes again)
Why? – Unless sales starts signing up more customers, we won’t be approving a lot more POs. We’re broke.

We didn’t even get to the 5th why at this point and totally missed that the UPS isn’t broken, just can’t handle the load, so you can’t even explore how to make what you have now work for you.

Let’s try with What.

What caused the service to go down?

What? – We lost power to the core servers and the UPS didn’t work
What happened to our UPS- It can’t handle the load we have.
What are we doing about it?- Well we’re trying to get a new one, only budgets are frozen right now.
What else could we do? We could try putting just half the servers on the UPS. If we lost power we wouldn’t be able to handle a full login load, but we’d be partially up at least.
What do we need to start doing that? – Give us the okay and we’ll have it done tonight.

Asking “What” is about creates an environment of clearer answers. If you ask “What is the speed of light” you get a very specific answer of 299 792 458 m / s. If you ask “why do people fight?” you could fill a Google datacenter with the results. Not a fair comparison? You’re right, it’s not. “Why” is used when the answer isn’t as clear or there are more than one answer.

So let’s try and experiment. What would happen if we used the 5 Whats instead of the 5 Whys?

Gorillas don’t juggle – The Sins of Multi-Tasking

Posted on February 23, 2013 by Silverback

“Yeah hang on a second there Pete.” I shifted the phone to my other ear so I could grab my cell phone. “Go on, I’m listening.” I brought up the screen on my cell phone to see a text message from my wife asking if I’d done the research on website design I’d promised. Setting the cell phone down I tried to shift my desk phone back to my other ear. Only to drop it on the desk.

Scrabbling it up I tried to sound nonchalant, “Oh sorry, wind caught my office door.” Pete started talking again so I hit the mute button and then put the phone on speaker so I had two hands free. While Pete continued on about the project status, I think Bill was actually asking some questions now though it wasn’t important, I brought up my web browser and quickly shifted it to my second screen so it wouldn’t block the web session I was hosting. I needed to get my wife an answer. I could do that while the conversation went along, just had to keep it on track.

“Yeah, Pete, that’s a good point. Can you talk about how you’re going to…” Why were people talking over me like I was on… Oh right. I hit the mute button and steered the conversation back the right direction.

Mute back on I dove into the website I had pulled up.

Why was the phone ringing and people talking at the same time. Oh, cell phone. “Yeah, honey I’m looking at it right now. What? No, hang on.”

Unmute, “Yeah, Bill can we get a summary of the Icarus work?”

Back to my wife, “No, I haven’t had a chance to do anything, I’ve had thing to get done first.”

“What, no, Bill Icarus is the highest priority I, uh, had someone come into my office. Please proceed.”

Mute.

“Honey, what? No, I understand how important this is. Hang on.”

Unmute “Yes, Pete the website will be ready on June 12.” Mute

“Now honey,” Oh crap, did I just.

UnMute, “I mean the software release will be ready on June 12, sorry about that.”

And before I could hit the mute button a massive hair covered hand reached over me to hang up my desk phone. Before I could protest, another similarly hirsute hand plucked my cell phone from my ear. “Mrs. BC, he’ll need to call you back. Oh, I’m good, thanks. Just doing a little intervention. Yeah, he’ll be better. Soon.”

“Hogarth!” I snapped, trying to snatch the phone out of his hand. “I’m working here!”

My gorilla drew back across the desk and settled into my guest chair with a creaking groan of protest from the chair. “Really,” he said, “It looks more like you are juggling, badly.”

“Wha…” I tried to come up with something sharp to say, but the image of dropping my desk phone wouldn’t leave my mind.

Hogarth set my phone down on the desk. “Think of it this way, ever seen a juggler try to eat an apple while he’s juggling?” I gave a mute nod and Hogarth continued, “Yeah, it’s a mess isn’t it? The worse one I ever saw was the guy juggling one apple and three eight-balls.” Hogarth shook his head, “I hope he had a good dental plan.”

Ouch….

MULTITASKING IS NO TASKING

Let’s do a little exercise. You’ve got a smart phone, right? If you don’t I’m betting you have a watch with a second hand. If you have both, pick your poison. You’ll also need a piece of scratch paper and a pencil or pen.

Ready?

For the next fifteen seconds I want you to write from number 1 to as high as you can get in that time. Ready? Go!

Okay, how far did you get? Not bad, huh?

Another fifteen seconds now. This time I want you to alternate between numbers and the alphabet. 1A2B3C etc. Ready? Go!

Wow… didn’t get as far, did you?

And these are easy tasks. Try a third time only this time start at number one and the letter Z. Go forwards on the numbers and backwards on the letters.

Yeah, didn’t go so well did it?

Multitasking is not really multitasking. Instead what we are doing reminds me of the early days of main frame computers. We have one CPU, our brain, which can only do one primary task at a time. We aren’t multitasking, we are switch-tasking. Like the main frames of the 1960s and 70s where the CPU would give each user a slice of time and constantly rotate. Only, we are not computers and that means we can’t switch tasks instantly like those old IBM main frames could.

The human brain is not capable of focusing on more than one primary task at a time. Yes, we can do a lot of secondary things (breathing, peripheral vision, etc.), we can only face one focused tasked at a time. We might be able to switch quickly from task to task. We just won’t be nearly as efficient as focusing on a single task. The cost of switching tasks high.

Some studies say we can take up to fifteen minutes to get back on track after being interrupted. If we are multitasking, we are interrupting ourselves.

The same thing applies to teams, that applies to people. If your team is only working 50% of the time on your project, the reality is they are probably only working 40% on your project as they have the overhead of switching back and forth between your project and other projects. The more projects they are working on, the less time they can devote to each project.

Jim Highsmith, in Agile Project Management gives a great example of a team doing multitasking. In the first example, the team switches between three projects, one day on project one, two days on project two, etc. In the second example, the team works on project one until it is done, then moves to the next project.

In the multitask example, the first project completes on day 48 and all three projects are done on on day 52.

In the sequential projects, project one is done on day 20 and all three projects are done by day 36.

I’m no math major and I can tell sequential is a better idea. The first project is done in less than half the time and all of them are done in two thirds the time.

Multitasking, all it does it make you look busy.

Results matter.

Do the math.

Reviews: There is no "Gorilla" in "Team"

Posted on December 8, 2012 by Silverback

“That’s it! Kill me now!” Throwing myself into one of my office’s guest chairs I directed an exasperated look at Hogarth.

Sitting in the corner, fichus on one side, bamboo on the other, he looked at me with placid eyes. Not say a word to me, my gorilla chewed slowly on a head of lettuce.

Trying to not think about where he got a head of lettuce I gave a deep sigh and waited.

Hogarth kept chewing.

I threw my hands in the air, “I mean it! Just put an arrow right through my heart. It’s just not worth the trouble of trying to go on.”

Hogarth set the lettuce down. Good, now maybe he’d say something outlandish so I could get angry and him and distract myself from my misery. Looking at me for several long seconds, he then picked up the remains of a fichus branch. Beginning to pick his teeth with the denuded branch he continued to stare at me mutely.

“Oh, fine! I see how it is,” I snapped. “When I don’t want your pithy words of wisdom I can’t get you to shut up. But when I actually want your help you just sit there and remain mute?”

Hogarth shrugged. “Well I’m a poor archer and I’d really rather not get blood on my fur, so I’m not going to kill you. Lacking any other information, I have a leaf stuck between my molars.”

“Argh!” He was so infuriating. Couldn’t he be a normal and reasonable human being? Right… 800 pound imaginary gorilla. What was I thinking? Sigh, I hate it when he’s right.

“We’re headed up on year end.” Hogarth nodded in agreement. “That means annual reviews.” He nodded again. “And it means my agile teams have just become a pack a ravening piranha out to be last fish standing.”

Hogarth cocked his head to the side, “Fish don’t stand and isn’t the whole point of an agile team that they all pull together?”

I jumped up and pointed a finger at him, “Precisely!” Realizing pointing at a gorilla was probably not smart, I lowered my arm and continued. “That’s the whole problem. The review process measures individual goals. Suddenly all my agile team members are scrambling to show how good they are and fighting for credit of who improved the database, or made the UI fixes, or identified the root cause of the uRay issue.” I waved towards my office door, “productivity has plummeted, morale is holed and I’ve even had to break up a couple of yelling matches.”

Hogarth shrugged, “Sounds like the review process is broken.”

“Give that gorillas a cigar!” I exclaimed. “Only it’s not really broken, it’s just the way it is. Yet another process that doesn’t match with agile. I’m doomed. Agile will never work outside of small startups.”

Hogarth shook his head, “No, it’s broken. You don’t measure your spaghetti one noodle at a time.” I stared at him in abject confusion. Seeing this, he said, “when the four man bobsled crosses the finish line fastest, who wins?”

“The sled team of course. What’s that got to do with this? They are all in the same sled.”

Hogarth nodded, “Good point.” Hah, I had him now. “What about the four hundred meter freestyle swimming relay? Michael Phelps carries the whole team, everyone knows that they couldn’t win without him. Why give the medal to anyone else?”

“Hogarth that’s silly. He couldn’t win without them. It’s not like he could have swum all 400 meters himself.”

Hogarth nodded again. “Yes, that’s right. There is no ‘I’ in team.”

“I know that!” I snapped. “We’re doing agile after all. It’s all about the team. Team empowerment, team accountability, team rooms, we even have team plush toys for Ghu’s sake!”

“Then why are you measuring individuals and not the team?” Hogarth asked.

Huh… Why indeed?

Agile Reviews for Agile Teams

The average corporate review process is an almost myopic focus on the individual. What have you done? What goals did you achieve? What milestones did you meet? You, you, you. Almost like a bad country western song. Everything is focused on the individual worker and what they did. You don’t get credit for being part of a successful launch team. No, you only get credit if you led the team, or did some great thing ,that no one else did, to save the launch.

And that’s the good companies. There are companies out there (I hear Microsoft is a big sinner here) that use stack ranking. If you have a five person team, you can only give one person a five star rating and by the same extension, you have to give someone a one star rating. How do you think your team is going to behave when their literally is no points for second best?

Traditional review styles are murder on normal teams. Just imagine how much worse they are on an agile team? Agile teams promote the team owning the deliverables. The team does the work. The team commits. The team delivers. Until review time, and then hold on tight because it’s every developer for themselves.

It doesn’t work. You’re killing your teams one review at a time.

We don’t have a choice, it’s the way HR does reviews.

First of all, go read last weeks blog. If one junior captain can change the US Navy, then a manager can certainly change how his team is measured.

As for how to do it, well that I can’t take credit. I learned of this from an agile training house here in Silicon Valley. Agile Learning Labs has factored into my own agile journey many times. The founder, Chris Sims, is one of the people who took it as a challenge when I said “You’ll pry waterfall from my cold, dead hands” (Oh yes, I did say this, once upon a time). I took my CSM course from ALL and learned about the real value of agile for the first time, while getting the straight talk on how effective a CSM is (not much, you should still get one, from a good teacher, it’s a great way to learn).

Agile Learning Labs was asked to help a company that was facing just the issues we’ve discussed. The company had gone completely agile and was very happy with the change. Unfortunately, when it came time for reviews, they experienced significant disruption across the company for the entire review cycle. I’m guessing for a time after the cycle ended as well, as people digested their reviews.

So ALL worked with the company and implemented a new review process. No fancy math, no weird hoops or process and absolutely no touchy feeling trust falls.

Each employee had their review divided into two equal parts.

The first 50% rated them on how they met their individual goals. These were goals created with their manager (Oh, hey how about the Manager Tools Coaching Model) and focused 100% on things that were only about that employee and their development as an employee. Things like “Will become proficient in Ruby,” “Will present to an audience of at least 50 people,” “Will be on time to work 95% of the time” (Sometimes your goals are not big and earth shattering). Most importantly is none of this 50% had anything to do with their work on the team.

The second 50% was how well their team did. The team was measured on how it succeeded in its business objectives (shipped the product, fixed the defects, shortened the release cycle by 25%, etc.). And then every single person on the team was given the exact same rating. The exact same! If the team did poorly, then everyone might get 20%. If the team was a rockstar band, then 50% all around.

That’s not fair! One of our team is a total slacker!

Then even money says you don’t really have an agile team. Still, let’s give the benefit of the doubt here, shall we? If one of the team is not performing, then it’s the team’s responsibility to deal with the issue.

Let’s head back to the Olympics, shall we? The swim team analogy probably isn’t the greatest. The relay is based on who is fastest on the Olympic team. These guys are rivals most of the time and don’t train together except at the Olympics.

Let’s look at the sculling team (that’s rowing, people). A four man sculling team trains together year round. They are a true team in every sense. If one of the team is not performing, do the Olympic judges say “Hey, you’re a horrible team mate, out of the boat”?

No, they don’t. That team mate never makes it to the Olympics. The team takes care of it. Sure, they may have help from their coach (Coach, hmm. Could that be a manager?). The team takes care of the problem and they make it to the Olympics.

If it works for an Olympics sports team, it can work for a software development team (or hardware, or marketing, or…).

Let’s go back to Agile Learning Labs and the company they were helping. A year later, the company went through the first full review cycle. They’d been using the new model all year and everyone knew this was the model and got reminded through out the year. What happened? It worked. It worked great. The details that ALL has shared is that morale went up, productivity went up and teams didn’t miss any strides during review time.

Want to know more? I hear Agile Learning Labs is available for hire.

So take the “I” out of the team and start measuring the team, as a team.

The Gorilla Coach

Talking to the Gorilla in the Room

Category Archives: Agile