How To Improve the Quality of Your Software While Improving Your Time-To-Market

April 5, 2012 — Posted by Al Shalloway

This is the third of a three part series. The first two were:

  1. The Cause of Poor Software Quality
  2. Quantifying the Return from Improving Software Quality

The key to improving software quality lies in selecting the right products to build and removing the delays in the workflow. Understanding Lean-Flow can be incredibly valuable in taking action on starting this.

Lean-Agile methods focus on reducing time to market by:

  1. focusing on the most important features to build
  2. avoiding delays that cause additional work by avoiding overloading teams
  3. improving the workflow of the development teams to avoid delays that cause additional work
  4. improving software quality
  5. reducing the complexity of a product's code base both by having higher quality software and by not writing software that is not needed

All of these improve time-to-market since they focus on removing delays to the overall process. Lean-software suggests that to do this we must remove the delays between the steps. Removing delays between the steps has the dual benefit of shortening time to market as well as improving quality. Quality improves because errors will be detected sooner and less work will be created from the delays (see How Delays Cause Waste: A Main Tenet of Lean).

When more than a team is involved, Lean-Agile must work at four levels:

  • the business side has to improve getting better at identifying, sizing and prioritizing the work to be done (proper product portfolio management). This has two advantages:
    • the most important features are worked on
    • this focus makes it easier for the business stakeholders to avoid overloading their teams (thereby raising their efficiency)
  • mid-management must work so that work is given to the teams in a coordinated manner (proper product management)
  • teams must learn how to discover, build and deliver incrementally with Agile methods (Scrum, Kanban, hybrid approaches)
  • teams must learn how to build software correctly (the use of design patterns along with test-first methods such as acceptance test-driven development and TDD)

Where to start requires an holistic view of the entire system. One must consider:

  • Who is the sponsor for the transition?
  • How well are the stakeholders selecting what to create?
  • What is blocking flow?
  • How much change will be required to create cross-functional teams?
  • What is the culture of the organization?
  • What is the level of technical debt of the product?
  • What should our pilot project's goal be? (it's not always just to succeed, but often requires testing some assumptions about how Agile will work in the organization)

The answers to these questions will inform your method of starting. Very often an assessment is advisable. Other times spinning up a team with Kanban or Scrum is great. Changing how your product portfolio management is being done can also be the key. The question is, what's going to provide the biggest return for the effort you can make? I'd caution against following anyone's suggestion that they always feel is applicable. As context changes, approaches must change as well.

Some things we've seen almost always help are:

See Where to Begin Your Transition to Lean-Agile for more on selecting where to start.

And, of course, I always like to be contacted for help as well.

Alan Shalloway
CEO, Net Objectives

Author: 

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With over 40 years of experience, Alan is an industry thought leader in Lean, Kanban, product portfolio management, SAFe, Scrum and agile design.



        

Free Email Updates!

Sign up for free email updates from
Net Objectives Thoughts Blog

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Software Design, Design Patterns, Technical Writing, TDD, ATDD, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, SAFe, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile