I’ve got a few real world examples I try to use to illustrate points. Would appreciate feedback if you love them, or think they are ridiculous:
Limiting Work in Progress
-
When teams do not resist the temptation to limit WIP, and try to make the case that they are mature enough (or should be empowered enough to make their own decisions) to “multi task” - I use my ‘Dinner Out’ Analogy:
-
While we might place our entire order (drinks, appetizers, soups, salads, and entrees) upfront - not Limiting WIP would be like having everything come out at the same exact time - for the entire table. Not only is there a space constraint, it likely takes longer to get your meal - as well as finish it. Savor phases of your meal, just like you should appreciate the opportunity to be focused on small batches of work
The case for finishing DEV/Test in the same sprint
-
I have heard the argument from waterfall proponents that there is benefit to being focused on specific aspects of Development and Testing - separately. These folks have even tried to contort the idea of limiting WIP and say waterfall is just a different way to keep team members focused on specific phases of delivery </ smiles />
-
I have played the following game at least 100 times. I’ll ask the person making this argument “what did you have for dinner 8 Tuesdays ago?”. After a quizzical pause - they will say, ‘I dont know’. Then I’ll ask, “what did you have for dinner last night?”. I always get an answer. I explain how easy it is to recreate recent history, and quickly recall something you just did, versus trying to rebuild the last 2 months, to answer a simple question. That’s how developers feel in waterfall. Instead of inspecting code they just wrote, they have to completely switch their frame of mind, and hope to recall certain events they did 2 months ago just to be effective. And yes, for this argument - I am 100-0.
Last one for tonight…
Defining Minimum Viable Product (MVP)
-
I have seen leadership abuse this term, and define it to be “the minimum scope I’m willing to take to production”.
-
Which really means, “this is how I will justify cramming every conceivable requirement into the solution without being asked any questions that make me think about what I really need”.
-
For this, I will usually say something like “You have us building heated windshield wipers, when you dont know if the bulk of our customers live in Death Valley (when its neither cold nor rains), Miami (where its not cold), or the North Pole (where it doesnt rain). Perhaps a better experiment would be whether windshield wipers protect the car from being stolen.” Assuming you know the solution to a problem space is not what having a MVP is. Its validating you are solving the right problem, or providing the most useful feature to satisfy a particular challenge. In many cases, people do neither - but tout MVP as the reason for why a given team or program exists. Just because we are building a feature that could be useful, market conditions and even just trying to figure out what problem you are solving - is often far more practical and effective.
Are these crazy? Or can these work to illustrate points??
No ego here. Beat on these, and please share anything else you’ve used so I can steal them 
