Calculating Lead Times While Waiting at the Motor Vehicle Department

I am fascinated with how systems work and how things are designed.  I put myself in observation mode as much as possible.  Today I had to head the Motor Vehicle Department (MVD) to get a few automobile titles transferred into my name.

I opened the door to a facility packed full of people.  The procedure here is that you stand in line to get a ticket.  That ticket is issued to you with a prefix.  The prefix is the group that you are assigned to.  I was assigned group J, which happens to be for issues involving title changes.  As I was standing in line I started to pay attention to how groups were called and in my head I noticed that it felt like each window was taking about 5 minutes to process.

When I received my ticket J616.  I realized that there were 18 tickets ahead of me.  It was 11:15 am.  I quickly did the math 18 tickets * 5 mins = 90 minutes or 1 hour and 30 minutes.  I should be done around 12:45 pm.  I had a lunch date at noon.  I didn’t call to cancel it immediately.  I figured I would calculate the cycle time for a few tickets and then figure out the lead time before rearranging my lunch plans.

I pulled out my phone and immediately started a timer.  The minute the first J ticket was called I hit “lap”.  First cycle time 5 minutes 11 seconds.  If I multiplied that by the remaining work 17 items and saw a lead time of 1 hour 28 minutes.  I texted my friends and asked if they could give me another 10 minutes to determine if our lunch plans were in jeopardy.   Two tickets later and the average cycle time had dropped to 2 minutes 43 seconds and the lead time was 40 minutes.  At that point I knew it would be cutting it razor close and so I opted to let them know it wasn’t prudent for me to hold them up and that I would be checking out of lunch.

MVD Cycle Time

Included above is the full source of data for my time at the MVD.   Cycle Time is the amount of time between completed tickets.  Running Time is the time of day at the cycle count interval.  Running Average is the average cycle time for all tickets completed through that cycle.  Lead time is the Average Cycle Time * Work In Progress (Tickets Remaining).  Est Finish Time is Running Time (Current Clock Time) + Lead Time.  Var From Reality is how much variance there was between that estimated time and the actual time completed.  You can see how calculating lead time using a cycle count can be used to predict completion time.

Some things I found fascinating.  The average variance against actual was 59 seconds.  The variance was never greater than 23 minutes.  My original estimates of 5 minute cycles wasn’t too far off from the 4 minute 12 second actual and the estimate of 1 hour 30 minutes was over stated as the actual was only 1 hour 11 minutes.

I know people tend to hate estimating, but I think it is because they are poor observers and can’t see the system as a whole in play.  Additionally, it only took me about 5 minutes to come up with the estimate and about 5 minutes to capture data and reconfigure my estimate based on reality.  What are some of your experiences playing with data to make predictions?

How to Run a Lean Coffee Meeting

During a session at Agile Open Northwest convened by Arlo Belshee a number of us discussed good ideas (Lean Coffee, Core Protocols, Open Space Technology, Technical Practices and Team Practices) that needed to be spread.  These are things we take for granted in the Agile community, but when introducing them to people it becomes obvious that they are not as common as we think they are.

Agile Weekly put together this video showing you how to run a Lean Coffee meeting.

When you need a structured, but agenda-less meeting. Lean Coffee is a great way to allow participants to gather, build an agenda, and begin talking. Conversations are directed and productive because the agenda for the meeting was democratically generated.

 

Scrum Burndown Chart Hack

Hours Burndown Chart

Hours Burndown

Recently a team asked about a visual indicator to show the projection of their work for their hours and points burndown charts during the sprint.  When indicating that a piece of string would work, it dawned on me that we have pipe cleaners in our Facilitator Toolkits.  Turns out they are the perfect size for an 8-1/2″ x 11″ piece of paper and easily wrap around push pins used on the board for a burndown chart.  Plus they come in some really fantastic colors.

Points Burndown Chart

Points Burndown

Agile Open Southwest Recap

Open Spaces always tend to amaze me.  They really are the right people in the right place at the right time.  When we kicked off Agile Open Southwest, I was a little bit nervous about what might come out.  As always, I was left absolutely amazed.  It was great seeing old friends and meeting new ones.  Finding everyone was a different place on their journey yet still able to be find common ground and learn from one another.

Alan Dayley led a great session on Permission Restriction.  What is holding us back?

Jade Meskill helped us articulate what the Phoenix Agile community could look like using Legos.

Roy van de Water helped us discover how we can learn together and what might be holding back internal improvement communities.

I was able to have a frank discussion about excellence and how it can propel us to the next level.

We broke bread together and got to know each other.

Most importantly we were human with other and left encouraged we are not alone in our quest for improvement.

I can’t wait for next year.

Don’t Make Your Retrospectives Confusing

If explaining an activity in a retrospective takes more than a minute or two it probably isn’t very effective. Don’t fall into the trap of making things too complex.  Activities shouldn’t be complicated they should be fluid. Giving participants too many options and being unclear with instructions makes it difficult to fluid with sharing thoughts.

This tends to frustrate the participants and make them disengage. Good facilitation makes sure everyone has high energy and is actively participating. Be sure that you come prepared and articulate with clarity and brevity what you want during activities. If something isn’t working don’t be afraid to adjust it on the fly. Make it more simple and keep the flow going.

Remember to retrospect on your performance regularly, it is the quickest way to improve your facilitation skills.

Retrospectives. When Facilitating. Facilitate. Don’t Participate.

As a ScrumMaster when you are “running” a retrospective it is easy to fall into the trap of actively participating in it. It is extremely difficult to do this well (if not impossible), because your role should be as a facilitator not a participant. The minute you start participating you are no longer neutral and severely impact your ability to effectively facilitate.

Sometimes the need to take advantage of coaching moment or provide input is too great. One way to handle this is let the group know you are taking your facilitator hat off for a moment and acting as a coach or a participant to briefly add the input and then put your facilitator hat back on. This should be used sparingly and know that it will greatly affect your ability to be seen as neutral. However, it will at least signal to the participants your understanding that a facilitator should not be a participant. Clear boundaries are good.

A way to prevent frustration (and burn out) is to not be the one always facilitating the retrospective. Ask another scrum master to switch it up with you. Ask a team member if they want a turn. They might just surprise you.

Estimates are Evil!

A young man was bitten by a pitbull when he was 10.  Ever since then every time he has noticed a pitbull it is barking, snarling and threatening to him.  He is now 35.  He believes that pitbull’s are a vicious breed and that they should not be family pets.

Many developers feel the same way about estimates.  At one time they worked for a company that abused them with estimates.  Ever since then they see all the attributes of estimation as evil and avoid them at all cost.  Now they believe that estimates are a vicious breed and should not be used in development ever.

Estimates like pitbulls can be deadly, but not all estimates or pitbulls are evil.  Be careful when using absolutes.

Should Senior Developers Pair Program?

I am a proponent of pairing (not just for programming). Anytime I introduce it to a new team I get a number of objections. The most prominent is that pairing slows me down (because I am so awesome and everyone else sucks so bad).

The logic goes something like, if I am good (and fast) and you are good (and fast) we could be just as fast alone as we are together. Since we are both good do we really need to pair? or I am good (and fast) but you are bad (and slow) so pairing with you means we will never get anything done because you are slowing me down too much. Maybe I am good (and fast) but you are okay (and not fast or slow) then maybe we should pair because we can be fast but I can make you better.

The problem here is that there is a belief that pairing is about going faster. It isn’t (at least not in the short term). It is about achieving something greater together than we could alone. A great African proverb goes something like “If you want to go fast, go alone, if you want to go far, go together“. Pairing is about improving together.

So I might slow you down. It means I am learning and by default you are teaching. Together we are both improving. If we think of it as a marathon instead of sprint we can see that together we can get much farther by slowing down to speed up.

Definitions of Pairing Partners: (Dreyfuss Model)

Novice (Advanced Beginner)
Has little domain and/or technical understanding. This is your classic n00b, junior developer or intern.

Competent (Proficient)
Has some domain and/or technical understanding. This is your standard developer.

Expert
Has deep understanding of the domain and/or technical aspects of the system. This is your senior developer.

Here is my theory on combinations of pairing:

Novice and Novice
In this match up the production will be very slow, but the learning will be tremendously high. This is because the pair is totally reliant on each other for discovery because they have no other choice and no existing knowledge.
Learning: High Production: Low

Novice and Competent
Production will be moderate as the competent programmer will often not try to explain too much and will work at close to a normal pace for themselves bringing the novice up to their speed. The learning will be fairly high because neither has all the answers and are dependent on each other.
Learning: High Production: Medium

Novice and Expert
Production will be low as the expert is often a poor teacher and goes into too much detail explain concepts too difficult for the novice. The novice likely will ask a lot of questions and be confused. However production will still be greater than two novices. The novice will likely learn a lot, but will be drinking from a fire hose while the expert will learn new things by teaching. Overall yielding a medium learning level.
Learning: Medium Production: Medium

Competent and Competent
Production will go at a good pace as the both participants are at the same level allowing for a cadence to develop. Learning will be good for both as their shared level will allow for maximum trust.
Learning: Medium Production: Medium

Competent and Expert
Production will be high in most cases as the expert will not have to explain things in detail. Learning will be medium as the competent participant is often reluctant ask questions and the expert tends to lean towards auto pilot mode.
Learning: High Production: Medium

Expert and Expert
Production will be high as the energy level will be strong and the cadence rhythmic. Learning will be low as neither participant will likely ask a lot of questions or seek new understanding.
Learning: Low Production: High

So why bother pairing if production is “High” in a majority of pairings? Because we are not worried about this iteration/sprint we are worried about 100 iteration/sprints from now. Below you can see the difference in production over time between teams that do promiscuous pairing of multiple types versus teams that do no pairing at all.

Together (Pairing)

 

Alone (Not Pairing)

 

 

 

 

 

 

 

 

Does your team want to go fast or do they want to go far?

5 Ways to Tell if Your DevOps Relationship is Failing You

Here are five smells seen in organizations that are not fully cross functional and are trying to simulate cross functionality with some variation of “DevOps“.

  1. The development team doesn’t have a fully local development stack on their machines/pairing stations.
  2. Someone other than the development team deploys the software. (The exception being an automated continuous deployment created/owned by the development team)
  3. Someone other than the development team owns the build/continuous integration process (or you don’t have one at all)
  4. The development team can’t create/deploy a simulated production environment for any version of the software with data in under 60 minutes.
  5. The deployment process is not fully automated with the ability to automatically rollback.

The above definition of “development team” is the team writing the application.

Sunday Book Review : Leading Lean Software Development by Mary Poppendieck

Leading Lean Software Development: Results Are Not the PointLeading Lean Software Development: Results Are Not the Point by Mary Poppendieck

My rating: 4 of 5 stars

Some of the best anecdotal stories on software development that I have read. Great wisdom and content, but failed to push me towards lean being significant short of a methodology. I think that if you are developing software you should read this book. Some people will love it and consider it a bible others will find it useful but not earth shattering.

View all my reviews