Water – Scrum – Fall
- Dave West
Design and product discovery usually is defined upfront, which is not agile, adding an agile development process in the middle isn’t all the benefits, especially with the testing and the deployment not part of the process.
Estimating the amount of work
- Pointless.
- Douglas Hubbard – http://www.cio.com/article/119059
- We create huge projections and we batch up all these little pieces of work together.
- The reason we batch the work up into one big batch, is because the transaction cost is so high. If the transaction cost was very low, we’d push the changes through in much smaller batches. Smaller batches also allow us to get the feedback more quickly.
- http://blackswanfarming.com/cost-of-delay/
- http://blackswanfarming.com/experience-report-maersk-line/
- Cost of Delay – How much does it cost you to NOT deliver the feature.
What Should We do
- Don’t optimize for the case where we are tight
- Focus on value, not cost
- create feedback loops to validate assumptions
- make it economic to work in small batches – working in small batches allows us to get the process working (i.e. faster feedback loops).
- enable an experimental approach to product dev
- Allows developers to test a hypothesis on a feature and get almost immediate feedback.
Requirements
- Users don’t know what they want. They know what they don’t want. Requirements are the wants of the HIPPO, the highest-paid person.
- A lot of the time the value isn’t defined. The "So that…" definition of value is never discussed or defined.
Tool Impact Mapping
A tool that maps the impact of the outcome. We work back from the outcome to the code of adding the feature.
The important thing is the shared understanding of the thing you’re building, not the artifacts, which agile emphasizes. This means the developers understanding the "Why" behind something, instead of tossing tasks over the cubical wall.
Pick a task with the smallest amount of work for the biggest outcome. "Minimize output, maximize outcome" – Jeff Geofels
Hypothesis-driven delivery
UX
Is about delivering things in a way that will satisfy our customers. The hard part is trying to discover what the customers want without sinking a whole ton of money into discovering, because, then you might get sucked into the sunk cost fallacy, where you’ve put a ton of money into a solution, and because of this, it’s the correct approach.
Do Less
Only 1/3 of the features improved the key metric. As Jez pointed out, this means 2/3rd’s of the work one doesn’t bring value. In fact, some of the work brings negative value to the company. This means 2/3rd’s of the time someone could spend time on the beach and have the same effect.
Feature Branching is a poor person modular’s architecture
HP Firmware Case Study
The Case Study: A Practical Approach to Large-Scale Agile Development – Gruver, Young, Fulghum
Goals
- Get Firmware off the critical path
- 10x productivity increase.
The incremental approach doesn’t just apply to software, but how we improve our processes and how we improve our companies. It’s how we improve anything.
The Four Steps of Improvement Kata Model
If you’re not constantly improving, you are degrading.
To get started, start with your job and then start networking with people in the company to understand their pain points.
Don’t fight stupid, make more awesome. – Jessie Owens
Leave a Reply