What Goes Around Comes Around in S/W Development… Let’s minimize the rework with Lean!

Posted on January 5, 2011 | 6 Comments

If you don’t have time to do it right, when will you have the time to do it over? (aka Do it Right the First Time).  There has to be a better way (and there is)!

Rework… what a waste (literally)!

Rework is one of the most frustrating aspects of software and systems delivery, especially when you consider that over 40% of IT development effort is spent doing rework (stats hover around 45% according to published reports from the Department of Defense).  Why is rework so high in software development?  There are many reasons including incomplete or unclear requirements, customer changes (since the beginning of the project), and elongated timelines.  Can you imagine what our life would be like if every industry was plagued by this amount of rework?

  • Construction would take two to three times as long to complete (imagine construction without sealed engineering drawings!)
  • Medical surgeries would mean that patients would have to endure multiple operations to get the original job done properly (I can hear the lawyers applauding already)
  • Clothing manufacturers would have to double their prices because of waste due to improperly cut or sewn garments

Few other industries would tolerate this level of rework…  yet IT not only tolerates rework (in the hope of delivering a product that achieves high customer satisfaction), but most projects end up late, over-budget, and delivering unnecessary or incorrect functionality.  Often projects are rushed through when schedule crunches and rework overwhelms them, or functionality or quality is sacrificed to finish on time.  In either case, results include inadequate software product releases, with costly follow-on maintenance to correct poor quality or product deficiencies.

When Phillip Crosby wrote his award-winning book “Quality Is Free”, many professionals mistakenly thought the title meant that there is no cost to building quality into product development. Today we know that Crosby meant that quality pays for itself in the long run – and ultimately reduces product development costs.  Unfortunately, the idea of doing things right the first time is still a pervasive challenge in IT – and not all the blame lies with the software development team.  Rework, poor quality, crunched schedules, inadequate budgets, and poorly documented requirements are a shared responsibility of both the business customers (who need the software) AND the software developers.

Since the mid-1900’s, other industries such as manufacturing embraced evolutionary approaches to reducing rework, shortening development delivery cycles, cutting out waste and delays, and scoping out smaller bits of functionality to deliver incrementally, with transformational results.  Today a handful of the best practices have been adapted and tailored for use in software and systems development and offer similar transformational results to the IT industry.  Approaches like Kanban, LEAN, JIT (just-in-time), and others  make complete sense and increase team morale and the quality of the resultant software products, while reducing waste.

If you’ve never heard of Kanban, Outcome-Driven-Development, Lean Software and Systems Development, or a myriad of other named approaches, you might be out of touch – but you are also in luck, because there are resources available to get you quickly up to speed.

I’d like to mention a couple of notable resources here:

LSSC11-logo1. The Lean Software and Systems Consortium (LeanSSC) is hosting their second annual Lean Software and Systems conference (acronym LSSC11) to be held 3-6 May, 2011 in Long Beach, CA at the Hyatt Regency Hotel. Here’s a few important links that may be of interest:

2. Upcoming FREE webinars:

The Lean Software and Systems Consortium (LeanSSC)is hosting a series of FREE webinars commencing on January 18, 2011 to educate professionals who want to improve the productivity and quality of their IT delivery. Register today for one or all of these webinars.  Here’s the upcoming schedule of topics and dates for the webinar series:

If you are like me and catching up with all the Lean terminology…

I’m going to be posting frequently in the coming weeks and months about concepts, ideas, and general software development related to Lean, Kanban, Multi-modal approaches, and other topics – I hope that these will help you to catch up and help your company leapfrog ahead of your competition in software development.  And, I’d like your comments and feedback on what you think!

I’ll end this post with a couple of (what I consider) essential snippets:

  • Lean Software & Systems Consortium (LeanSSC) is a global, non-profit organization whose mission is to promote and create awareness of Lean Thinking applied to software and systems engineering and associated competencies.
  • From David J. Anderson on Yahoo discussion group kanbandev:  “I’ve jokingly referred to Kanban as “Outcome Driven Development” recently on Twitter. Some people thought I was joking 😉 as the ODD method hardly seems sensible! You are deciding the outcome you want (from a small change). You want code tested early to avoid it going stale. You want it tested while it is fresh in the minds of those who created it. You also want testing exposed as a bottleneck. You want the test bottleneck made visible/transparent/explicit. You seek to do this through a process (or system) change that introduces a WIP limit. Your hope (based on an understanding of theory, so it is a belief based on a scientific understanding) is that by setting a WIP limit you will expose the bottleneck and provoke further discussions that will change behavior, resulting in the outcome you desire. Your leverage point is the WIP limit. The WIP limit is the actuator you are using to stimulate emergent (desirable) behavior.”

Happy 2011 and I hope you’ll pass on this post to others who may be interested.  Join us on one of the Facebook, Plaxo, LinkedIn or other LSSC11 groups.  You’ll be glad you did!

Regards,
Carol Dekkers
Share

This entry was posted in Articles, software development, Standards, Technology conferences and tagged , , , , , , , , , , , , , , , , , , , , , , , , , . Bookmark the permalink.

6 responses to “What Goes Around Comes Around in S/W Development… Let’s minimize the rework with Lean!”

  1. James L. Hutchins | January 6, 2011 at 3:34 am | Reply

    First, I would not be so filled with self righteous dignity as to laugh at CArol of all people. She represents one of those on a cusp of a knowledge base to gather information and disiminate (sic) it.
    Second, as a longtime SQE practitioner I am ever amazed time and ‘gain with the thought that hardware development and software development are so similar as to be comparable. Where hardware development has MRB activities to correct errors in effort software does not, as a rule, become aware of errors in development until well into the testing process. Then, usually, only then the does the corrective process become active. It is far harder without thorough active review process is the requirement development, block code development and interface grouping that the disease of poor software development be cured.
    Third, those that take Crosby’s maxim as gospel are like a man who reads “The Origin of the Species” and believe the text is in conflict with the Bible. The same as earlier Taylor and Figenbaum were looked upon as end all to the questions of quality. Each solves problems/anomalies within their own time. As the times grow, those problems/anomalies evolve demanding we find newer more immediate resolutions.
    Finally, to those who gather further joys or sorrows with the coming of software development programs/projects. Each new one presents not only opportunities but exigencies (sic) which can confound and entice the mind.

    Like

  2. Robert Merrill | January 6, 2011 at 9:54 am | Reply

    Curiously absent is any mention of the A-word. Or XP. Or Scrum. Or DSDM. I’m no methodology purist, but these rest on the same empirical process control foundation. Why not inform readers, who might not otherwise know, about this large body of proven approaches as well?

    Like

    • Carol Dekkers | January 6, 2011 at 4:04 pm | Reply

      Robert,

      Of course you are correct with your comment about the other approaches including Agile, XP, Scrum, DSDM… etc. No disrespect intended by the exclusion and in fact, I’d welcome additional links if you’d like to include them in a follow-on comment. It’s kind of like coming late to a party where everyone else has already been introduced and if I can rely on kind hosts like you to introduce me around, I’d be grateful.

      Thanks for reading and commenting!
      Carol

      Like

  3. Agile Scout | January 9, 2011 at 3:58 pm | Reply

    Thanks for sharing. Totally agree. I was thinking about this earlier this year. I mean, IT industry allows for all this re-work… crazy notion!

    Like

  4. Project Management Tools That Work (Bruce) | January 14, 2011 at 12:12 pm | Reply

    The great thing about software is that it is so easy to change. Try this, try that, backup, try something else. We want to leverage this characteristic in our methodologies – not stamp it out as some folks felt waterfall approaches tried to do. Of course this ease of change encouraged “let just do it” software approaches and we found ease of change became an excuse for a lack of any discipline.

    Crosby and Deming both focused on quality first. In my first 10 years in the industry, when I had little control over schedules/budgets/requirements, we delivered products on time because we focused on quality first – getting it right the first time – and not the schedule or budget (much to the chagrin of more senior management). Getting it right the first time was centered as much on the process as it was the product (lines of code in this case). It is amazing what even a small team of a half dozen can accomplish when they write code that works the first time.

    It is also amazing the productivity of programmers when they don’t have to spend inordinate amounts of time with testers and builders helping them to sort out what is wrong with the software (and then fixing it). Costs go down as we don’t need as many programmers working on the same product to get everything done. (See http://pmtoolsthatwork.com/high-quality-gives-high-productivity-no-extra-cost/)

    Regards,

    Bruce

    Like

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.