Operating a Lean Software Engineering & Product Development Team

During the past several years, I have read quite a bit about lean software engineering, and as a leader have also mentored teams on the benefits and required process & cultural changes that may need to occur. I have documented (and frequently added new or updated content) a reference sheet that outlines what I believe to be the core elements, and have included this below to share with others.

As a Team >> The Seven elements of Lean >> Applied to software development

  1. Eliminate Waste by avoiding anything that is unclear, unproductive, inconsistent, or unreasonable
    1. User stories that are not small, meaningful, and testable, with thoroughly defined acceptance criteria are sent back
    2. Clean and simple code using examples such as SOLID, DRY, YAGNI, and DDD design principles
    3. Define and limit work in process (WIP)
    4. Avoid frequently changing requirements
    5. No room for bureaucracy, slow, or ineffective communication.
    6. Work must be complete without known defects and quality issues
    7. Minimize task switching
  2. Build Quality in from the start, which is obviously extremely important, or you inevitably create all sorts of waste further down the line. Build it in as early as possible in the process to avoid quality issues materializing, and build it in throughout the entire development process, not just at the end.
    1. Frequent code reviews required prior to stake holder review, courteous feedback regarding adherence to defined standards
    2. Unit (80% coverage or greater) and Integration Tests are required, using Test Driven Development when possible
    3. Minimize time between stages
    4. Design before coding (Minimum Viable Documentation/Diagrams)
    5. CI/CD is at the core of the process
    6. Configurable logging will be used in all layers of the application
    7. Manage Tradeoffs and always consider the value stream of the customer, and always think about long term and scale of the application you are building for.  Don’t over or under architect, instead build for extensibility.
  3. Create Knowledge which will help the long-term productivity and flexibility of the team. Take actions in the short term to create and share knowledge.
    1. Pair Programming when working on complicated tasks
    2. Code reviews
    3. Self-documenting code and architecture, Minimum Viable Documentation when necessary
      1. Simple but meaningful naming conventions, and consistent coding styles
    4. Knowledge sharing sessions
    5. Training and Learning Opportunities
  4. Defer Commitment and decide as late as possible to avoid rework, particularly for decisions that are irreversible, or at least will be impractical to reverse.
    1. Time box critical decisions for the latest point they can be made without causing problems.
    2. Keep your options open for as long as possible, analyze just prior to development 
    3. Architect your solution to be simple, flexible, and extensible
  5. Deliver Fast to gain “First Mover Advantage”.
    1. Simple solutions incrementally based on real customer feedback
    2. Pitch in to help others who are behind
    3. “That’s not my job” does not apply, anywhere!
    4. Minimize lead time to avoid stale or changes in requirements
    5. Simple, frequent, and clear communication channels with decision makers
  6. Respect yourself & others regardless of their role within the team or organization.
    1. Challenge and be assertive, without sounding aggressive, threatening or argumentative
    2. Decisions are thought out, made in a timely manner, and with support of the team.
    3. There is no place for Egos or “Hero Syndrome”, anywhere!
  7. Optimize the Whole by focusing on the entire value chain and not just individual teams or functions
    1.  Reduce hand-offs when possible, and make sure someone owns it from beginning to end
    2. When possible, teams are complete, multi-disciplined, and co-located, consisting of functional teams as opposed to product teams, and they will have all the roles and skills needed to deliver from beginning to end.
    3. Promote sense of ownership, accountability, commitment, quality, innovation, team spirit, and cooperation.

The 8 sources of Waste taken from Taiichi Ohno (and modified by Jeff Mangan), who created a lean manufacturing framework, based on the idea of preserving (or increasing) value with less work. Anything that doesn’t increase value in the eye of the customer must be considered waste, or “Muda”, with the acronym for the eight wastes is DOWNTIME:

  • Defects
  • Overproduction
  • Waiting
  • Not utilizing talent
  • Transportation
  • Inventory excess
  • Motion waste
  • Excess processing

#1 Defects

Mistakes that require additional time, resources, and money to fix.

  • Poor quality controls
  • Poor repair
  • Cryptic and meaningless naming conventions
  • Lack of standards
  • Weak or missing processes
  • Misunderstanding customer needs
  • No WIP limits
  • Poor design or task break-down

Completely eradicating any form of waste is impossible, but defects can certainly be limited by the application of standardized work plans, more stringent quality control at all levels, a full understanding of work requirements and customer needs, and simple job aids such as task lists.  When troubleshooting and debugging, do not get wrapped up in “Paralysis by Analysis”.  Spend no more than 1 hour or less, and if still stuck ask for help, leverage your team members.

#2 Overproduction

Blindly keep producing things that are not needed Right Now. This can tie up resources, eat up budgets, complicate systems, and introduce defects.

  • Poorly defined and prioritized backlog
  • Unclear customer needs
  • Relying on a predicted forecast
  • Engineering changes or task switching
  • Poorly applied automation

The solution is to establish a reasonable work flow for the benefit of the customer, monitor WIP, and continuously retrospect.

#3 Waiting

This occurs whenever work must stop for any amount of time: dependencies such as detailed processes, or lack of tools and materials, waiting for requirements. Causes can include:

  • Unbalanced workloads
  • Unplanned downtime
  • Lack of automation
  • Insufficient staffing or complex team structures and division of labor
  • Poor communication
  • Poor task breakdown
  • Too many specialists
  • Deep approval and documentation processes

Whatever the cause, some workers must wait for a bottleneck to be cleared. One way to address this is the need to provide adequate staffing to handle the workload at the bottlenecks, which some managers may target as a source of monetary waste.  A good way to make bottlenecks visible is a properly prioritized backlog.

#4 Not-Utilizing Talent

While not part of TPS’s seven wastes, such as not or under-utilizing peoples’ talents, skills and knowledge can cause employees to lose interest or motivation. Value of skills and improvement ideas from all levels of the business need to be recognized. This can typically be seen with:

  • Assigning staff to wrong tasks
  • Wasteful admin tasks
  • Poor communication
  • Lack of teamwork
  • Poor management / leadership
  • Insufficient training

Many of these failings are the same ones that result in a lack of employee engagement, which can reduce productivity. Key solutions include empowering your employees, stop micromanaging and increase training.

#5 Transportation

Waste caused by un-necessary movement. Too much transportation tends to increase costs, wastes time, and can result in increased failure rates. In general, transportation waste can be caused by:

  • Lack of automation
  • Complicated deployment process and development cycles
  • Misaligned process flow
  • Poorly-designed operations

Limiting transportation waste can be easily addressed by common-sense efforts such as simplifying processes, automation, making distances between steps as short as possible.

#6 Inventory Excess

This waste occurs when too many features are created and by building more features than the actual customers demand, which hinders value adding feature development. Causes include:

  • No way to measure value and usage of completed features
  • Lack of customer involvement and feedback on feature development and prioritization
  • Poorly planned or unrealistic time frames and expectations
  • Lack of communication between separate teams
  • Misunderstood customer needs

This can be mitigated by limiting WIP, and following the principles of agile software development (and scrum for example)

#7 Motion Waste

Any excess “people” movement that doesn’t add value to the product, service or process. Typical causes include:

  • Poor communication flows
  • Poor workstation/office layout
  • Workstation congestion
  • Isolated or physically separated teams
  • Lack of standards

The solution here is to re-arrange layouts to decrease the distance between team members, and make it easier to reach customers, stake holders, etc…

#8 Excess Processing

This often occurs due to the creation of multiple decision makers, process more than is required or long-winded poorly designed processes. Examples include:

  • Excessive reports
  • Making assumptions on processes that have not been validated as absolutely necessary or value adding
  • Multiple signatures
  • Re-entering data and duplicated data
  • Lack of standards
  • Poor communication
  • Misunderstanding of the customer’s needs
  • Human error

All of this unnecessarily increase your costs, time and resources. You must first examine and map your organization to analyze the processes in order to fix them.
Standardize processes, empower employees and eliminate unnecessary documentation, sign-off processes and meetings.

  • flow = F(density,velocity)
  • full utilization = congestion (like traffic) – Muri

Definitions

  • Muda means wastefulness, uselessness and futility, which is contradicting value-addition.
  • Mura means unevenness, non-uniformity, and irregularity. Mura is the reason for the existence of any of the seven wastes. In other words, Mura drives and leads to Muda.
  • Muri means overburden, beyond one’s power, excessiveness, impossible or unreasonableness. Muri can result from Mura and in some cases be caused by excessive removal of Muda (waste) from the process. Muri also exists when machines or operators are utilized for more than 100% capability to complete a task or in an unsustainable way

This document was created by Jeff Mangan, and continuously updated over the past few years.

Leave a Reply

Your email address will not be published. Required fields are marked *