Lean software development

From CEOpedia | Management online
Revision as of 18:17, 1 December 2019 by Sw (talk | contribs) (Infobox update)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Lean software development
See also


The lean software development is related to Agile project management. It translates lean manufacturing ideas into domain of software development.

7 wastes of software development

The idea of waste is present in LSD, however other types of waste are important:

  1. Work done partially
  2. Extra processes
  3. Extra features
  4. Task switching
  5. Waiting
  6. Motion
  7. Defects

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

Many lean enthusiasts talk about excellence, not value. Wrong. The lean is about value. The customer's requirements should be fulfilled at reasonable cost, low risk, in time.

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

There are many technologies available. The team should choose one that is best for the problem. Starting with chosen technology or working with only one technology will reduce your market share.

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:

Eliminate waste

  1. Seeing waste - every employee should be trained to see the waste in software development (see: 7 wastes above)
  2. Value stream mapping - project managers have to understand how value for the customer spreads in the project

Amplifying learning

  1. Feedback - in modern, agile projects feedback generates substantial value. It helps to remove problem, improve features, etc.
  2. Iterations - help respond to facts, synchronize, force decision making
  3. Synchronization - small batches of work have to be synchronized. Tests of builds help in synchronization.
  4. Set-based development - start with constraints and select best choice rather than start with one choice and refine it.

Deciding as late as possible

  1. Options thinking - delay decisions, because they can be irrevocable. Get more information, use Just in time for lean development
  2. 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.
  3. 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

  1. 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.
  2. 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
  3. Cost of delay - an economic model should empower team members to figure out for themselves what is important for business

Empower the team

  1. Self-determination - help the workers to engage rather than set the tasks. Managers are part of the team.
  2. Motivation - compelling but achievable purpose helps keep motivation high
  3. Leadership - leadership shouldn't be restricted to managers. Leaders shouldn't be cheerleaders.
  4. Expertise - share expertise, enforce standards

Build integrity in

  1. Perceived integrity - focus on keeping customer values first, use model driven design
  2. Conceptual integrity - measure how well components work, reuse existing solutions
  3. Refactoring - complex systems lead to effects that aren't fully understood at design time
  4. Testing - feedback from tests should be as quick as possible, daily builds, automated tests.

See the whole

  1. Measurement - track the progress, measurement helps keep high performance of workers
  2. Contracts - agile approach requires cooperation, not taking advantage of other side

References

Author: Slawomir Wawak