December 22, 2003
XPDAY - Mary Poppendieck, Tom Poppendieck - Lean Development - Tuesday 2nd December 2003
Waste is anything that doesn't create value for the customer. If the customer would be as happy without something, then don't do that something.
Value Stream Analysis - [Ant see this entry for a little more on that]
Increase Feedback
For fixing troubled projects, increase feedback at customer, team and management levels. A lack of feedback somewhere in the chain is the most common area for improvement in project debriefs.
Make change inexpensive. You can do this by:
- delaying commitment
- sharing partially complete design information
- developing a sense of how to absorb changes
- avoiding extra features
- developing quick response capability
- developing a sense of when to make decisions
Encapsulate variation
Group what is likely to change together inside one (code) module so that interdependencies are intrinsically linked.
Separate Concerns
A module should have only one responsibility. Don't make them dual purpose.
Avoid Repetition
Don't repeat yourself. Never copy and paste code.
Defer Implementation
Functionality doesn't have to be made till the order is recieved.
Deliver fast - rapidly, reliably, repeatedly
- Wait till there's a need before you start to build. This is a good incentive or way of 'pulling' your requirements out
- Don't 'push' with a schedule, you can't keep them up to date. Too much in a project's life changes and its wasted time updating them.
- Make work self-directing through the use of a visual workplace whereby staff can see what state elements of the project are in
- Rely on local signalling (like a Daily SCRUM or other methods for communication between team members)
- Do small batches
Queuing Theory
- Steady rate of arrival (short iterations)
- Steady rate of service (test features immediately)
- Small work packages (integrate features individually)
- Reduce utilisation (you don't load servers to 90%... productivity in staff drops off exponentially after around 70-80%)
- Eliminate Bottlenecks (Everyone piteches in, when and where ever they are needed... yes this means multiskilled staff)
Lean means introducing a gating mechanism so that full capacity is never reached. Lots of half done stuff IS BAD and is the result of overloading. Just as a highway gets choked up when there's too much traffic, the same happens in a workplace when it is overloaded with work.
Build Integrity In
- Perceived – totality – overall customer delight
- Conceptual – the system's components work well together
The way to build both perceived and conceptual integrity is to ensure all aspects of a business are included in the design process. There are 4 questions to answer which cover all aspects.
- Why are we doing this? This is the business drivers question
- The Vision
- Success Model
- Priorities
- Capability
- What needs to be done?
- User Experience Design
- Acceptance Tests
- User Tests
- Use Cases
- How do we build it?
- Programming methods (e.g. XP)
- Technological platforms
- How do we support it?
- Ask your support team to be involved in the design process
Empower the team
Kaizen Events are a way to bring a multidisciplinary team together to improve a process or product. The order in which they are done is as follows.
- Bring team together
- Set the challenge
- Brainstorm Solutions
- Present recommendations
- Decide at a "town meeting" (merely where all stakeholders are consulted)
- Implement immediately
Posted by Ant at December 22, 2003 05:57 PM | TrackBack
I'm currently reading your book "Lean Software Development". Many of your points are salient. Howevre, I believe the belief that a certain amount of waste is necessary as part of the software process.
For example: Vacations, time with the family, lunch outings, sleep, technically speaking all of these things are waste from the perspective of a customer waiting for delivery a software product or service. Yet each of these is necessary. They not only act as safety valves to keep a software engineer from "blowing out", they bind together a team into a cohesive group, they are the raison d'etre for being a software engineer.
It might be worth your time researching the Japanese term "karoshi": In Japan the phenomenon of dying from overwork.
Posted by: Jim Davidson at January 29, 2004 06:47 PMI guess 'Commitment' in this context means laying down lines of code in such a way that you can not extract yourself from that position. In this regard you are 'committed' to doing things in a particular way when you don't necessarily want to shackled to your first assumptions. It presumes that you have started to bulid something when you aren't sure that it's right (as Agile advocates).
I think this is the hardest concept (speaking as a designer) of Agile to reconcile, but it is at the heart of this approach. Providing the whole team is aware and bought into the fact that things must change over the duration of the project, change shouldn't be the thorn in our side that it is when using a less iterative approach.
Then again, these are all 'guidelines' based on the observations of one (admittedly very experienced) lady and should be adopted as you see fit. So put it in the order that it seems right to you. I'm sure that's what she'd say anyway. :-)
Posted by: Ant at December 23, 2003 11:27 AMCan 'delay commitment' be put at the bottom of the list? That should be the last resort if no other flexibility measures have worked.
Instead it tends to be the first - which means no other measures are looked at...
Posted by: Tom Dolan at December 22, 2003 11:16 PM