Wednesday, August 2, 2017

Procrustes the Scrum Master

Procrustes of Greek myth was an innkeeper with a curious proposition: he would give you a free night at his inn, but there was a special bed you had to be fitted into in order to sleep. As you lay in the bed, if you were too short, your legs were pulled out of their sockets to make you long enough to fill the bed exactly, and if you were too tall your legs were chopped off. Rumor has it Procrustes went on to a successful career as a Scrum Master, where his skill was put to use during sprint planning.

Scrum is a good start

Scrum is a great start for teams that have been mired in Waterfall. It helps get them to start thinking of smaller batch sizes – weeks instead of years. Ceremonies such as Sprint Retrospective help establish the idea of continuous improvement.

Scrum was also useful back when introducing Agile into an anti-agile organization. It provided a set of well-defined events, schedules, activities and roles that appealed to line supervisors coming from a project management background. It also fostered an “us versus them” mentality (“Scrum Master leads and coaches organization in its Scrum adoption”) that is not really necessary now that most (all) agile adoption initiatives are top down.

Teams that depend on Ceremonial Scrum often run into issues. Having regularly scheduled ceremonies implicitly tells the team to wait until the next occurrence before doing anything. An example is the sprint retrospective. An issue or need for improvement from the first days of the sprint lingers until the retrospective occurs.

How do you deal with “leftovers” (stories started but not finished) at the end of a sprint? Do you take velocity “credit” for them? Do you stop work? Do you need to resize them? Put them back on the backlog? How much velocity credit do you take? What if a team takes on a “stretch” story and fails to finish it? How does that “count” on velocity? What about infrastructure work that takes longer than a single sprint?

When a team makes a “commitment” to a certain number of story points, what does it mean if they come in above or below? What is the difference between that “commitment” and a numerical quota? How does management “hold teams accountable” to their quota? Is there any likelihood that teams will game story sizing to make their numbers? What does management do to a team that “commits” to just one point?

Where’s the value?

More importantly, what is the value to the customer of the team spending time trying to figure this out?

Imagine you are part of a team racing Formula One, and every ten minutes you are told to stop (wherever you are on the track) and estimate how many laps, what kind of lap and against which other drivers, you will complete in the next 10 minutes. It must be exact! You are going to “commit” to it!

You have to estimate based on the risk of dealing with which other drivers in which laps where on the track. Uncertainty about weather. Doubt about how well your pit crew works.

You’ll then estimate using a Fibonacci number, derived by the team using a consensus mechanism like Planning Poker. “I voted 13 because Mario Andretti in the hairpin with new tires”. The team then “commits” to completing that many “story points” of laps based on what lap stories of previous sizes were completed in previous 10-minute chunks.

Then during the next 10-minute span of time (or, let’s call it, “sprint”) the driver knows to slow down if they would exceed the quota, or drive recklessly if they are behind. Because after all, meeting numerical quotas are more important than quality. Procrustes would be proud. Deming would not. (See his rule #11).

Maybe just try to win the race

What if, instead of spending all those brain cycles on getting the estimate right, and making commitments, your team just tried to win the race? You remember, just deliver value? The team would have no need to “game” the estimates.

What to do instead?

You could use an emergent metric, such as how many laps you actually you completed in the last ten minutes. Don’t worry about partial laps, only count those that actually completed. You could focus on finishing. If you are part-way thru a lap, finish it then start the next one. You could pay attention to improving your process, and stop managing to quotas.

Friday, July 7, 2017

Lean Standup and Kaizen

“Kanban is not clever workflow management. It is a tool for Kaizen – a device to reveal problems and lead people to think more deeply about their work”                                                                                                                                 --- Taiichi Ohno

Learning effective use of the Kanban board for Kaizen during standup is a key part of a team’s successful transition to Lean.

Often the biggest (and most valuable) cultural changes with the move to Lean is creating a Sense of Urgency. The focus is today: What can we finish today? What is the most important thing to work on today?

The team should “get annoyed” at any work item that is not moving. What’s on the goal line? Why can’t we get it into the end zone? Why do we have so many items in the Red Zone?

Per Ohno-san, use the board daily for improvement questions such as:
  • How do we work now? Does the board reflect that? Do we agree? Could we say we have a “standard” process?
  • What is the work for the team to do? Does the board show our status? (e.g., someone returning from holiday knows exactly what to do next) Do we all agree? Is there a better way to show/communicate the work?
  • What improvement experiments are underway? Are there quality issues? Who has a better way to do this? What is bugging me about this?
  • What “non-value-add” activities are distracting the team? (Visible to management during their Gemba Walk)
  • Can we “walk the board”?

Explicitly schedule daily kaizen, or make it the focus of the standup until it becomes a habit.

Improvement Needed

If your board consist of “To Do”, “Doing” and “Done”, then you do not have a Kanban board, you have a grocery list. This is usually a sign of a team that doesn’t work together or hasn’t worked together previously. Getting to a more rigorous specification of your work should be your team’s first order of business.

Thursday, April 13, 2017

Beyond Cargo Cult Agile

Many organizations trying to become “agile” never get beyond the imitation and ceremony stage. They go through the motions hoping that following the forms will give them the results they want. 

They don’t go beyond the forms to think about why certain practices are recommended, and how to apply them to this team, or how to improve on those standard practices. 

It is a rare organization that looks at the leadership behaviors and management systems that drive unhelpful team attitudes. 

And most large IT companies often have a “playbook” or an “Agile SDLC” document. Rather than being a map to help teams explore, corporate culture makes it a straitjacket that must be followed exactly.

For Example, the Stand Up meeting

One example is the Daily Stand Up, or Daily Scrum. Each team member answers the three questions: Oh sorry, wrong three questions. Those might actually be useful. 

Rather, teams are supposed to answer, what did you do yesterday? What are you going to do today? What impediments do you have? 

This often devolves into the “ice cream for breakfast” meeting. Everyone just thinks of the most recent thing they did (that they can remember) and talks about that.


Some of it is the Memento Effect

A major culprit is the insidious Timesheet Culture: Accounting has invaded development and wants to know “utilization” – people have to “estimate hours” for a task, then “track hours” and then “re-estimate hours” if there is still work left to do. 

The Timesheet Culture demands individual silos of work and prevents any kind of pairing or swarming

The standup becomes a "gotcha" to invent a rationalization for “why did you charge 8 hours to this project” (Accounting has not allowed the Scrum Master to make an effective transition from being a Project Manager). 

And then there is the dreaded “assigning work”, where team members have little or no choice in what to work on.

But the underlying reason is that the stand up as it is has no value, it just another “ceremony” the team has to endure. 

Is there anything more boring than a status report?

How to fix it

The first question I ask teams is, what is the purpose of your Information Radiators? 

Shouldn’t an Information Radiator radiate maybe, I don’t know, information? 

How about if that information reflected the changes in status due to the work you did? 
What if the radiator was structured so that “at a glance” it was obvious what is different today from yesterday? 
What if everyone updated the Information Radiator as the work progressed? 
And what if part of the team working agreement was to look at the Information Radiator before the stand up? 

In other words, what if before the meeting everyone already knew what the status of work was?

Then let’s change the stand up to make it meaningful to the team:
  1. What did you learn about the work yesterday? 
  2. What did you learn about how to do the work? 
  3. What did you learn about ways the team can improve?

(“Learn” includes raising questions about standards, processes, as well as the work)

Or better yet, use the time to consider the work as a team:
  1. What is the most important thing for the team to work on today? 
  2. What is the key improvement the team should work on today? 
  3. What does the team need to learn today?

Or perhaps:
  1. What process needs to be improved? 
  2. Where is quality at risk? 
  3. What experiments should the team conduct to explore improvements or mitigate quality risks?

You may recognize these ideas from Lean: Focus on the process and getting value to the customer as a team – eliminating waste and improving flow.