DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

Waste #5: Delays

Matt Stine user avatar by
Matt Stine
·
Sep. 13, 10 · Interview
Like (0)
Save
Tweet
Share
24.54K Views

Join the DZone community and get the full member experience.

Join For Free
Welcome to episode five of our series "The Seven Wastes of Software Development." In episode one, we introduced the concept of eliminating waste from our software development efforts. Waste elimination can be traced all the way back to the the mid-1900's, the birth of lean manufacturing, and the Toyota Production System (TPS). This is how Taiichi Ohno, the father of the TPS, described its essence:

All we are doing is looking at the time line, from the moment the customer gives us an order to the point when we collect the cash. And we are reducing the time line by reducing the non-value adding wastes. [1]


In this episode, I'd like to focus on "Delays." Simply put, delays are anything that either delay the start of a value adding activity or that make a value adding activity take longer than it should.

Read the other parts in this series:

  • The Seven Wastes of Software Development - Introduction
  • Waste #1 - Partially Done Work
  • Waste #2 - Extra Features
  • Waste #3 - Relearning
  • Waste #4 - Handoffs
  • Waste #5 - Delays
  • Waste #6 - Task Switching
  • Waste #7 - Defects

Here are some common manifestations of delays in software development:

  1. Starting development work on a project long after the initial customer contact or requirements gathering activities;
  2. Waiting for appropriate staffing to become available to start working on a project;
  3. Lengthy requirements documentation phases that attempt to exhaustively specify every aspect of a project;
  4. Review or approval processes that act as gates between development process phases and that require the attention of a scarcely available individual;
  5. Increased work in progress. Think about what happens on the freeway at rush hour. The more cars you try to shove onto the road, the slower the flow of traffic becomes;
  6. Gaps between the completion of development work and the beginning of QA/verification work;
  7. Gaps between the completion of verification work and the beginning of deployment.


Any of these delays will create serious problems in any software development environment, and each of them are pandemic.

Unlike the wastes we've looked at previously (partially done work, extra features, relearning, handoffs), there isn't really a process improvement spectrum around delays. Delays either exist, or they don't. Your goal is simply to eliminate them.

So why are delays so bad? Two primary reasons:

  1. Delays prevent your customer from realizing value as soon as possible. Even if you remove all non-value adding activities from your process, any delay between the remaining value-adding activities adds no value. In fact, it can even have a net-negative affect on value if the delay reduces your customer's competitive advantage, profit margin, etc.
  2. Delays introduce discontinuity into your process, and just as Type O blood is the universal donor type, discontinuity is the universal waste creator. Discontinuity always spawns instances of the other wastes:
    • Delays trigger task switching. If you don't have all of the knowledge that you need to complete your task, and you have to wait for that knowledge, then you can either sit idle or switch to another task. Either way, you're task switching and you've lost flow.

    • By triggering task switching, delays trigger partially done work.
    • Delays fuel relearning by lengthening feedback loops. Requirements that are gathered far in advance of development become obsolete and must be regathered. Defects that lie undetected in a QA wait queue force relearning as developers swap the related knowledge back in to address them.
    • In the same way, delays fuel extra features through those same lengthened feedback loops. It's quite possible that, given long delays between product demos, that we'll build to completion features that the customer no longer needs nor wants.
    • Delays between coding and testing, be it at the unit or acceptance level, increase the impact of defects by allowing them to lie undetected longer.

So what are some ways that we can attack delays?

Build complete project teams. Ensure that all of the individuals possessing all of the knowledge necessary to carry the project to a successful delivery have skin in the project game.
To the best of your ability, ensure that your teams are collocated. Face-to-face communication is the most effective means for sharing knowledge within a project team, and even teams separated by only an elevator ride or stair climb will have less face-to-face interaction. Get all of the project team in the same room if at all possible.
Use short timeboxed iterations and deliver value to the customer at regular intervals.
Seek out regular feedback, even in the middle of an iteration, and act on it immediately.
Ensure that knowledge is always made available at the timeliest moment. Don't make it available too soon, or it will become obsolete. Don't make it available too late, or its value will be negated.

That's all for this episode of "The Seven Wastes of Software Development." Stay tuned for the next installment: Task Switching.

References

[1] Poppendieck, Mary and Tom. Implementing Lean Software Development: From Concept to Cash. Addison-Wesley, 2006.

Software development

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • A Simple Union Between .NET Core and Python
  • Data Mesh vs. Data Fabric: A Tale of Two New Data Paradigms
  • Connecting Your Devs' Work to the Business
  • The Importance of Delegation in Management Teams

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: