When our teams commit...what are they committing to?

This is what I’m thinking. It’s the holiday season. Happy thoughts right? 

Maybe some parties. Getting down! Maybe a little extra eggnog. 

But sadly, it’s also the time of season when all good things must come to an end. Our budgets have all but shriveled up. Our projects have ended (hopefully all on a good note.) And if we’re smart, we’ll even commiserate on what we plan do better next year.

Just being Agile over the Holidays!

For me I have to decide whether I’ve been a good little boy or a naughty one. What I mean is: will I find a Hess truck under the tree (remember Hess trucks?) or a stocking full of coal? You see, most years I can’t decide whether I’ll be seeing good old Saint Nick with his bag of goodies or Scrooge with a “bah humbug!’

 Why? Because no matter how good we think we’ve been, whether we’re drawing to the close of our last sprint or our final PI...

We’ve still got bugs!

“A software bug (or defect) is an error, flaw, failure, or fault in a computer program or system that produces an incorrect or unexpected result, or causes it to behave in unintended ways. Most bugs arise from mistakes and errors made by people in either a program’s source code or its design..." - Wikipedia

I know what your saying. â€œJohn, it’s December. It’s the holidays. You really wanna’ talk about software defects?”

Probably not. And I know nobody wants to find bugs in their code, but still they pop up – and never at a good time. Sometimes it’s simply a misunderstood requirement or just a poorly implemented product feature. And things were going so well…

Maybe it’s just too much, or not enough, caffeine during our design sessions. But regardless of whether the fault lies with the requestor or the programmer – a bug was found, fingers got pointed, and we have no choice but to fix it.

In a perfect world there’d be no bugs. In an almost perfect world, the few bugs that did surface could be handled by the Defect Elves up in Santa’s Bug Workshop at the North Pole. What I mean is…how cool would it be to have a totally different team devoted to only fixing our defects? That’ll leave our development teams to doing just the cool new feature work. I mean customers want new toys right? Not last years model just fixed up! 

 But unfortunately we live in neither of those worlds.

In the real world defects do affect us. They offset our concentration. Become annoyances and distractions and just muck up all our carefully laid plans, leaving us no choice but to find methods that enable us to properly juggle their impact - while keeping our heads focused on innovation and our feature-trains rolling. 

Simple? 

Of course it is. 

Really? 

OK maybe not so much. 

“One of the fastest ways to kill motivation is what is called in the US Army a zero defects mentality. A zero defects mentality is an atmosphere that tolerates absolutely no mistakes; perfection is required down to the smallest detail. The army considers a zero defects mentality to be a serious leadership problem, because it kills the initiative necessary for success on a battlefield.” — Mary & Tom Poppendieck

We have all heard the phrase: Fail fast, fail often. Most of us in fact consider it a healthy ingredient to creativity and invention. "It’s even motivational" you say? 

But is it always?

Let’s not hand out the party hats just yet and stay sober about this. Failing doesn’t mean we just write off defects “as the norm”. Actually, to gain all that value in innovation that we would all love to exploit from our small mistakes, we have to get better at managing defects.

Steve Tokak writes: 

“First, let’s be clear: failure is not a good thing. It’s not a goal. It’s not a desired outcome. The very notion that it’s not a big deal is creating a generation of entrepreneurs and workers that, best case, have a cavalier attitude toward failure and, worst case, think it’s OK to screw up.”

It’s great when a little screw up turns into a clever new product. I mean who could argue against Bubble Wrap when it first started out - trying to be wallpaper! Or the everyday household lubricant WD-40 - that got its name after 39 failed attempts!

No, a good idea that starts as a failure will surely find the light of day. But bugs in the code are a totally different thing. We need to better manage the flow of our defects if we truly wish to perfect the products we build. To do that, we need to be watchful, maintain managing eye and think cost-effectively. In other words - we need to control our defect ratios to maintain a healthy Balance of our Development!

The good news is we have tools to help us do this. For instance in commonly used ALMs like CA Agile or Atlassian JIRA, we can create “buckets” to manage defects alongside our normal feature development stories. You might even see a story labeled “Production Support” in your sprints. These stories accomplish two things. First, they allow us to link a bunch of similar defects in one place. Bunching them as a “story” allows us to estimate the hours we need to remediate the problem. Better yet, assessing the complexity and tallying effort hours allows us to arrive at a suitable story point equivalent.

Second, it allows us to monitor the effort of our defect work and balance our new development load along with our defect load.

Why is this so important? Keep reading.

In CA Agile (formerly Rally) we have a function that helps us associate our defects into workable clusters. We call them Defect Suites (DS). A DS is similar to a Production Support story for handling a family of defects that might profit by being managed together.    

The real value though is that regardless of whether we utilize defect suites or simple production support stories, we are exposing the quantity of our defects so that we can level-set them against our entire backlog. When a team (or product) is seeing a small number of defects per iteration, our normal 20% buffer for unknowns is probably enough to handle the load and the team may never feel challenged.

But if a team is going through a period where a large number of defects are surfacing, a better method for managing the remediation is warranted.

Obviously the root cause of this bug-up-surge is worthy of attention but that’s for another discussion.

Recently I came across a team – a hard working team – that no matter how they tried, consistently missed their iteration delivery goals. They tried everything. They had a good product owner who was doing everything he could to manage their load and keep a prioritized backlog in order. The team was writing solid user stories with articulate acceptance criteria and they had a Scrum Master always promoting rigorous Agile principles and practices like INVEST and Definition of Done.

But no matter what they did, they always ran out of time and found themselves carrying over or splitting stories because they were incomplete.

Where was the smoking gun?

 Now let me tell you a little story…

What if you were a high school weight-lifting coach? And what if you asked all your students to prepare for a big tournament by estimating (predicting) the amount of weight they all personally believed they could successfully lift. Of course, as good students, they would exercise and practice, and then come back with an estimate, in pounds, that they felt comfortable with. A weight that they believed showed them at their very best - right? 

Then on tournament (demo) day each student got up to lift his weight, and most students seemed to make their target with no problem. All except one sorry fellow who consistently missed his goal.

Let’s say that student continually insisted he could lift 50 pounds but on his first attempt only lifted 40. And on his second attempt only 35 pounds. And then on a third try, only 44. You might tell him “Listen son, I hate seeing you try so hard. It’s embarrassing to you, the team, AND ME! Let’s average off those 3 attempts and see what we get.” (Arriving at around 39.666.) 

You might then tell him “Now stop saying you can lift 50. You can’t. You can only lift 40. That’s your new target weight. You’re obviously not as strong as you think you are.”

Obviously you, as his coach, wouldn’t have to feel embarrassed any more. And he could actually get by without having to try (in his mind) as hard. You’ve definitely solved the problem of his “over-committing”, but wasn’t it at the expense of potentially creating a case of future “under-performing?”

Now let’s say the problem wasn’t the over-commitment of the weight lifter. Let’s say that on top of that 50-pound weight (that he was attempting to lift each time) sat another 30-pound weight that was invisible! He was trying to lift 80 pounds not 50. 

But no one saw it.

In my examination of some teams I often find 3 issues apparent:

• Passion and Over-zealousness. Teams tend to over-commit and under-deliver 
• One Size Does Not Fit All. No teams are identical. We’re made up of different personalities. Different skill-sets. Different development goals and most times, suffer from a different set of defect types. Some teams suffer from only a small number of bugs, while others, an overabundance.
• Invisible Load. When I find a team with a lot of backlog technical debt (carried-over or split stories) and also a high number of defects, I always look to see if they’re managing their full development load correctly. So often I learn they never account for their Defect Load. They might task them in hours but they rarely summarize the load in points. It’s a simple problem to solve. Remember when we commit during sprint planning we are saying that based on our X Velocity we will try to deliver/commit X Points in Load. How valid can that commitment be if it fails to account for their full load? (I’ve seen some teams with an invisible load as high as 20 points per sprint.)

In terms of recommendations, this is what I suggest:

? Create Full Load Transparency. The team should immediately begin using Defect Suites (CA Agile), or with JIRA create Production Support stories to cluster defects into a visible and measurable “pool”. They should then tally the estimated hours (per defect) in the pool and assign an equivalent Fibonacci point estimate. 

When using Production Support stories, the sprint may begin with a story having no tasks (no defects reported yet.) The “tasks” for this story will be the defects coming in during the sprint. As each defect arrives, maintain the tally in hours and using a normalized pointing method (as found in SAFe), place the point value into the story.  I usually start with a 2-3 point story but I continually trend it. The initial 2-3 points are just for planning purposes. 

Benefit: This will permit the team to visualize the complete iteration load and improve commitment accuracy. This of course obviates a need for improved and ongoing defect prioritization by the Product Owner. The Team, with the Product Owner (who is the voice of the customer) must monitor that production support story so that the commitment and goal expectation of the iteration never enters jeopardy. Some negotiation and bartering will be needed.

? Factor in Remediation Time. Many teams admit that they don’t consistently factor in the true time for story/defect remediation into their story estimates. This means they are estimating for “happy path” development. Of course we know our programmers are all “gods” - all on first name basis with Zeus and Hercules, but QA and Dev need to assess the true cycle times (define/build/test) of development to determine the “real effort” needed to move a story from define to accepted. 

One suggestion might be to apply a Pert calculation to your estimates:

WC + (4 * TC) + BC / 6

WC = worst case; TC = typical case; BC = best case

Benefit: This allows for a more accurate story estimate rather than relying entirely on exorbitant or “catch-all” buffers.

Remember: 

“You are allowed to feel messed up and inside out. It doesn’t mean you’re defective – it just means you’re human.” - David Mitchell, Comedian

The teams I’ve worked with, and even work with now - work hard. They’re often faced with staggering obstacles, unrealistic customer demands and inscrutable unknowns. 

But somehow they do it. 

It’s not so much a miracle. It’s more that they really do care about their customers and take pride in their work. 

I love sound metrics. But I hate to see good people demoralized by staring at numbers. The Metric is only valuable when the Metric is good. Metrics are useless - even damaging, when they don’t present a true picture.

“Garbage in, garbage out” as they say. 

So being a little more careful in how we classify and manage things like defects will give us better metrics and might even shine the light on those teams that are pulling some extra weight.

Happy Holidays All,

John (Dec 2017)