In recent years we have found that a focus on flow (lean), rather than a focus on waste elimination (agile) is proving a better catalyst for continuous improvement within software development.
Lean Software Development has emerged as its own discipline – not specifically a subset of the Agile movement but certainly related to Agile.
Lean is based on two fundamental principles – first, one must take a systemic view to improvement and second, one must do this by looking at the flow of work though the system. The first is a shift from managing people to improving the systems within which people work. The second is a shift from focusing on productivity directly to removing delays in workflow to increase productivity.
The 7 principles of Lean software development were inspired by the original Lean principles developed by Toyota.
Principle 1: Eliminate Waste
Waste is defined as; Anything that interferes with giving users what they value.
Inventory is waste; In software thats incomplete work
Requirement Churn; Software built against the backdrop of rapidly-changing or late changing requirements often means one thing – changes!
Requirements specified long before coding begins
Testing occurs long after coding was finished
Delays in integration of code into our production environment
Overproduction; Low priority/value features are developed. 66% of features in bespoke software are rarely or never used.
Principle 2: Build Quality In
Don’t focus on logging defects in a bug tracking system – avoid creating defects in the first place.
Defect tracking systems are another example of partially done work
Implement Test Driven Development (TDD) and Continuous Integration
Write Less Code – Keep your code base simple, Refactor often
Expect to change existing code
Principle 3: Create Knowledge
Software is a knowledge creating process
Validation of architecture comes as the code is being written
An early design cannot fully anticipate the complexity encountered during implementation
Expect the design to evolve
Release a minimal feature set to customers for evaluation and feedback
Daily builds and rapid feedback from integration tests
Create a modular architecture that has the ability to add new features easily
Encourage systematic learning throughout the development cycle
Don’t act as if our predictions of the future are fact – but rather a forecast.
Principle 4: Defer Commitment
Schedule irreversible decisions for the last responsible moment
Endeavour to make decisions reversible
Avoid making decisions that will lock in critical design decisions that are difficult to change
Principle 5: Deliver Fast
Find a way to deliver software so quickly that our customers don’t have time to change their minds
Organisations that compete on the basis of time;
Have a significant cost advantage
Eliminate a huge amount of waste
Low defect rates
Repeatable and reliable speed needs to be in tandem with superb quality
In fast-moving companies work is structured so our people doing the work know what to do without being told.
Our people are expected to solve problems and adapt to changes without permission
Principle 6: Respect People
Hire an entrepreneurial leader!
An organisation that respects its people develops good leaders.
Ensure your teams have the kind of leadership that fosters engaged team members focused on creating a great products
Expert Technical Workforce
Appropriate technical expertise is nurtured
Teams are staffed with needed expertise to accomplish their goals
Responsibility-Based Planning and Control
Teams are given general plans and reasonable goals and are trusted to self-organise to meet their goals
Principle 7: Optimize the Whole
A lean company optimises the whole value stream
Vicious Circle 1
Customer wants a new feature “yesterday”
Developers hear: Get it done fast!
Result: Sloppy changes made to the code base
Result: Complexity of the code base increases
Result: Number of defects in code base increases
Result: An exponential increase in time to add features moving forwards
Vicious Circle #2
The testing team is overloaded with work
Result: Testing occurs long after coding has finished
Result: Developers don’t get immediate feedback
Result: Developers create more defects
Result: Testing has more work. Systems have more defects
Result: Feedback to developers is delayed further. Repeat cycle.