Enforcing Governance

Rules of the Road

I was on my way into the office the other day at 5am.  Being it takes about two hours, a lot can happen.  For about 15 minutes, I noticed a driver tailgating me on a winding country road.  When they had an opportunity to pass, they took it, though we were in a no passing zone.  It was a reckless act.  I then watched the driver tailgate the car in front of me.  Within five minutes, they passed that car though we were still in a no passing zone.  Off they drove, into the dark.  I thought there were three very clear possibilities that would happen.  First, this person was going to skid off the road or hit a deer. Second, a Police officer would pull them over and cite them for reckless driving. Three, nothing would happen and they would continue to drive recklessly.

Governance in our Organizations

Now, let's consider a similar situation in an organization.  You have clearly defined rules of the road, known as your organizational governance or framework.  You use this governance to ensure the different types of teams deliver on the organizational goals and that there is a shared understanding of what not to do.  The bigger and complex the organization, the greater need for the governance.

You have a team who is not following the organizational governance.  Though they are able to reach their goals, they put everyone else at risk.  What do you think would be the best course of action?

  1. Should we monitor them and see if they negatively impact other teams and the organization?
  2. Should we enforce the governance?
  3. Should we do nothing?

 

Lean Metrics in the Real World

Today, I was faced with the unfortunate task of renewing my driver's license. It's been 10 years since the last renewal and I remember the last time I was at the Maryland MVA (Motor Vehicle Administration) office, I waited for what seemed to be an hour.  We all know how painful the experience is.  You stand in line, you get to the front of the line, they tell you to go fill out some paperwork and then to get back in line. I will use the opportunity to teach others about lean metrics.

Lead Time

Lead time is the time between the initiation and completion of a production process.  In my case, I left the office at 09:00 and arrived back at the office at 10:00.  The lead time to get a renewed driver's license was 60 minutes.  Given my goal, the shorter the lead time the better.

Cycle Time

Cycle time is the total time from the beginning to the end of a process, as defined by you and your customer. Cycle time includes process time, during which a unit is acted upon to bring it closer to an output, and delay time, during which a unit of work is spent waiting to take the next action.  The shorter your cycle times (including delays) the shorter your lead time.

My cycle times included:

  • 15 minutes - driving to MVA office
  • 5 minutes - standing in initial line to be added to the proper queue
  • 16 minutes - wait time to get the front of the line
  • 5 minutes - actual renewal processing
  • 4 minutes - wait time to be given the new driver's license
  • 15 minutes - driving back from the MVA office

Cycle time is one of the key lean metrics

My hat comes off to Maryland MVA.  On their website, they provide current wait times at the different locations.  I took a screen grab before I headed to the local MVA branch.  This feedback was very valuable.  Given the service I needed, it allowed me to provide an estimate of my time away to others I was going to be working with today.

Throughput

Throughput is the the amount of material or items (people in this case) passing through a system or process per time unit. With an average cycle time of 5 minutes for the renewal process, the throughput in 60 minutes would be 12 people.  At first glance, I didn't see any real bottlenecks or delays in their system.  Given what I saw, I believe 10 people an hour is a reasonable throughput.

Understanding Lean Metrics

I hope this brief real world example of lean metrics is valuable to you.  When I was at a session for value stream mapping at Agile 2015, the poor guy leading the session kept getting lead time and cycle time mixed up.  The people in the room heckled the hell out of him. After reading this, that should never happen to you.

MythBusters Tour in Baltimore

Last night we went into downtown Baltimore and saw Jamie and Adam of MythBusters fame. This performance was much like last year, with the exception that last year we had backstage passes and got to meet them both. Though I have a lot of respect for Jamie, my admiration goes to Adam Savage.  I listen to him regularly on his podcast (Untitled: The Adam Savage Project), follow him on Tested, and I love to see his involvement in the Maker community.  He's engaging, genuine, very entertaining.  Last night, while taking questions from the audience, he responded to someone who asked why they choose the methods they choose to test  experiments. Adam said

In the spirit of science, there really is no such thing as a failed experiment. Any test that yields valid data is a valid test

Touche Mr. Savage. Though MythBusters is coming to an end in 2016, I look forward to seeing what you do next.

How Not to Choose an Agile Framework

It doesn’t matter if you’re choosing an Agile development framework like SAFe or an Agile Transformation Framework like the LeadingAgile Basecamp model, the models and frameworks are incomplete, by design.  They need to be adapted to meet your organizational goals.  Do you think the Agile Manifesto would have lasted as long as it has, if it answered all of your questions in two pages?  To that, if you think all of your questions are completely answered by a single “big picture” poster, you’re being naive. But, that’s exactly what I see happening. Realize that you have permission to mix and mash whatever you need, to make your organization operate better. The Agile police are not going to break down your door because you’re not following a framework as it was originally written. If that is what you think, what happens if the author or creator of the framework or model you're following changes it? Does that mean your business is now broken? Don’t just follow the horde of people that are choosing frameworks because they look pretty on a poster.  It's not a car!  Look for a framework that looks like a potential organizational end-state.  Evaluate what your company values from a planning perspective. Next, evaluate what your customers value from a planning perspective.  Pick a framework and then refine it (through structure, governance, and metrics/tools) to align with an ideal end-state.

Want to read more?  See more at:  agile frameworks and template zombies