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:
1. 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:
- LSSC11 conference website
- LeanSSC Linked in Group
- LSSC11 conference Facebook page
- LSSC11 conference Plaxo Group
- Twitter accounts: @LeanSSC
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:
- Session 1: Lean Decision Making
12:00pm-1:00pm PST. Tuesday, January 18, 2011
Presenter: David Anderson
- Session 2: Introduction to Kanban
12:00pm-1:00pm PST. Wednesday, February 2, 2011
Presenter: Janice Linden-Reed
- Session 3: Lean-Agile For Executives
12:00pm-1:00pm PST. Wednesday, February 23, 2011
Presenter: Alan Shalloway
- Session 4: Intro to Lean Product Development Flow
12:00pm-1:00pm PDT. Wednesday, March 16, 2011
Presenter: Yuval Yeret
- Session 5: Systems Engineering
12:00pm-1:00pm PDT. Wednesday, April 6, 2011
Presenters: Jim Sutton and Richard Turner
- Session 6: Kanban and CMMI
12:00pm-1:00pm PDT. Wednesday, April 27, 2011
Presenter: Hillel Glazer
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!