Handoffs Create Heartbreaks - A Christmas Story

Our story begins and ends at one of Florida's largest tourist attractions - The Sawgrass Mills Mall. Just like any good procrastinating parent, I waited until the last week before Christmas to get the earrings that my daughter had (strongly) hinted at. Over lunch on the 21st of December, I headed to the Swarovski store at Sawgrass Mills mall. This was also an economical decision in terms of time invested, as I was able to pick up a gift for my wife at the mall, as well. 

My daughter had shown great interest in two separate pairs of earrings. As is the most efficient method available at these stores, I walked straight to the case and located the two earrings. I asked the shopping assistant working the floor to help me get the earrings, as they were behind a locked case. The assistant, a very nice and personable gentleman, let us call him Joe, was happy to help. The fact that this was the week before Christmas meant that the store was pretty busy. Joe, did his best to help me while still helping two other customers. Since I knew exactly what I wanted, my transaction was simple and Joe led me straight to the payment counter after finding the appropriate boxes.

There were still the other customers on the floor that Joe had been helping. As Joe started ringing me up, His colleague (Let us call her Mary) who had just finished ringing up another customer, suggested that he return to the floor and she would help finish my transaction. Mary's was a logical proposal, as this arrangement would make sure that all transactions proceed unimpeded. I am able to pay for the earrings that I am buying and other customers would be helped in making the best selections possible in their context. Joe took the offer, said a courteous "Happy Holidays" to me and went over to help other customers. Mary helped with the bagging of the boxes and the finalisation of the bill. I was happy that I was able to get two pairs of earrings for my daughter in the space of 10 minutes, as this left me with time to pick up a gift for my wife as well.

After getting home, I hid the earrings and again, like a good procrastinating parent waited until the afternoon of the 24th to actually wrap the gifts. I wrapped the two sets of earrings in one gift pack and placed it under the tree for my daughter to open on Christmas morning. For any parents with a teenage daughter, the excitement is easy to imagine. You are so sure that jewellery is going to be a success. Even if every other gift is rejected, jewellery, which is backed by strong hints, is absolutely going to work.

The night passes, and I am sure Santa has done well. My wife, my daughter, our German Shephard and our Maltese are all gathered around the tree. We start opening gifts or sitting in boxes, based on our preference ( you have no idea how small a box a 90 lb German Shephard thinks she can fit inside). It is my daughter's turn and she is unwrapping the box with the earrings. I have done well, she has no hint of what is inside. She finally sees the Swarovski boxes and immediately knows what she got for Christmas. She opens the first box and there are the crystal hoop earrings that she wanted. The thank yous, kisses and hugs are being distributed. She opens the other box and... nothing! The box is empty. We shake the box, turn it in every direction, close it and reopen it, but the earrings do not appear. This just turned into an anti-climactic heartbreak. The starfish shaped earrings that I bought for my daughter are nowhere to be found. I show my daughter the picture on the box, to assure her that I had bought the right earrings and tell her that I will visit the store soon after Christmas to get the earrings that she wanted and the ones I paid for. That box was definitely not worth the money I paid for it.

Not the day after Christmas(because I love my daughter, but I hate crowds), but the day after that, I headed over to the mall. Luckily, the "returning of the gifts" crowds had died down enough for me to find decent parking and not hyperventilate due to an over-crowded mall. I made a beeline straight to the Swarovski store and was met there by two shopping assistants (not Joe or Mary) that were working at the time. One of the assistants, let us call her Kate, approached and asked what she could help me with. I explained the problem to them and asked if I could get the earrings that I had purchased. Kate seemed to be very surprised by the request. She explained that it was store policy to show the customer the box before finally closing it and bagging it. Only after the customer has verified are they supposed to bill the customer. She saw the receipt and remarked that Joe "is very good" and she is surprised that there was a slip up in the processing of my purchase. Kate asked me if I could wait to talk to the manager so that she could take care of it. I didn't mind waiting and when the manager became available, she promptly took care of the matter for me by getting me a pair of the same earrings (after doing her due dilligance of checking the vedio tape ofcourse).

If Joe is a well-respected employee with a reputation that people are surprised when things go wrong, how did things go wrong? Putting on my Agile Coach/Process Junkie hat I can see exactly where the issue occurred. When Joe handed over my transaction to Mary, there was some loss of information. Mary assumed that Joe had already shown me the box and Joe assumed that Mary will show me the box with the earrings inside. Neither of them did. This is why handoffs are dangerous. They might seem efficient at first, but there is always some loss of information when the handoff happens.

Think of all the handoffs that a single work item in software goes through. Customer request - Product Owner - Business Analyst - Software Engineer - Quality Assurance - Build Team - Operations - Customer. It is a long game of telephone where any one of these handoffs can result in a heartbreak. In the case of the earrings, it took just one handoff to cause the issue. Closing the handoff loops and eliminating handoffs is one of the reasons Agile first took flight. DevOps is the latest iteration of this. Fewer handoffs, result in fewer communication issues.

This does not mean that in every organisation, all handoffs, will be eradicated. Handoffs will exist, but where ever there is a handoff, there need to be explicit rules. There have to be explicit exit criteria before the work item can exit a stage. In order for Joe to hand something off to Mary, he should let her know of some basic information, including whether he has shown the contents of the box to the customer and received an acknowledgment. Ideally, there is no handoff, but if there is one, the policies for the handoff are explicit and understood, otherwise, there will be many heartbreaks on Christmas mornings.

How One Team Went #NoEstimates

This post is mostly a case study on one team. This is a team that I led for a couple of years. We challenged our way of working often. We changed our way of working often. We tried out changes and kept the ones that improved the rate at which we were getting things done and the quality of the work that was getting done. In early 2015, after being exposed to #NoEstimates, I decided to try the approach with the team.

As a traditional scrum team, we used to observe all the major scrum ceremonies. The major ceremonies though, morphed and changed a lot for us over time. In April 2014, 8 months before our "No Estimates" move, we had already stopped doing sprint planning. We had a pretty steady velocity of about 30 points. Instead of spending 2-3 hours estimating and planning out each sprint, we would put an estimate on a story as we were about to start work on it. We had one rule with this "just in time" estimation - We would never work on a story that was estimated at more than 5 points. We discovered two advantages with this approach. First, instead of taking the entire team offline for half a day, we would only take 3-4 people offline for 5 minutes per story at different points of time during the iteration. Second, it allowed the product owner to reorder the priorities mid-sprint. We were fine with any work that has not yet started being reprioritized. Working on a product that is affected by local, state and federal regulation changes, this allowed the product owner to change priorities, whenever any government changed its mind.

By the middle of 2014, we had discovered that our no-planning experiment was working out very well. To be clear, by no-planning I mean not doing sprint planning. We still had dates to hit, we just realized that we were just as predictable, whether we did sprint planning or not. January 2015 is when we first started questioning if the estimates themselves were providing any value. I pulled up the numbers from the last four iterations(which included the Christmas and New Year's breaks) to take a closer look at what value the estimates were giving us. Below is the breakdown of the points per iteration and points per story.

What the numbers told us here was that if we had kept the same rules (don't work on anything that takes too long) and estimated everything as 2.5 points, we would have achieved the same results. Based on this analysis we did the following (this is an excerpt from an email documenting the changes) -

1.          We bring in stories that are as small as possible(just as we do today)
2.          If any story looks like it will take the dev + qa kicking the story off more than 6 working days to complete, then split the story down.
3.      .   For reporting purposes consider all stories to be 2.5 points.

Eventually, as the organization got used to fewer teams reporting points and more reporting story counts, we got rid of bullet number 3 as well. Our Estimation discussions became sizing discussions. We went from "How many points is this story?" to "Is this too big to work on?". This, surprisingly made us more predictable in terms of the number of items we can get done over a time period. It also gave our PO the ability to pivot more frequently.

As a matter of coincidence, our Product Owner, in his numbers used to multiply the stories he had in a feature by 2.5 to figure out roughly when that feature would be done based on our velocity of 30 points per sprint. We also took that indirection away. He wasn't multiplying things in his head and we were not spending time estimating. We were both simply counting stories. Challenging the norm, in this case, seemed that it was making things easier for us, without having an adverse effect.

Without deviation from the norm, progress is not possible. -Frank Zappa

I am personally a big fan of sizing, finding out if something is too large and needs to be broken down. I am no longer a fan of estimating. Story points are a level of indirection that the entire Agile movement could have done without. There is usually the argument that they are a better way of getting teams used to sizing their work. I agree, they are, but I am sure there are better alternatives out there to introduce sizing. Removing story points did not change our throughput or predictability, so, in lean terms, they were a form of waste. I would highly recommend doing the math for your teams and finding out if story points are providing you with value. Maybe they are, but if they are directly and consistently in proportion with story counts, most likely they are wasted effort.