I attended a talk on lean programming by Mary Poppendieck. The talk was held at SDForum in San Jose, CA on March 15, 2004. It was sponsored by the Bay Area eXtreme Programming mailing list. Here are my notes from this presentation.
About the speaker
Mary Poppendieck, a Cutter Consortium Consultant, is a seasoned leader in both operations and new product development with more than 25 years' of IT experience. She has led teams implementing lean solutions ranging from enterprise supply chain management to digital media, and built one of 3M's first Just-in-Time lean production systems. Mary is currently the President of Poppendieck LLC and located in Minnesota. Her book Lean Software Development: An Agile Toolkit, which brings lean production techniques to software development was nominated for the Software Development Jolt Award in 2004.
What is productivity?
The recent dip in employment in IT is a first since the US Department of Labor started monitoring it. There was also a dip in software productivity two years before the one in employment.
To increase out standard of living, we must increase productivity. But how do we measure productivity in software development? It is the ratio of output to input into the process. So what's the input and what's the output? Some have tried lines of code per developer but this is never indicative of revenues for the software company. Worse, as technology progresses, developers can do more with fewer lines of code.
We need something else. If your producing software, it should be revenue per employee. If your in a support organization, it should be revenue in the support organization per dollar spent by the IT organization. In either case, you should tie each and every projet to somebody's bottom line. This way, developers know precisely the impact they can have on the business, and it helps planners decide which projects to prioritize over others.
While software industry has seen a decline in productivity, the retail and the manufactring industries have seen regular improvements. Year after year, they have been seeing a steady 2% improvement. This begs the question: What can slow growth industries teach the high tech world?
- focus on core business processes that drive productivity
- decide where to match the competition and where to lead the market
- create end-to-end improvements for the customer
Find out what your productivity levers are and use them to drive your business. Pay special attention to the lever that gives you the most leverage. For instance, Symantec didn't start this way but now focuses on anti-virus software. Adobe didn't start this way but now focuses on Acrobat. Both found the lever that gave them most leverage in the market and focused on that to achieve success in the marketplace.
The key is to transform ideas into products.
- make sure you really understand the customer
- limit to work to what you can actually deliver
- be fully invested in your customer's success
- keep maintenance in mind
There are two things we can do to increase productivity: do less work for the same output, or create more value out of the same effort.
Do less work
One way is to reduce the effort by providing only what the customer will pay for. Standish Group released numbers in 2002 that 64% of software features are never or rarely used. 20% are used often or always. We see the 20-80 rule at work here. We can raise productivity by focusing on the 20% that customers are willing to pay for and ignore the 45% that is never used. The effort expended on that 45% would be better used on the 20% that is worth something. This boils down to doing 20% of the work to get at 80% of the revenue.
This is difficult to do when replying to RFPs with a fixed feature list. The customer does not necessarily need everything on the list, but they have been told to consider solutions that include everything. You can try to educate the customer, but it is not clear that this can work in real life.
Once you have identified the 20% that you really need, you can break it down into minimum marketable feature (MMF) sets and categorize them by return on investment. Do the highest return on investment first, and repeat until you can no longer justify any more work. By deploying early and often, market models predict that you can move profit forward by generating revenues earlier. This is similar to a talk that Ron Jeffries did a while back about predicting completion date from velocity and making profit earlier by shipping partial, but functional, software early.
One case where this approach fails is when profit is not the determining factor. This happens often in government work.
Another way to reduce the effort is to streamline core processes and the flow of value. This includes accelerating the delivery of value to the customers. Counter-intuitively, any efficiency or cost reduction that reduces customer value will decrease productivity by reducing the customer business.
If a measure of an organization's maturity is how quickly and reliably it can execute its key processes, a software organization's maturity should be how quickly and reliably translate customer needs into code. But you need certain core disciplines before you can start refactoring your process:
- naming convention
- coding rules
- configuration control (source control)
- automated build
- automated unit tests
- automated acceptance tests
These disciplines allow you to be reliably fast. Open source is a good example where these disciplines are used aggressively at very low cost.
You can do this streamlining by finding bottlenecks and eliminating them, usually by changing the process. The key to the success of any change is to get buy-in by senior executives who will not only launch the change, but follow up on it frequently and regularly to make sure it is implemented. You can also streamline information transfer with fully-integrated cross-functional teams. These teams are characterized by the bidirectional, high-bandwidth flow of detailed information.
Create more value
The other way to raise productivity is to create more value from the same effort. Shorter customer feedback loop is key, through iterative development where you deliver early and often. The enables you to better improve your customer's productivity; when they win, you win. You must look for ways to optimize the entire economic chain, the way a Japanese keiretsu tightly integrates many cooperating companies, to everyone's mutual good. This sounds a lot like a Nash equilibrium situation. Boundaries betweeen organizations introduce costs, so lowering boundaries should reduce costs and improve productivity.
You need to have people who understand what are the levers that drive your industry and how to steer your company using those levers. Unless you have the right people recognize the right levers and use them to drive the enterprise right, your company won't last in that industry.
For clues on how to achieve good communciation within a group when you cannot have everyone in the same room, look at open source. They do all communication without ever meeting. Everything is done by email. Their success hinges on:
- benevolent despot / champion to coordinate
- motivated contributors
But we must not underestimate the burden and responsabilities this places on the coordinator, who must make sure things get done and work is allocated.
Alex Chaffee had an interesting quote:
Good people can fix a bad process.
A good process cannot fix bad people.
Increasing productivity does not equate turning software development into a sweatshop. At 3M, while Mary Poppendieck as there, everyone had to spend 15% of their time on a project of their choice. Senior members were expected to go out and find interesting projects that benefit the business.