The philosophy:

We want value. Teams must be given responsibility for creating value. They must be guided to understand needs and time constraints. These teams must be organised. We organise around features. We plan by selecting the features we need, and in what order. We build feature by feature to ensure frequent delivery of value. This ensures that we can see how things are progressing, early and often. Slicing features down enhances this. A capable product can be enhanced and grown. You must always remain ready to ship. We must ensure quality as we go to ensure value remains continuous, sustainable and indefinite.

Value

• Value is what we want. * Features (minimum marketable features) deliver value.
• Work incrementally for each new feature. _ Value is only achieved once software is shipped. Value must be delivered early. _ Features: Everyone may want something different, but no one wants everything. _ Ship early, ship often. _ Focus on high value, low cost features first. The next features mightn't be worth the time and money once the time comes to make them (so don't!).

Guiding

• Don't follow the Analysis, Design, Coding, Testing in series method. Analysis doesn't give insight to Design or Coding. Testing at the end leaves no time to readjust.
• Monolith projects are bad. _ You'll waste time planning for things you'll never complete by the deadline = Wasted work! _ Multiple releases are easier manage and show value sooner. * Projects that deliver feature by feature are more predictable.
• You get a better sense of the projects cadence.

Organizing

• If teams are organized by skills-set, scheduling and delays will arise during handoffs between teams. _ Organize by 'Feature Teams', each with all the necessary skills to build the entire feature. _ If you don't have enough specialists for all your teams, just make do. Assigning the best to the most important features. Creates a training/learning opportunity on the other teams. A Community of Practice! _ Build Communities of Practice around around skills. However, people still belong to their feature teams. _ Community experts now must bring everyone else up to speed in the community. * Experts are not paid because they are so, but because they help others become an expert too.

Planning

• Move from grand visions to tiny bites. _ Don't make plans too detailed - it will waste time and cause confusion. _ Key features are important to identify. _ Defer low value ideas indefinitely. _ Think about the product deeply, not just at the beginning, but all the time. _ Stay loose and ready to change plans during the project. _ Make time and money budgets, producing the most valuable features first. Stop when the clock runs out. _ Break two week sprints into two/three day stories. _ Larger stories (often broken into technical tasks) are hard for business-side people to evaluate until the end of the two-week sprint. _ Teams should choose how much work they can get done. They know better and will feel more commitment/determination to see the work through. _ Have planning sessions where features are presented one at a time.
• Don't estimate individual pieces of work, look at the aggregate and decide how much the team can do. _ 'Yesterday's Weather' - You'll get as much done today as you did yesterday. _ Estimates are risky - they want to be improved, compared. What is achieved by estimating? _ Get started immediately, if a prediction of how long things will take is needed, just count the things done. _ Stretch goals are destructive. Teams will try and unconsciously hurry - forgotten tests, unclean code. _ Hurrying introduces defects. _ Defects take longer to fix than they do to prevent. _ Estimates focus on the cost of things rather than the value. _ If there is too much food don't eat it, therein lies obesity and lethargy. * In it for the whole project, staying healthy is critical.

Building

• Go through a complete product development cycle from concept to ready to ship (requirements, design, coding and testing) in the one- or two-week cycles. _ Large, vague, sweeping requirements must be broken into small, practical next steps. _ Strive for maximum value with minimum effort. _ Features are either done or not done. There is no middle ground. _ Eliminate the test-and-fix finish. They drag on forever. _ Software should be free of defects all the time. _ Design as you go. _ Too much and all features won't be completed. _ Too little and features will be hard to execute. * Manage through observation. Tweak, observe, tweak again.

Slicing in Parallel

• Every feature needs a solid infrastructure, a "foundation". _ If foundation is built first, too much of it will be built. Resulting in fewer features. _ Building foundations first inhibits features being shipped. This restricts value creation.
• Build features to be complete enough (a simple functional version). Do not start by building each feature to its full glory. _ We still need to build all the features that are important, not just a few. _ Fill these features to as much capability as time permits. _ Small versions of each necessary feature, with just enough foundation to be solid is best. _ Having the best product at every moment, means we have the best possible project when we decide to ship. * Don't design an entire system upfront, as we never know upfront what the system will be.

Bug Free

• Product is built up of a set of correctly working features. _ Defects amount to negative features. _ Progress becomes uncertain. _ Eliminating defects as you go provides clarity on whats done. _ Defect repair is an unknown time delay. _ Repair as you go. _ Bugs are introduced when design evolves and when features are added or enhanced. _ Continuous comprehensive testing is required to catch new bugs. _ Business-level Tests: Verify we have received what we asked for. _ WE must test everything. This means more and better tests over time. _ Test burden grows over time. We need to keep up with it. _ Acceptance Test-Driven Development: Expressing features in terms of tests they must pass. _ Programmer Tests: Use TDD to ensure the code works as expected. _ More tests makes the team go faster. _ It takes longer to find and fix a problem that to prevent one in the first place. _ Design improvements must keep up, like testing practices. _ Every change tends to break our current design.
• Design must be refactored. _ Deteriorating design costs us in the same way a lack of tests do. _ We get slower unless the design remains fresh. * Testing and refactoring are required to make feature-by-feature development possible.

Recap

• Value is what we want. _ Features deliver value. _ Manage by looking at value, not by dates/artifacts that don't deliver value. _ Planning by feature is easy. _ Don't estimate if possible. Using 'Yesterday's Weather' works best _ Build features as small complete products every week. _ Products must always work correctly and be well designed.