Sprint Planning

A few topics (actually quite a few topics) are made unduly complicated in “A”gile circle.  
Sprint Planning is one of them.

Look at these folks enjoying a well-laid-out buffet spread. Guests have a look around the buffet table, they see what they would like the most among the options, and then they serve themselves keeping in mind what size of portion they would happily consume.  

To me, Sprint Planning is not (and should not be) more complicated than helping yourself to a buffet meal.
In fact, I see quite a few similarities between two. 

1::
At the Buffet table, guests serve themselves.
Developers (ideally) PULL the work-items themselves.


2::
Guests have the liberty to pick a small/big portion from any food bowl, keeping in mind what portion they can eat happily.
Developers pull vertical-slices of User Stories, keeping in mind how many slices they can finish within an iteration while abiding by the established DoD.
{After all, there is no point vertically slicing a UserStory, but not building it slice by slice} 

Here is what Ron Jeffries thinks about building it slice by slice.

3::

Guests select food by considering what they like most. 
Developers pull work-items keeping in mind what work would be liked and appreciated most by the Market.
What work would create maximum value for the Market, and hence for the Product, for their own Organization, and hence for themselves.

4::
If the guests need 5-10 mins more (more than what they thought), to finish their meal, then they generally take 5-1o more mins, rather than throwing away the plate with the remaining food because the time is over.  
If the developers need 2 days more (more than the planned duration) to finish the pulled work-items, they take that time to finish the pulled work-items.

5::
When a guest feels the pudding is exceptionally good, and she wishes to have one more small portion, she certainly does that.
If a developer finishes the work-items she had already pulled for the sprint, and if she feels confident that she can finish one more work-item, then she can pull additional work in the same sprint too.
After all the market appreciates how well you serve them.
The market has zero interest in knowing that your plan was accurate and your schedule variance is zero. 

6::
And here is the most important similarity.
Guests can very well use their judgment about how big/small portion of food they should serve themselves.
A developer can also use his/her educated guess (aka guesstimate) to pull just enough slices in the sprint so that she/he can finish the work with the agreed DoD.

But then, many teams do not like this simple approach of Sprint planning. 
And they love to make a big event out of it, which is appropriately called a “Ceremony”. 
I am not surprised with their preference for a complicated approach. 

As Edsger Dijkstra (winner of the Turing Award in 1972) famously said… "Complexity sells better".  

Glass Wool Effect

Glass wool is/was used in thermos flasks because glass wool is a poor conductor of heat. You can enjoy cool lemonade from your thermos flask even on a hot sunny picnic day because of the glass wool.

Many years ago, I found myself in a software building team which reminded me of this Glass Wool Effect. It taught me how bad this effect can be for the business and it also taught me how to tackle it.

Our team size was about 18 consisting of developers, testers, PO, designers etc. We also had a separate Tech Support team who worked closely with Customers to educate them, do the hand-holding, and solve their problems. Frequently Tech Support Team and Developers had long discussions (many times heated discussions) about the problems customers face.

The Tech Support opinion used to be “Developers do not really understand how Customers use our product and how to solve their problems”. The Developer’s opinion used to be “Tech Support folks do not know how to use the product and how to provide support”.

In short, the Developers were living a life like lemonade in a thermos flask, completely isolated and safe from the heat of customers. They were completely oblivious to the heat from the real users.

To be fair to Developers, it was not their fault.

Somehow our Org had created a working practice that Customer Interaction was exclusively reserved for the PO and Tech Support. A working practice where Developers job was just to write code. In Agile lingo, their job was just to complete User Stories. To make the matter worse, they were using metrics like… Velocity, #of Stories Completed, Health of Backlog, yadda, yadda, yadda. They were doing all this very diligently. But at the same time these developers had absolutely zero outward focus.  It never struck them that all these metrics are worthless, in absence of the metric of Market Feedback.  

All these developers were extremely sharp and hard working. The root cause for customer complaints was that the developers were not PERSONALY exposed to them.  The glass wool effect. I decided to remove the glass wool so that the lemonade will realize how hot it is outside.

I removed 4 developers from the Dev team for a duration of 3 weeks and told them that they should work closely with Tech Support folks and help them to solve Customer issues. Developers were anyway convinced that Tech Support folks lack product knowledge. So, they took this challenge happily. Within just 2-3 days, these Developers realized that the way they were visualizing the product is not same as the way it was being used in market. They quickly understood what kind of problems real users face. More importantly they started appreciating the challenges and the work of Tech Support folks.

Just after 1 week, I could conclude this experiment which I had planned for 3 weeks. The outcome (& the learning) was…. There is absolutely no substitute for the first-hand interaction with real users.  After that 1 week, the interaction between the Developers and the Tech Support was completely changed. Their team work became exemplary. Developers started showing willingness to talk to Customers with (or even without) Tech Support folks. Because they had realized that 1 Hr spent with Customers can give them big insight and that can help them tweak the software and to plan further work.

Once the glass wool effect was tackled, it became a win-win game.

In fact, a win-win-win game.  

Working Hard to Solve a Problem That Does Not Exist.

( Credit : EnJoy It) 

Here is a good & hilarious example of working hard to solve a problem that does not exist.
Do you see a similar kind of hard work around you?
Well, I do.

Here are a few examples of solving non-existent problems from the "A"gile circle...

• Doing an endless comparison between various frameworks and nailing down every minutest difference between any two. (An indication that Org wants to be a passenger on the bandwagon. This could also be an indication that the stakeholders do not have a common agreement on the End-Objective) 
  
  
• Investing huge energy & time to do better and better Estimation. 
  
  
• Measuring Velocity. (A clear sign of celebrating Effort, rather than Outcomes)
  
  
• Trying to maintain steady Velocity (Completely a wrong ambition)
  
  
• Obsession with Capacity Planning & endlessly searching  for “THE BEST” template for Capacity Planning
  
  
• Working hard to invent novel ways to “Add Fun”, particularly in Retrospective
  
  
• Seeking more and more ways to do self-assessment of team's  "A"gile Maturity
  
  

In all these cases, the intentions are not bad. 
But having bad intentions is not a must to go on the wrong path.

How to focus on problems that are worth solving?
Well, one approach could be...
Laser sharp focus on the market and having an outside-in view.  Laser-sharp focus on the market could lead to: 

• Gathering market feedback frequently 
• Finding out & doing THAT piece of work that would generate maximum RoI
• Releasing in shorter cycles, (at least building & showcasing in shorter cycles)
• Working with thin slices, which would enable showcasing in shorter cycles
• Working with thin slices, which would safeguard us from generating big waste

All these problems are worth working on. And when you work on them, it creates +ve impact on business. 
Business of the Customer as well as yours.