Difference between revisions of "Lean software development"
|Line 15:||Line 15:|
The '''lean software development''' is related to [[
The '''lean software development''' is related to [[management]]. It translates [[lean manufacturing]] ideas into domain of software development.
==7 wastes of software development==
==7 wastes of software development==
Revision as of 15:49, 13 July 2019
|Lean software development|
7 wastes of software development
The idea of waste is present in LSD, however other types of waste are important:
- Work done partially
- Extra processes
- Extra features
- Task switching
See extended version in article 7 wastes of software development
Principles of Lean software development
The description of 22 tools of LSD (see below) provides another set of principles. In literature both are treated as LSD principles. They aren't contradictory, however one of the list might be more convenient for some organizations.
1. Satisfying the customer is the highest priority
It is very easy for programmers to forget about the customer. Programming requires competences that most of the customers don't have. The final product however has to be user-friendly and fulfil customer's requirements.
2. Always provide the best value for the money
3. Success depends on active customer participation
The customer can get greater value from the software that was created with his participation. It is often misunderstood by customers. They want to pay and have great software. Fortunately, this approach changes over time.
4. Every lean development project is a team effort
The projects should be run by multidisciplinary teams, not individuals. Diversity creates innovation, team work reduces time of development.
5. Everything is changeable
Panta rhei - everything flows. In lean software development we assume that everything can change. Running business these days requires changing something almost everyday. The software that was ordered can be useless on delivery. Moreover, the requirements can change after delivery. The software should be ready for changes. This creates opportunities for the software company.
6. Domain, not point, solutions
Creating solutions solving one problem is not cost effective. Better to create extensive systems, with many modules which can be configured for different customers.
7. Complete, don't construct
Using pre-fabricated software, models, frameworks helps shorten time and resources required to create software.
8. An 80 percent solution today instead of 100 percent solution tomorrow
Beta versions are everywhere. Customers have got used to 80% solutions, because they pay off faster. It keeps them up to speed with markets.
9. Minimalism is essential
Focus on project, keep the team small, minimize paperwork.
10. Needs determine technology
11. Product growth is feature growth, not size growth
Every additional feature should be design flexibly, to be able to quickly adjust to changes. The features can be influenced by changes in business, but also business can be influenced by new opportunities created by features.
12. Never push lean development beyond its limits
The lean software development is about increasing revenue, reducing costs, creating value for the customer. If you have other objectives - use other methods. Lean is not religion.
22 Tools of LSD
The LSD uses several approaches. Each of them comes with separate tools:
- Seeing waste - every employee should be trained to see the waste in software development (see: 7 wastes above)
- Value stream mapping - project managers have to understand how value for the customer spreads in the project
- Feedback - in modern, agile projects feedback generates substantial value. It helps to remove problem, improve features, etc.
- Iterations - help respond to facts, synchronize, force decision making
- Synchronization - small batches of work have to be synchronized. Tests of builds help in synchronization.
- Set-based development - start with constraints and select best choice rather than start with one choice and refine it.
Deciding as late as possible
- Options thinking - delay decisions, because they can be irrevocable. Get more information, use Just in time for lean development
- The last responsible moment - if the decision is not made in that moment, some alternatives are eliminated - the default decision is made. Default rarely means best.
- Making decisions - most of problems should be solved as late as possible to keep the alternatives open, however if the problem is new and complex, or the team has an expert that is able to make correct decisions, it might be more effective to reduce complexity right in the beginning.
Delivering as fast as possible
- Pull systems - you can tell workers what to do, but if you have knowledge workers, as in most software projects, it might be better to let them task themselves. Set the dates and let them work.
- Queueing theory - queues should be as short as possible because waiting is waste. Release small packages of work, observe how the work arrives and how the process works
- Cost of delay - an economic model should empower team members to figure out for themselves what is important for business
Empower the team
- Self-determination - help the workers to engage rather than set the tasks. Managers are part of the team.
- Motivation - compelling but achievable purpose helps keep motivation high
- Leadership - leadership shouldn't be restricted to managers. Leaders shouldn't be cheerleaders.
- Expertise - share expertise, enforce standards
Build integrity in
- Perceived integrity - focus on keeping customer values first, use model driven design
- Conceptual integrity - measure how well components work, reuse existing solutions
- Refactoring - complex systems lead to effects that aren't fully understood at design time
- Testing - feedback from tests should be as quick as possible, daily builds, automated tests.
See the whole
- Measurement - track the progress, measurement helps keep high performance of workers
- Contracts - agile approach requires cooperation, not taking advantage of other side
- Presentation of Lean Software Development tools and approaches (PDF)
- National Institute of Standards and Technology website
- Lean Enterprise Institute website
- Ballé, F., & Ballé, M. (2005). Lean development. Business Strategy Review, 16(3), 17-22.
Author: Slawomir Wawak