- Mob programming
- Build small things you can ship in 0.5-2 days
- Shipping infrequently reduces feedback and increases the odds of building the wrong thing
- Get immediate feedback from actual users
- Adapt what you’ll do next based on the feedback
- MUDA - anything you do that isn’t directly putting value in user’s hands is waste; it’s not unavoidable, but should be minimized
- Estimates are always wrong because they are made without the benefit of the feedback that will come as you work
- “Re-estimating” is not a solution, it just multiplies the wasted time spent on this activity
- “We’ll learn from our estimates” is a mistake as well because it focuses on the list of implementation tasks rather than the value to customers - it pulls you towards thinking about development work instead of thinking about business value
- No estimates = focus on company strategy and happy users
- Software development is not analogous to the factory analogy that lean, scrum, kanban etc focus on
- Estimating achieves nothing when working in an incremental, customer-focused way
- Estimates are based on fear of wasting money - you have to address that fear to get past this
- Agile will save money by building the right thing - that’s the lightbulb
- When speaking to management, you have to speak in terms of money
- Talk about building better products and happier customers
- Scrum (backlogs, sprints, estimating story points, etc) is not helpful and
- People also think estimates lower risk by letting you measure your progress towards The Plan
- But the real way to lower risk is to ship every few days to get immediate feedback and reduce the chance you’re building the wrong thing
- Working incrementally and delivering frequently and getting real user feedback at each increment improves the odds that you are building the right thing
- Working in long enough stretches that you become interested in estimates means you are increasing the risk of building the wrong thing by delaying real user feedback
- Estimation doesn’t work because it supports a process you shouldn’t be following: making a detailed plan that takes awhile to complete and sticking to it without real user feedback along the way
- Estimation also creates perverse incentives based on pressure that are unpleasant and simply not necessary if you reduce risk by delivering value incrementally every few days instead
- No estimates! They’re inaccurate illusion of predictability.
- Tactical roadmaps are not useful (micromanaging the implementation sequence) - try stuff, make small bets, get feedback, and be agile about what to implement next
- Strategic roadmaps are helpful, though; a direction the product should move towards to create more business value
- Code has no value - money has value
- If code isn’t helping the business make money, throw it out
Original video by CraftHub Events: