Issue 1, August 2007

Dear Members and Friends,

To better support our environment, HKSPIN has decided to publish our newsletter electronically starting this year. We intend to publish four times each year. Each issue will include several articles on topics related to quality, process improvement, and industry best practices, etc. In this issue, we identified three interesting articles (the last two had been recommended by Australian Software Metrics Association/ Software Quality Association (NSW) April 2007 newsletter.)

As always, we welcome your comment on this new form of interaction with you. If you have suggestion on a certain topic that we should cover or you like to contribute an article, feel free to email us at hkspin@hkcs.org.hk. For the calendar of event on quality and process improvement, visit our website (http://www.hkcs.org.hk/en_hk/sg/hkspin
.asp).

Dr. Hareton Leung
Chair, HKSPIN

In this issue:

1. Best practices for software development projects

2. What Engineering Has in Common With Manufacturing and Why It Matters

3. Is Software Development Like Manufacturing?

4. Measurement Planning Template

1. Best practices for software development projects

Mike Perks, IBM

This article provides a list of 16 best practices for improving the success of your software development projects. These practices have been recommended by industry luminaries such as Scott Ambler, Martin Fowler, Steve McConnell, and Karl Wiegers.

2. What Engineering Has in Common With Manufacturing and Why It Matters

Dr. Alistair Cockburn, is an expert on object-oriented (OO) design, software development methodologies, use cases, and project management. He is the author of Agile Software Development, Writing Effective Use Cases, and Surviving OO Projects and was one of the authors of the Agile Development Manifesto. Cockburn defined an early agile methodology for the IBM Consulting Group, served as special advisor to the Central Bank of Norway, and has worked for companies in several countries.

The debate continues on whether software engineering is a legitimate branch of engineering science. In this article, Alistair Cockburn suggests: "Software engineering is more like manufacturing than most people expect. Once we spot their similarities, we can apply the lessons learned over the last 50 years in manufacturing to software development. This article picks six lessons to apply to software development gleaned from the manufacturing industry." Maybe learning from manufacturing is not all that surprising, as we know that some organizations have already adopted the Six Sigma and Lean Six Sigma manufacturing tools for large, complex software development projects. This article takes a new approach, including the suggestion that the decision in software development corresponds to a part in a manufacturing line. There are also some interesting thoughts on the benefits of manufacturing techniques for moving software incrementally and quickly through development.

Apr 2007, CrossTalk

3. Is Software Development Like Manufacturing?

Jeff Atwood, Scrum expert

This blog was a response to the September 2006 Technical Report What Engineering Has in Common With Manufacturing and Why It Matters. In this blog, a Scrum protagonist suggests that " In many ways, software development is the antithesis of manufacturing"

4. Measurement Planning Template

For those who are considering setting up a measurement program, here is a template for planning a measurement strategy. Some general guidance on measurement is also provided.

(Summary) 2. What Engineering Has in Common With Manufacturing and Why It Matters

Software engineering is more like manufacturing than most people expect. Once we spot their similarities, we can apply the lessons learned over the last 50 years in manufacturing to software development. This article picks six lessons to apply to software development gleaned from the manufacturing industry.

It is generally considered frivolous to compare engineering - software engineering, in our case - with manufacturing. Manufacturing (so the reasoning goes) consists of making the same thing over and over, while software engineering is about making something different each time. In software engineering, coming up with the design and code is the hard part, while production is the easy part, sometimes as easy as publishing to the internet.

Software engineering is remarkably similar to manufacturing once we notice decisions as the product that moves through a network of people. In software development, people make decisions, hand those decisions to other people to build on, and (most importantly for this article) wait for other people to make their decisions. The decision in software development corresponds to a part in a manufacturing line: Both flow through a network, wait in queues at bottlenecks, have throughput delays, and so on.

With this equivalence in place, there is a very real parallel between design and manufacturing. This is useful to us because manufacturing has been studied heavily over the last 100 years, and we can learn from lessons in that industry.

In what follows, I shall focus on software development, but it should be clear that the same argument applies to every team-design activity, including engineering, theatre, publishing, and much of business.

Waiting for Decisions

We start by recognizing that in team-design activities, people wait on each other for decisions. (Editor's Note: The original article has a number of figures illustrating the dependencies between people in software development, mapping of the decision dependencies and Decision Dependency Networks.).

• Business analysts and user interface (UI) designers waiting for users and sponsors to decide what functions and design styles they want.
• Programmers waiting for business analysts to work out the business rules and UI designers to allocate behavior to different pieces of the user interface.
• Testers waiting for programmers to finish their coding.

A nice thing about considering individual decisions as connecting people is that we can move away from stereotypes about how a company's process or decision-making activities ought to look, and instead focus on how it actually looks - what decisions actually get made by which people, and who is really waiting for whom.

There is no ideal software process any more than there is any ideal manufacturing process. Each company has its own strong-minded people who make a disproportionate number of decisions that might, in other companies, be made by people in other roles. Each company has its own shortage of UI designers, programmers, testers, or even sponsors, which causes its process to have a certain characteristic shape - people working overtime or sitting idle because other people can not get their work done fast enough. Each company has its own reasons to have a large, external test department, or perhaps no test department at all.

Different Bottlenecks, Different Processes

In any organization, we can find a backlog of decisions stacking up at some particular work group. This creates a bottleneck , which limits the speed of the overall team.

Bottlenecks are of great concern in manufacturing and have received much study. The obvious thing to do is to increase the capacity of the bottleneck group - hire more people, or better people, or get better tools, and so on.

Sooner or later, however, the organization hits its limit as to what it can do to improve the speed of the bottleneck group. At that point, what comes into play is the process definition itself.

(Editor's Note: The original article uses diagrams to illustrate three different, but fairly typical organizations.)

In the first organization, there are not enough UI and database designers to keep up with the work. We see decisions stacked up at their work centers.Assuming that this organization cannot or will not hire more UI and database designers, it should look at ways to have programmers and business analysts pick up sections of the UI designer's and database designer's work. Even assuming that UI design work is specialized, parts of that work can be automated, carried out by assistants, or handled by programmers.

In the second organization, there are not enough experienced programmers, and work requests stack up in front of them. In this second organization, the reverse is more the case. The programmers, being few and inexperienced, might need to have much of the problem digested for them as often as possible.

In such a situation, in which I participated, we recommended that the business analysts write quite detailed use cases (not containing the user interface, but containing the business rules more explicitly than we otherwise might), the layouts of the data needs, plus discussions of different business scenarios.

The business analysts sat with the respective programmers as they started on each use case and discussed the use case, the scenarios, and the data. The business analysts left the paperwork with the programmers and made themselves available for discussions and tutorials as needed. The process we came up with was aimed at minimizing the trouble the programmers had to undergo to understand the problem at hand. This is quite different from the process in the first organization.

In the third organization, the users and sponsors are notably missing from the discussion. What happens in these organizations is that the business analysts and UI designers end up making the business decisions and then sending those decisions (or running products) back to the users and sponsors for comment.

In the third organization, the process might call for prototypes and early samples to be produced and put in front of the users and sponsors. Since those people have the least availability, the material should be as fully prepared as possible. Also, since close collaboration between the programmers and database designers is required, those teams should be seated together, or at least have frequent meetings and joint design reviews.

Lessons From Manufacturing

To apply the lessons from manufacturing, we need to recognize the life cycle of a decision:

• The decision gets made. It might be a business-level decision, a UI-design decision, or a decision about a particular line of code. The person making the decision does not really know at this point if it is a good decision or not.
• The decision gets reviewed internally. Part of reviewing a line of code is passing it through a test suite. Part of reviewing a UI design is putting it in front of a group of test users. Part of reviewing a business decision is putting it in front of sponsors and test markets. The decision fails the review, gets marked for adjustment, or passes.
• The decision gets pushed out into the world. At this point, the world makes a judgement about the quality of the decision and the decision makers get very useful feedback.

Even a very good decision has a finite lifetime, after which time it needs adjusting. A major goal of the development team is to get decisions reviewed, repaired, and sent out into the world earning value as soon as possible. All the decisions waiting for internal and external review constitute internal inventory or work in progress (WIP).

Move Inventory Out

One of the lessons to draw from manufacturing is to reduce the WIP, that is, get decisions out of development and into the business . This is important in manufacturing, and it is also important in software development, because the value of decisions decays over time. Every moment a decision stays in the development cycle costs the organization money.

• Each requirement is a decision based on a business climate. When the business climate changes, the decision may become incorrect. If the software is not yet earning value for the company, the requirement is a waste.
• An architecture is a decision based on technology and business. If the technology changes before the software is earning value for the company, those decisions are a waste.
• Each line of code is a decision based on requirements, domain, technology, and aesthetics. If anything causes it to become obsolete before the software is earning value for the company, it is a waste.

To the extent that it is not earning value in the business, each decision loses value and quality with time. The more decisions stuck inside the pipeline, the more decaying inventory the organization is carrying.

Inventory stacks up quickly. Assume for reference an organization that is so fast that when a new requirement arrives, it can implement and deploy it by the next morning:

• The company with a one-day turnaround has about one day's worth of inventory lying around the office.
• The company with a two-week turnaround has about 10 days worth of inventory lying around the office.
• The company with a quarterly delivery system (assuming they deploy from fresh requirements every quarter) has about 100 days of inventory lying around.
• The company delivering a three-year project has 1,000 days of inventory (decaying) around them.

The message, in software as much as in manufacturing, is the following: Get the inventory out the door and earning value! Find ways to shorten and speed the pipeline.

Move Small Amounts, Continuously

The next lesson to draw from manufacturing is that, for the WIP (decisions still inside development), reduce the size of transfers between groups. Move small amounts often rather than stacking them up in large batches for long periods of time.

(Editor's Note: The original article uses diagrams to illustrate ways of transferring work from the programmers to the testers. )

In the first case, the programmers hand over 100 lines of code (each week, let's suppose). The testers get a regular weekly arrival rate of about 100 lines of code and have to integrate and test them against the rest of the system and against the known defect log.

The amount actually handed over will vary, of course, and the actual length of time needed to work through the new code will also vary. That variance is part of why small amounts should be handed over at any one time.

The lower part of Figure 4 shows the programmers handing about 1,000 lines of code to the testers (each quarter, that would be, to keep the rate of production about the same as in the upper picture).

The problem with the lower picture is that all 1,000 lines of code show up at one time. The responsiveness of the testing group suddenly becomes much more variable with the large arrival of an unknown number of bugs of varying sizes.

Equally bad is when the testers start handing bug reports back to the programmers and the programmers suddenly see a large spike of requests on their input queue coming from the testers (see the arrow in Figure 2, from the testers back to the programmers). The programmers are now juggling two work queues: requests for new features and requests for bug fixes.

Manufacturing groups have experienced and studied all the previous examples, and they concluded that these sorts of feed systems run best when small amounts of work get handed from one group to the next. The ultimate goal is to hand over just one part from one group or person to the next.

Toyota pioneered this idea in its lean or just-in-time manufacturing lines. They aim for continuous flow , the flow of just one piece of material from one person to another (what to do when a queue backs up is the subject of another lesson).

It is not clear exactly what continuous flow might mean in software development. Some design decisions affect large parts of the system, and some decisions can not be validated for a long time. However, the experiences in manufacturing are backed up by both mathematical models and experiences in agile software development.

It is rare to find development teams able to deploy fresh requirements every week, but I have been able to find a few teams who both deploy weekly and have a low enough defect rate that they get only a few requests a day. On one team I talked with, a person was assigned each day, on a rotation, to handle any incoming requests, whether bug reports or requests for small enhancements. That person would stop other work, do the work and redeploy the system before rejoining the main group. The average time to re-deployment was half a day. With such a small, steady flow of requests on the feedback queue, the team was able to keep from being diverted from their main assignment.

Cross-Train People

The literature on lean and agile manufacturing contains the recommendation to cross-train (training in multiple areas) people at adjacent stations. The idea is that when a small bubble of inventory shows up at someone's input, the neighboring person, having a spare moment, steps over and works it down. In this manner, small variances in work flow can be evened out and not disturb the organization's overall flow.

We see this in software development when programmers help testers, user interface designers, and business analysts, or when business analysts help testers. Unfortunately, programming is a technical enough activity that UI designers, testers, and business analysts are unlikely to be able to help the programmers. Programmers can help other programmers, though. We see in some companies that front-end developers, middle-ware developers, and back-end developers help each other when one of the groups has a sudden bump in work.

Extend the Network

All of these ideas are good - so good, in fact, that people using them soon find that their bottleneck lies somewhere in their supply chain, whether sponsors, subcontractors, or distributors. They start to draw the dependency network for the larger system in which they sit, and they start including their supply chain partners in their discussions.

Toyota is well known for working with its suppliers. Less well known are cases of software development groups doing it. The same team I referred to earlier, using the daily programmer rotation for fixes and enhancements, also wrote automated acceptance tests for their subcontractor's part of the system. They reasoned that their time was better spent writing automated acceptance tests and catching bugs on arrival than debugging and finding those same faults in the integrated system when their supplier's code broke. The supplier was, of course, surprised and delighted to find they did not have to write the automated acceptance tests.

The lesson from Toyota and the other companies who are streamlining the wider network is the following: The wider the network of we , the faster we all go.

(Editor's Note: The original article provides details of relevant literature and links.)

Summary

It is not immediately obvious that software development teams can learn from manufacturing. However, once we chart the network of dependencies between people in a software development organization and make the shift to think of decisions as comprising the team's inventory , then the parallels become startlingly clear.

We learn six lessons from the parallels:

• Drawing the decision-dependency network helps us spot the bottleneck stations, where decisions-to-be-made are piling up.
• From the different decision-dependency networks in various organizations, and their varying bottlenecks, we can see how the optimal process varies from organization to organization.
• Move inventory out. Decisions decay over time, so it is important to find ways to shorten the pipeline from arrival of a request or decision to the deployment of the system.
• Move small amounts, continuously. Transferring large amounts of inventory (decisions, in our case) between workers causes unpredictable variations in the organization's output. It is better to move small numbers of decisions more often. This reinforces the idea of incremental development, with the smallest increment size possible.
• Cross-train people. When people can help each other across specialties, they can move quickly to eliminate small bubbles in each others' input queue, thus smoothing the organization's output.
• Extend the network. By widening the network included in the dependency analysis and queue-size reduction, a company can smooth its own input stream and simplify its work.

(Summary) 3. Is Software Development Like Manufacturing?

We've adopted Scrum for all of our software development at Vertigo. Although I'm totally in favor of Anything But Waterfall, Scrum is an unfortunate name:

1. It's two additional characters away from a term for male genitalia.
2. The term is derived from rugby, an extraordinarily violent sport. During my first year at college, a guy on our hall participated in Rugby. His ongoing injuries, both small and large, became a running joke in the dorm. Eventually even he started to re-evaluate the merits of the sport. As Steve pointed out, Wikipedia defines scrum as ".. the most dangerous phase in rugby, since a collapse or inproper engage can lead to a front row player damaging or even breaking his neck." My indirect experience with rugby leads me to agree. The most dangerous phase of a violent sport is not exactly the sort of thing you want to add to your project.
3. When you tell customers your software developers use the Scrum process, they have absolutely no idea what you're talking about.

We usually say "agile" to avoid all the weird connotations of the word Scrum.

To promote understanding of Scrum, and Agile software development in general, everyone at Vertigo got a copy of Mary and Tom Poppendieck's book, Lean Software Development: An Agile Toolkit. I was inclined to like the book, because I'm a big fan of Mary Poppendieck's article Team Compensation (pdf).

Although the book is great, the Poppendiecks spend a lot of their time drawing parallels between software development and manufacturing. Every few pages, you'll find some example from a classic manufacturing company: Ford, L.L. Bean, GM, Dell, Toyota, etcetera. Although the examples do extend beyond the manufacturing sector, they're definitely dominated by it.

Perhaps this makes sense if you consider that Scrum originated in manufacturing:

Scrum was named as a project management style in auto and consumer product manufacturing companies by Takeuchi and Nonaka in "The New New Product Development Game" (Harvard Business Review, Jan-Feb 1986). Jeff Sutherland, John Scumniotales, and Jeff McKenna documented, conceived and implemented Scrum as it is described below at Easel Corporation in 1993, incorporating team managment styles noted by Takeuchi and Nonaka. In 1995, Ken Schwaber formalized the definition of Scrum and helped deploy it worldwide in software development.

The manufacturing examples presented in the book don't resonate with me at all. I'm not convinced that manufacturing industries and software development have much, if anything, in common. Fortunately, the Poppendiecks address this criticism early in the book:

The origins of lean thinking lie in production, but lean principles are broadly applicable to other disciplines. However, lean production practices -- specific guidelines on what to do -- cannot be transplanted directly from a manufacturing plant to software development. Many attempts to apply lean production practices to software development have been unsuccessful because generating good software is not a production process; it is a development process.

Development is quite different than production. Think of development as creating a recipe and production as following the recipe. Thse are very different activities, and they should be carried out with different approaches. Developing a recipe is a learning process involving trial and error. You would not expect an expert chef's first attempt at a new dish to be the last attempt. In fact, the whole idea of developing a recipe is to try many variations on a theme and discover the best dish.

Once a chef has developed a recipe, preparing the dish means following the recipe. This is equivalent to manufacturing, where the objective is to faithfully and repeatedly reproduce a "recipe" with a minimum of variation.

In many ways, software development is the antithesis of manufacturing:

• Variability is the enemy in manufacturing; in software, it's the reason we get up in the morning. Every worthwhile software development project is a custom one-off job for a unique problem.
• Requirements are the bread and butter of manufacturing; in software, we rarely have meaningful requirements. Even if we do, the only measure of success that matters is whether our solution solves the customer's shifting idea of what their problem is.

I suppose the proof is in the pudding; if Scrum works for manufacturers and software development shops alike, then maybe the parallels between the two industries are valid. Still, I think Lean Software Development: An Agile Toolkit would be a much stronger book if it relied more on examples from actual software development efforts and less on examples from the movie Gung Ho.