Category Archives: Uncategorized

Don’t Give Up! A Story About Impediments


snail crawling on pavement

This snail thinks it’s speeding along. Do you?

Let’s talk about impediments.  “A hindrance or obstruction in doing something”.  From the Latin impedire, to shackle the feet of.  A thing that slows you down or keeps you from moving forward.  Simple as that.

And yet every day I go to stand-ups or Scrum of Scrums meetings and I hear people go around the room: “No impediments.”  “No blockers.”  Really?  There’s nothing standing between you and your ideal flow state where you code, test, or write stories all day in your dream office on your dream machine with no interruptions and churn out only the best bug-free features with no tech debt and no escalated support calls?  Are you guys hiring?  I wanna come work there!

Often when people say they have no impediments they mean that they have no unusual impediments.  Or they mean that they have none that they think anyone can do anything about. Other things that keep people from reporting impediments:

  • They’re embarrassing:  “We’re about to do some Angular and I don’t know anything about it.”
  • They involve interpersonal dynamics:  “There’s a person on the team who won’t explain their code to me.”
  • They involve money.  “This laptop is too slow.”

I have a true story about that last one.  Read it and let me know if that changes your mind about handling impediments.

So … slow.

When I train Scrum Masters I always stress their role as impediment removers.  Some take naturally to this part of the job, while others need some assertiveness training.  I myself tend to naturally avoid conflict so I often have to remind myself to practice what I preach and not shy away from the hard problems.

Anyway, there once was a newly minted Scrum Master who was very gung-ho about the role and almost immediately let me know that his team’s top impediment was that their laptops were too slow. I agreed and pushed a request for faster laptops up the chain.  And … not in the budget.  Also, I was told, the machines aren’t too slow: the teams have designed an app that’s too complex and thus puts a strain on the machines when running locally.  Which was true to an extent, but not that helpful in the short term.  I tried to push it a bit but got a very firm answer again: this isn’t going to happen.  Make do.

laptop with stethoscope and crumpled paper

Is it doing anything? I can’t tell.

Reader, I’m embarrassed to say that I gave up at that point because, well, that’s just how things are around here.  But my Scrum Master trainee didn’t.  He started to collect data from the teams:  mean time to open the application in the IDE, mean time to start debug mode, mean time to run all the unit tests, and so on.  He made videos.  He showed them to people. Eventually he found the company’s employee suggestions site and wrote a long and compelling case for better laptops, which included calculations of the cost of lost productivity versus the extra cost of a fast machine.  He then started networking with developers on other product lines and in other offices and got them to all go vote for his suggestion, which then became the #1 hot item on the suggestions site.

This got him an audience in front of the executive team, which was delayed but eventually happened.  Between this and some cajoling of a new development director, the first new and souped-up machine finally arrived.  Benchmarks showed it did indeed cut task times by a huge amount and as machines aged out they were replaced with the new spec, which made its way to the IT department as the updated company “performance laptop” standard.

This entire process took close to a year if I remember correctly.  The Scrum Master did not get a fat bonus or much official recognition for this, but I’m going to go out on a limb now and say that was one of the all-time legendary impediment removals.  No mandate, no seniority in the company, just good old-fashioned stick-to-it-iveness.

Are You Fighting That Hard For Your Teams?

As a Scrum Master. impediment removal is one of the single best uses of your time once a team is up and running with the basics of Scrum.  You are directly targeting waste and by doing so increasing your team’s velocity and most likely its morale.  Also, if you’re not a technical member of the team, you’re gaining the team’s appreciation and respect and helping the organization see the value of the Scrum Master role (Hey, it’s OK to have a selfish motive thrown in there).

Don’t get me wrong – it’s not always easy to solve impediments.  Many times even getting the team to recognize and raise them takes quite a bit of creativity and effort.  But don’t let that stop you.  You’re a Scrum Master – Master of Scrum!  So use your Courage and Commitment – two of the five Scrum values – and dig into those impediments.  What are you waiting for?

bored lemur

Courage, Conferences, and Coffee

Today I have for you a hopefully inspirational little anecdote about recognizing wastefulness (muda in Lean terminology) and having the courage and initiative to eliminate it when you see it.  In this particular case, the wastefulness involved waiting for something very important to me personally: coffee.

Conference Coffee For Five Hundred

I’m not sure exactly how many people turned up recently at the wonderful TriAgile 2017 conference in Raleigh, NC, but I can tell you that a lot of them wanted coffee at about the same time.  In between sessions I wandered into the dining area and got in line for the self-service coffee station, which was set up against a wall on a folding banquet table, like this from left to right:

3 big coffee urns / 2 smaller hot water urns (for tea) / coffee cups / coffee accessories / water cups / water urn

I forgot to take a “before” picture, but the key takeaway is that the process went like this:

  1.  Person A (let’s call him Alf) goes to the middle to get a coffee cup.
  2. Alf steps to the left a bit to dispense coffee, but is still sort of blocking the cups.
  3. Person B (let’s call her Beth) waits patiently a few steps away.  She needs a cup for tea.
  4. Alf steps to the right a bit to begin his fiddly process of making his coffee Just Right:  Grab one sugar.  Grab a Splenda.  Tear and dump into cup.  Toss empty packets in tabletop trash bin. Grab two creamers.  Struggle with opening creamers due to obsessively short fingernails (probably a programmer).  Pour creamers.  Put creamers in bin.  Get stirrer. Stir.  Put stirrer in bin. Take a sip before moving because it’s too full now.  But carefully – it’s hot!
  5. Beth experiences the fourth type of waste (Waiting) from an uncomfortably close perspective.  The next session is about to start.
  6. Finally Alf steps away, which allows Beth to get her cup and tea bag, add hot water, and head off to her next conference session.  Luckily for person C (Calvin), Beth drinks her tea plain.

Are you getting annoyed just thinking about this?  I was in a pretty good mood as I watched this happen a few times in front of me, but as I got to the front I couldn’t resist saying to the next person, “Excessive queue lengths … if we were really agile, we’d fix this ourselves.”  I got the sort of laugh I usually get at my bad jokes and he wandered off.  But then I decided to step back about 10 feet and watch the coffee line for a few minutes.  Without fail, each person with non-trivial coffee requirements would block the entire table for a minute or so as the next person quietly and politely waited.  I kept an eye on my phone timer to get an idea of the amount of delay.

None of these people seemed to notice how long this was all taking.  Obviously, this situation called for a hero of sorts.

He’s a Man of Action!

As soon as there was a break in the line, I looked around for a banquet staff member but none were to be found.  But there was a second, tantalizingly empty table just to the right. So I did this:

Optimized coffee station

Ahh … much better.

As you can see, I moved all of the coffee condiments (sweeteners, creamer, and stirrers) out from between the coffee cups and water cups and over to the next table.  What do you suppose happened next?

The next person came up, poured a cup of coffee, glanced around, and happily wandered over to the new table to mix all the extras in.  And the next … and the next.  There was even enough room at table #2 for multiple people to work side by side.  No one questioned the new setup or had seen me make the change, but they moved through the system noticeably faster.  As a bonus, people who needed something simple like water or plain tea or coffee had virtually no wait time.  Hooray!

Be Bold

The surface lesson here is that there’s waste in almost every system and that improvements can often require surprisingly little effort.  But there are more important things to see.  In order to make the process improvement, I had to feel empowered to do so.  I didn’t worry too much about whether the staff would get mad at me; after all I had a good reason for doing what I did. Still, it took a small amount of courage I suppose, and courage is one of the five core Scrum values.  I hope that when you come to work with your agile teams each day, you trust your instincts and feel equally bold about making your team and process better.

Step Outside Yourself

Ok, so I took a small risk and Just Did It.  And yet before I even made the decision I had to notice that something was wrong.  I’d wager that most of the people waiting just accepted a slow line as their destiny for that moment.  We’re all used to waiting in lines, right?  In my case, the idle time spent in line is actually what allowed my mind to wander outside the system I was in and realize how silly it was to just take the current parameters as given.

Now think about your agile teams and whether they are truly taking matters into their own hands when it comes to the various inefficiencies they deal with as they try to complete all the sprint work they’ve undertaken.  In many cases I’ll bet they are surfacing and solving small problems in their retrospectives while the true “elephant” problems persist.  Are they convinced they aren’t allowed to tackle the big ones?  Are they so busy that they don’t even notice?  If they’re always working at or above capacity it may be the latter.

As a coach or leader, encourage brainstorming, outcome visualization and other techniques that put people into the state of mind that’s needed to generate those a-ha moments that really move teams to greater efficiency.

Perfect for a While

After all that, I’m sorry to have to tell you that eventually afternoon snacks arrived and needed to go on the second table, so the event staff moved the coffee stuff back to where it was.  I think it survived at least an hour though.  And of course this is a solved problem in general – go into any decent coffee shop and they’ll have the coffee urns together on one counter and there’s a totally separate counter for putting other stuff into the coffee.  It’s obvious when you pay attention – systems thinking, right?

Thanks for reading – see you next time!


Lies, Damned Lies, and Agile Metrics

rusty metric measuring tapeWhy do we measure things, or in this case, agile teams?  Well, we might want to know what is likely to happen in the future (prediction), or we might want to know if we’re getting any better (progress), or we might want to see how much value we’re getting out of one team versus another (productivity).  In order to make sound business decisions, we’ve got to know about all these things.  But too often we forget that measurements of human teams building new software are not exact.   Not only that, they sometimes conflict with the qualitative results we see in reality.  As an agile leader, it’s important to counterbalance graphs and and calculations with quite a bit of Management By Walking Around, a healthy dose of Gut Feel, and a heaping portion of Actually Using The Software Yourself.

Please realize that I’m not arguing against metrics.  They’re a crucial part of any agile endeavor and the lean enterprise.  But let me tell you a story about measuring teams.

Which Teams Are Giving The Most Value?

There once was a product that had teams working in two locations.  Several of those were in the United States, where tech salaries tend to be quite high.  Other were in a different country – let’s call it Freedonia as a Marx Brothers tribute – where the team cost was significantly less (60-80% of the US team).  Both teams estimated stories using Fibonacci series points (1, 2, 3, 5, 8, 13 …) and management tracked the teams’ velocity over time.

After about a year of this, management looked at the velocity charts and it was very apparently that the Freedonia teams were consistently delivering more story points per sprint.  When they factored in the lower cost of the Freedonia teams, the difference was even more stark.  Conclusion?  Invest in expanding the Freedonia teams!

Hm, you think.  He wouldn’t be telling this story if that was the end of it.  And you’re right.  Here are just a few of the problems with the conclusion that was drawn.

Problem 1 – Lack of Normalization – This one’s the easiest to spot and fix.  The teams in the two countries were not estimating relative to the same baseline.  Instead, The Freedonia teams tended to assign much larger point values for comparable stories.  So the US teams would consistently estimate and complete 35 points while the Freedonia teams sometimes did up to 80!

Problem 2 – Externalities – If you’ve studied economics, you know that externalities are (roughly) costs or benefits that don’t get quantified as part of an economic transaction.  In this case there were some major unbalancing issues in play.  Most notably, the US teams and their associated business colleagues spent a very large amount of time attending to the technical and requirements needs of the Freedonia teams, because of their overall lower level of familiarity with the product.  That is, the Freedonia teams were creating some drag on the US teams (through no fault of their own).  Also, due to time zone, language, and product owner location issues, the cost to transfer information to the Freedonia teams was much higher.

Problem 3 – Customer Value – Remember, story points or SAFe’s 1-10 scale business value don’t equal customer value.  Customer value equals customer value.  At some point, someone decided to step way back and look at a list of the features delivered by each set of teams over a period of about 12 months.  It looked something like this:

US TeamsFreedonia Teams
Internationalization of product
Metrics dashboard and widgets
Task management
Custom fields
HTML5 screen template builder
Complex international accounting
Third party accounting software sync
Roles and permissions system
Product tiering
Accounting sync enhancements
Bulk document upload
Task management (later redone by US teams)
Page-specific permissions
Spike - doc management (not implemented)
Spike - additional accounting sync

Without knowing too much about the specific product, it’s pretty obvious that the US teams delivered many more meaty, releasable features, while the Freedonia teams took more of an assisting role extending existing features. There were also several spikes that ended up as lost sunk costs since they didn’t end up as released features, and most notably a feature that had a large number of design flaws and bugs which had to be rewritten by a US team.

This doesn’t imply that the US teams were “better”; but they did have more domain knowledge and the advantage of being collocated with the Product Management, architecture, and UX teams. At the very least, deciding to expand in one location over the other should have taken into account the qualitative track record and the other situational advantages of the US teams.

Change Is Gonna Do a Number on Your Metrics

hand adjusting sound mixer fader

Change is constantly happening and affects the viability of your metrics.

My background is in science, where experiments are tightly controlled and the goal is, when possible, to change one variable at a time in order to determine its effects on a system. It’s important to realize that although we talk about agile experiments, they are not and will never be scientific experiments. You’re not building the same feature multiple times (I hope), and products, teams, and environments change so frequently that most metrics need to be taken with a shaker of salt.

Off the top of my head, here are a few things that can affect team velocity (and delivered business value), which is one of the most important metrics in agile teams:

    • someone new joined the team
    • someone left the team
    • the Definition of Done was made more stringent
    • production issues or other operational distractions
    • new Product Owner or ScrumMaster
    • vacation or illness of key personnel
    • larger organizational changes
    • moving offices
    • variable sprint length (yes, people do this)
    • quality of stories and requirements for a specific feature
    • new technologies being introduced

I’m sure there are others, but you get the point. You really aren’t ever comparing apples to apples when you’re measuring your teams.

Baby, Bathwater, Etc.

Having said all this, I love me some metrics. I love pretty graphs and charts, especially when I can draw a trend line through them that shows teams getting faster and better. But I try to be aware of their limitations in describing what’s really happening in my teams and why. Most importantly, I balance them with cultivating a deep knowledge of my teams and products as they exist in the real, non-mathematical world. I talk to the developers and testers. I play with the software and read users’ anecdotal feedback.

I’ll leave you with a short checklist you can use to evaluate your metrics and be appropriately careful about the conclusions you draw from them:

    1. Certainty – What is the level of certainty of this metric, and do all parties understand the error margin? Or are some parties taking SWAGs (Sophisticated Wild-Ass Guesses) as hard truth?
    2. Hackability – How likely is it that people are deliberately or subconsciously gaming the metric to please management?
    3. Variability – What changes to the teams or system are occurring over time that might affect the metric?
    4. Predictiveness – If you step back and look at the team or system in a qualitative, not quantitative, way, does the metric square with what you’re seeing on the ground?

Please think about this and balance metrics with other observations, and do your best to ensure that more perspectives than just raw statistics make their way up and down the leadership chain.  Good luck and happy measuring!

The Product Backlog: A Journey In The Mist

Man walking in the mistI’ve been working on reviewing an upcoming agile book and there’s a nice discussion in it about the various metaphors that people use to describe product backlogs in Scrum.  They all get the point across, but I thought I’d try to come up with an alternate visualization.  And then I had a dream about it (really)!

Something’s Bugging Me About Icebergs

One of the most common backlog metaphors is the iceberg , where a small percentage of the backlog is very well defined and visible at the top (this math says it’s about 13% for actual icebergs) and the rest is progressively more coarse-grained and murky as you go down, until at the bottom you’ve got Big Ideas For The Future that aren’t clear at all.  The idea is that this is a good thing, because Lean principles tell us not to spend too much time worrying about low priority features we may never build.  However …

Let’s play a quick word association game.  ICEBERG!!

icebergI bet you thought “Titanic”.  So did I.  It turns out that the 87% of the iceberg that’s below the water is a big problem if you’re trying to navigate.  In the case of an iceberg, it’s actually *not* ok that we don’t know much about what’s down there, whereas with software development we’ve got to accept that and deal with it.  Also we can’t see the underwater part at all without special sensing equipment – versus the sprint/current release/future release gradation of a backlog – so the analogy kind of breaks down.

Stories In The Mist

So, here’s my metaphor for the backlog:  You’re walking through a misty landscape where the fog obscures your view beyond a few dozen yards.  You need to get to your destination – a small rural town which you know lies to the north – but you can’t see it.  You do have a compass to point the way, though.  You know you’ll have to cross rivers, rocky areas, and other obstacles but again, most of them are hidden from view.  Luckily, the colors and details of closer features stand out crisply against the white background.  You see some rocks and roots in the path and an incline to climb, so you note them as the most important and move forward.

As you reach the top of the small slope, more features emerge from the mist, and now you can see some vague larger shapes in the distance, including what looks like a foot bridge over a river.  You pick that as your goal and as you keep going, more trees and rocks reveal themselves with enough fidelity that you can navigate past them.

You doggedly hike on in the right general direction, picking short and medium distance goals and stopping every now and then to rest and check your compass.  Eventually you begin to see lights piercing through the mist in the distance and this gives you energy to quicken your pace, knowing that you’re almost there.  You hear the sounds of the town emerge: car tires on pavement, a dog barking, and you step out of the fog and the woods onto the main road leading into the town proper.  You’re just a mile away from a comfortable bed and a satisfying meal.  You did it!

What I Like About This

I like this metaphor because it emphasizes that while it’s important to have long-term goals (heading north to the town), most of the effort is in assessing the immediate and imminent surroundings to make good tactical decisions:  step over these roots, head for that bridge, etc.  It also adds a sense of movement.  You’re constantly traveling forward as you achieve small milestones, and that movement itself is what reveals and clarifies the next steps.  Even if you have some prior knowledge of the landscape, there are going to be surprises and that’s ok.  A bridge is out; a path is washed out by a storm or blocked by a tree.  There are no guarantees that the set of actions you end up taking to meet the goal are the same ones you expected to take.

What do you think?  Is this a useful way to think about the backlog?  Leave me a comment and let me know!

stones on foggy river