1. Reduce waste
1.1. Anything that doesn't currently give the customer value
1.1.1. Only analysis and code add value Royce - Management of large software systems
1.1.2. E.G.
1.1.2.1. Partially done work
1.1.2.1.1. May not be included
1.1.2.1.2. Risk of bugs
1.1.2.2. Extra process
1.1.2.2.1. Don't document until implementation. Earlier stuff may be out of date.
1.1.2.2.2. Consider what paperwork is needed and what the best format is
1.1.2.2.3. Management doesn't add value but impacts the amount of waste
1.1.2.2.4. Complex tracking systems are waste
1.1.2.3. Extra features
1.1.2.3.1. May not be used
1.1.2.3.2. More code to test, debug and maintain
1.1.2.4. Task switching
1.1.2.4.1. Time to switch between tasks delays delivery
1.1.2.5. Waiting
1.1.2.5.1. No progress while waiting for external things
1.1.2.6. Motion
1.1.2.6.1. Getting data from others
1.1.2.6.2. Document hand off
1.1.2.6.3. Artifact transfer
1.1.2.7. Defects
1.2. Value stream mapping
1.2.1. Waste / value against time diagram
1.2.2. Traditional process have a lot of waste at the start. When waiting for requirements to be finalised.
2. Amplify learning
2.1. Transfer principals, adapt practices
2.2. Right first time
2.2.1. IFF implementing a known solution to an understood problem
2.3. Iterative
2.3.1. Learn more each time
2.3.1.1. Problems visible earlier
2.3.1.2. Planning based on latest knowledge
2.3.2. Fix gaps in knowledge
2.3.2.1. Thought
2.3.2.2. Collaboration
2.3.2.3. Testing
2.3.3. Iterations short enough for regular feedback but avoid thrashing
2.3.3.1. Only take requests between iterations
2.3.3.2. Start with essential features Add more as time and budget allow
2.3.3.3. Track progress to see if on schedule
2.3.3.3.1. Burndown chart
2.3.3.3.2. Tests passed / tests written
2.4. Royce suggested "doing the project twice"
2.4.1. Sub team to investigate areas of uncertainty
2.5. Waterfall is deterministic
2.5.1. Details know at the start
2.5.1.1. People likely to suggest everything that may be useful
2.5.2. Clear contract
2.5.2.1. Managment enjoys the illusion of control & predictability
2.5.2.2. PM focus on scope, cost and schedule over suitability
2.6. Milestones Points where code can be merged
2.6.1. Allows concurrent development
2.7. Synchronisation
2.7.1. FDD
2.7.1.1. Modules have owners
2.7.1.2. Feature collaboration by relevant owners
2.7.2. Span the application ASAP
2.7.2.1. Add depth later
2.7.3. Start with interfaces
2.7.3.1. Allows mocking
2.7.3.2. Allows synchronisation
2.7.3.2.1. Modules can communicate
2.8. Set based development
2.8.1. Consider range of options
2.8.2. Prototype to get the best value (or combination of values)
2.8.3. Use constraints
2.8.3.1. Solution should appear
3. Decide as late as possible
3.1. Breadth first approach
3.1.1. Overview of everything
3.1.2. More time to discover issues that can't be spotted from the depths
3.2. Code that's costly to change is waste
3.2.1. Make changeable areas into modules
3.3. High cost decisions (reduce)
3.3.1. Language
3.3.2. Architecture
3.3.3. Inter system interactions
3.4. Easy to respond to likely changes
3.4.1. Areas changed in development likely to be adapted later
3.4.2. Need adaptability without excessive complexity
3.4.3. Modifications will have cost
3.5. Avoid planning based on guesses
3.6. Absorb changes
3.6.1. Modules
3.6.1.1. Single purpose
3.6.2. Interfaces
3.6.3. Parameters for magic numbers
3.6.4. Abstractions
3.7. Simple rules / checklists
3.7.1. Don't need to wait for management
4. Deliver fast
4.1. Using more recent data for better decisions
4.2. Pull systems
4.2.1. Devs can get their next task
4.3. Queuing theory
4.3.1. Cycle time
4.3.1.1. Average process duration
4.3.1.2. Want to reduce this
4.3.2. Regularly add small amounts of work
4.3.2.1. Leads to consistent rate of progress
4.3.3. Greater utilisation causes longer cycles
4.3.4. Want to reduce bottlenecks
4.4. Cost of delay
4.4.1. If considering a purchase
4.4.1.1. Hours saved against cost not enough
4.4.1.2. Include loss of income & market share
4.4.2. If options have financial cost use that in decision making
5. Empower team
6. Build integrity in
6.1. Conceptual integrity
6.1.1. Ideas work together
6.1.2. System combines
6.1.2.1. Flexibility
6.1.2.2. Maintainability
6.1.2.3. Efficiency
6.1.2.4. Responsiveness
6.1.3. Requires collaboration
6.1.3.1. Info shared
6.1.3.1.1. ASAP
6.1.3.1.2. Small chunks
6.1.3.1.3. Bidirectional
6.1.3.1.4. Face to face
6.1.4. Use existing components when possible
6.1.4.1. Architectural layer patterns
6.1.4.1.1. Presentation (UI)
6.1.4.1.2. [Services (transaction control)]
6.1.4.1.3. Business logic
6.1.4.1.4. [Translation]
6.1.4.1.5. Data source
6.1.4.1.6. Notes:
6.1.5. This helps with percieved integrity
6.2. Percieved integrity
6.2.1. In traditional sdlc requirements go via analysts and designers
6.2.1.1. Multiple degrees of separation from what customers wanted at some point
6.2.2. Better approaches:
6.2.2.1. Customers use sub system protoypes
6.2.2.2. Lead dev knowledgeable about the tech and customers situation
6.2.2.3. Customer and devs use a common model
6.2.3. MDD
6.2.3.1. Conceptual Domain Model
6.2.3.1.1. Overview
6.2.3.2. Glossary
6.2.3.2.1. Ubiquitous language
6.2.3.2.2. Use customer (domain terms) not tech ones
6.2.3.3. Use case model
6.2.3.3.1. User stories
6.2.3.4. Qualifiers
6.2.3.4.1. Considerations for the production environment
6.2.4. Start with abstractions
6.2.4.1. Add details during implementation
6.2.4.2. Communicate at highest viable level
6.2.5. Customer uses model to approve concepts
6.2.6. Unit and regression tests check code
6.2.7. Unt tests and abstract overview should be enough to summarise the system
6.3. Refactoring
6.3.1. New features added
6.3.1.1. If related change architecture to support it
6.3.1.2. Avoids losing conceptual integrity
6.3.2. Must maintain:
6.3.2.1. Simplicity
6.3.2.2. Clarity
6.3.2.2.1. Follow conventions
6.3.2.2.2. Meaningful names
6.3.2.3. No duplicates
6.3.2.4. Fit for purpose
6.3.2.5. Lack of bloat (unrequested features)
6.4. Testing
6.4.1. Describes how a thing should work
6.4.1.1. Is docs
6.4.1.2. Customer tests function as requirements
6.4.1.2.1. Pass
6.4.1.3. Dev tests
6.4.1.3.1. Are the internals working as expected
6.4.2. Checks that it does
6.4.3. Allows changes to be made
6.4.4. Testing vital so repurpose it for documentation
7. See the whole
7.1. System thinking
7.1.1. Considers
7.1.1.1. Parts
7.1.1.2. and their links
7.1.2. Modeling the system shows the impacts of policies
7.1.2.1. Including
7.1.2.1.1. Side effects
7.1.2.1.2. Impacts on other areas
7.1.3. Policies can exacerbate the problem
7.1.3.1. Possibly leading to more rigorous enforcement of the poison policy
7.1.4. A process may help initially but not cure
7.1.4.1. Limits to growth
7.1.4.1.1. Side effects that reduce the gains
7.1.4.2. Shifting the burden
7.1.4.2.1. Problem difficult to fix
7.1.4.2.2. Mask symptoms instead
7.1.4.3. suboptimisation
7.1.4.3.1. Devs working with a part of the system
7.1.4.3.2. They optimise their bit
7.2. Measurements
7.2.1. Can be dangerous
7.2.1.1. Wrong metrics
7.2.1.2. Incomplete set
7.2.1.3. These number look good, so encourage a bad direction