Skip to main content

Quality over Quantity: Squirrel Burgers

Last post 03:28 pm September 24, 2019 by Daniel Wilhite
6 replies
10:25 am September 22, 2019

The most common scenario happens in the software industry is when a boss or project manager came to the team or a developer and ask them for the estimation to develop a new system for the client. The team responded that they need 3 months to develop the system without knowing about the architecture, user interface and any other technological constraints (as the manager is in a hurry). Manger says I need this done in 1.5 months at most. Negotiations on rough estimations often end up in a big mess and this is a worrying sign for any team.

The story below was associated with Ken Schwaber (co-author of the Scrum Guide).  It might be changed slightly in the way, but the correlation with the above scenario is still valid.

Squirrel Burgers

A man walks into Fat Burger and orders a Double Fatburger, fries, and a drink.

Man only has $3.15 but the total comes to $7.15. The manager tells him he’s going to remove something from his order.  But the man insisted to have it all.

The manager doesn’t want to lose the customer so he walks out and finds a dead squirrel off the street.  He makes the burger by cooking the squirrel and putting it on a bun and hands it over to the man.

So if you draw the analogy of the story with the scenario above, it clearly seems that team compromises the quality just to deliver the product on time.

In order to achieve the unrealistic deadlines, first thing teams do is to discard the automated tests and stops refactoring the code. Soon after their code resembles coding they did in high school and they are making a huge mess.

Conclusion

The best solution is to use the Scrum in the way it is defined. Avoid upfront estimation. Estimations should belong to the team. User stories should follow INVEST principle.

Quality goals must stay the same in every sprint. (The rule of thumb is that 25% of

resources are allocated every sprint to fixings bugs and refactor the codebase: Reference is taken from The Scrum Anti-Patterns Guide—by Stefan Wolpers).

A prioritized backlog is vital (Client negotiation is very important. Product owners must work with the Client to choose which items they need the most). Even if they really want to have three features, the moral of the story is that it’s better to deliver two quality ones in the first step, release it in the market and then work on the remaining features.

 


05:56 am September 23, 2019

Or instead of a dead squirrel, make a smaller MVP hamburger (menu) to fit the expectation of cost, you can still have it all, but MVP style ;)

 


10:21 am September 23, 2019

Amount over quality methods it's more essential to get a greater amount of something than to get a couple of things that are high caliber. It's regularly used to rush individuals up, urge individuals to complete something rapidly.


01:02 pm September 23, 2019

Xander Ladage

Exactly my point. But we have to negotiate with the Customer/Client that it’s better to deliver two quality ones in the first step, release them in the market and then work on the remaining features.


07:54 pm September 23, 2019

Muhammed,

So if you draw the analogy of the story with the scenario above, it clearly seems that team compromises the quality just to deliver the product on time.

According to the analogy, the product was delivered within the budget constraints.   I don't see any time expectation in your example.

Quality goals must stay the same in every sprint

Could quality goals change from sprint to sprint based on experiments/Kaizens, with the potential of improving such quality goals?   Your statement assumes that we've somehow "arrived" at the perfect list of quality goals, and no further consideration is needed.

 


05:07 am September 24, 2019

I assume that since you posted this statement here you wanted feedback. So, I respectfully disagree with everything you said. You make a statements such as your opening one about "The most common scenario happens in the software industry..." but in my 30+ years experience what you describe is not all that common. 

In the scenario you point out that the customer was not willing to take anything less than a double Fatburger, fries and a drink.  However, the actual delivery was not a Fatburger because as you point out a Fatburger is not made with squirrel meat.  So in this case the there was a failure to deliver on the customer request. 

So if you draw the analogy of the story with the scenario above, it clearly seems that team compromises the quality just to deliver the product on time.

Not sure how you draw the analogy to a team failure because there was never a team involved in this. This is a better example of how a unilateral decision made by one person in charge failed The Manager took it upon himself to deal with the situation and provided sub-par product.The Manager went out and found a dead squirrel. The Manager cooked the squirrel.  The Manager delivered the burger to the customer.  Could the situation be different if the Manager had asked the food preparation team for alternatives that would meet the customer's requirements?  Could they possibly have settled with the customer on providing a single Fatburger with fries and a cup of water if the conversation had taken place? We will never know because the Manager did not involve the team in discussion or the decision.  This isn't an example of team failure at all.

I am going to also state for the record that everything about your original post sounded very familiar.  I did a quick google search for "Ken Schwaber fatburger" and found why it was so familiar. I read this blog post recently (https://www.threefivetwo.com/blog/avoiding-squirrel-burgers-by-insisting-on-quality) and it was why I was triggered by your post. Even though this story is attributed to Ken Schwaber, I don't see the correlation drawn by him between the single person and a team any more than I can see it in yours. At the time I read that post, I tried to find any record of Ken Schwaber actually using that story but could not. I wanted to see how he drew the correlation or the context in which he used the story. If you or anyone reading this can point me to that I would appreciate it.

I will say that your conclusions are good things but I am not sure how you drew those conclusions from that scenario.  I will also say that the "moral of the story" presented by Chris Burns at the link above are good but his seem to fit the story a little better. 

Thanks for sharing and please don't let my post deter you from sharing again.  I will always support the presentation of one's ideas and opinions in these forums. I have said many times that I learn from other's posts and that my posts are only my opinions.  Keep sharing so that we can all have a healthy debate. 


03:28 pm September 24, 2019

I want to publicly say that I reread my response and it sounds very condescending.  I apologize for that.  There is no excuse for it but I will say that I posted that late in the evening..ok early in the morning..after a long frustrating day.  While I stand by what I said, I certainly could have said it in a much better way.  Please understand that no offense was intended although I can easily see how offense can be taken.

Sorry once again.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.