Reduce rework

Waste

"The general root of superstition : namely, that men observe when things hit, and not when they miss; and commit to memory the one, and forget and pass over the other."" ~ Francis Bacon

Software development, as a complex socio-technical activity, presents numerous opportunities for waste to occur. Defined as any activity that yields no value for the customer or user, waste can manifest in several forms in software development projects, including the prevalent issue of rework[6]

In the context of software development, rework—comprising revision, correction, or modification of developed software—is often perceived as an inevitable evil. However, when examined from a knowledge-centric perspective, where software development is driven by knowledge in the same way a car is powered by fuel, we start to recognize rework as a significant form of waste

Waste is primarily due to rework.

1. There is rework due to changes about "What" to be built.
2. There is rework due to changes about "How" to build the "What".
3. There is rework because of defects.
4. There is rework because tasks are delegated to someone with inadequate training. We should not forget that the individual software developers need to be properly trained and have the capability to do the work.
5. There is rework because of misleading, incomplete, unclear information.
6. There is rework because of rebasing during code review. As presented in this example that rebasing operation caused re-work for all people involved in the code review. First, the developer had to locate the pieces of code in the new class to adapt the original source code changes to the external changes in the codebase that were incorporated by the external commits. Second, the reviewers had to review virtually the same code change, but now into a different context.

In this article, we will focus on the first two cases. Rework will specifically mean the work that occurs when a prior decision that was assumed to be final for the project is changed because it was later found to be defective.

A decision is considered “final” when the team doesn't have any reason to believe that the decision would need to change and will stand for the remainder of the project.

Such rework is distinct from design iterations performed for rapid learning, where the design decisions are understood to be experimental and subject to change. It is also distinct from establishing rapid project cycles to accelerate customer feedback. However, rework may occur within a design iteration or rapid project cycle if a poor decision would otherwise result in the iteration or project cycle failing to achieve its goals.

Rework has become so commonplace that most development managers seem to consider it normal. So they pad project schedules to account for rework. Such practices treat the symptoms as if they were unavoidable, rather than address the root causes so that the rework can be eliminated.

Much of the rework that product development organizations experience is not inevitable.

Development organizations can eliminate rework from their product development processes. But to do so requires a very different way of thinking about the development of new products. This, in turn, mandates a very different way of managing projects and organizations.

Less rework means more reliable on-time performance, faster time to market, lower development costs, fewer maintenance problems, more innovation, better quality and customer satisfaction, higher return on investment.

Causes for rework

Causes of rework can be classified into three general categories:

• Late learning. The development team learns something critical late in the development process that invalidates prior assumptions or otherwise causes the team to revisit a prior decision. For example, when marketing is changing requirements late in the development process, because they have learned what the customer really wants or what the market needs really are late in the development cycle.
• Premature design decisions. The development team makes critical decisions too early in the project, before they have the knowledge needed to make a reliable decision. For example, when to get projects under way, teams often make key decisions early so that plans can be formulated and development started, in spite of general understanding that they are just guessing this early in the project.

• Poor cross-functional coordination. Development team members with one expertise inadvertently make decisions that overly constrain those of another expertise. For example, when marketing or the customer requiring product specifications that are technically infeasible, or teams designing products too difficult to develop or maintain.

Existing strategies for preventing rework

Through the years a number of models and tools have been proposed to reduce the need for rework to some degree. The most popular are:

• Concurrent engineering. One of the earliest approaches to reduce the size, cost, and frequency of rework is concurrent engineering. Development teams attempt to avoid rework by performing dependent design tasks concurrently. In practice, concurrent engineering tends to be limited to engaging the engineers who will perform the later dependent tasks as advisors to the earlier tasks in order to minimize the number of defective decisions and thus reduce the amount of rework.
• Phase-gate process. Also referred to as a stage-gate process or waterfall process is a project management technique in which a project is divided into distinct stages or phases, separated by decision points (known as gates). Gated (reviews) between development phases are supposed to help identify defective decisions before additional investment is made based on incorrect assumptions.
• Front-end loading. It refers to the implementation of robust planning, design and preparation for project execution in the early stages of a project's lifecycle to improve the potential for a successful project. Trying to shift problem identification and resolution to earlier phases of development also potentially reduces rework. Front-loading can be accomplished by enhancing knowledge transfer from previous projects, and conducting rapid problem-solving cycles in early phases.
• Spiral Development. It emphasizes the gradual refinement of the design to avoid premature decision-making and the associated rework[1].
• Iterative Development It is where design and development of a new product occurs in a series of short phrases that repeat similar development activities, but adding more detail and resolution with each successive iteration[2]. The short cycles reduce the time from when decisions are made to when the defective ones are detected, thus minimizing the size and cost of rework.

Despite the many strategies and tools that have been developed, rework still consumes a great deal of product development time and resources.

The fundamental difficulty with conventional approaches is that the knowledge needed to make good decisions in the early phases can only be generated through detailed design work. However, detailed design requires that key concepts and systems design decisions are already made. Generating this knowledge before making those key decisions, and thus breaking the circular dependency, requires a different way of thinking. One such method is called Set-Based Design[5]. In what follows we will see remedies to the three causes of rework identified earlier.

Delay critical decisions until the knowledge is learned

Traditional software development projects begin with requirements documents and then proceed to development of technical and design specifications. Both documents start at the system level, and then continue down to the lower levels, eventually feeding into detailed design at the lowest levels. Of course, some design decisions are made during the execution of the project, but they are usually expected to be easy to change. The goal in this approach is to get the requirements and technical specifications ready as early as possible. They are also expected to be sufficiently precise so that they can be used in the verification and validation testing. The traditional process allows for those requirements and specifications to be modified as more is learned, but the preference is that they stay intact till the end of the project. That, intended or not, tends to inhibit change and thus inhibit learning.

However, rigidly specifying requirements early in the project means that some of the most critical decisions are made very early. If they are made with too little knowledge of what customers really want or what is technically possible, then rework is inevitable. Set-Based is generally accepted as an enabler of delaying decisions until you can establish the knowledge needed to make the decisions. Delaying decisions will help you deal with the second major category of rework causes i.e. making critical decisions with insufficient knowledge. Let's look at some of the earliest decisions in the software development process.

Requirements Definition

The team should be knowledgeable about what the user wants from the product. Business value is equally important. Value to the business defines what the business interests are e.g. target profit margin, competitive positioning etc. That is : why to invest in a project? The project may target only a subset of those interests, but that does not change what the user is interested in. Business value must be explicitly captured and well understood, or it will not be possible to evaluate the trade-offs with the customer value. Projects should not simply produce a product. They should design a profitable operational value stream for delivering that product[4].

Requirements should embody a deep understanding of both the user value and the business value so that developers can properly evaluate the tradeoffs between both.

A common technique for dealing with uncertainty in what the customer wants or needs is to express requirements as ranges of values, such as a "minimum acceptable” level and a "goal" level. The ranges form a set of possibilities that the users and the business are interested in and expect the product to satisfy. They are coupled with their preferences for the trade-offs that currently exist between those various requirements.

Specify user and business interests as target ranges, giving the development team room to explore, innovate and find the most appealing trade-offs for both the business and user interests.

Put together targets for performance indicators per functionality in the early phase of development. The objective is to express the range of what is appealing to users, what will sell, but with minimal constraint on the development team. This will give the team flexibility to learn about the trade-offs associated with various decisions. Requirements may not be adequately expressed as a list of numbers or even ranges, but rather must provide the knowledge needed to properly evaluate tradeoffs. Since the nature of the trade-offs emerges as the technical design progresses, the convergence of requirements will necessarily be an ongoing learning process.

Set-based requirements enable developers to learn about technical trade-offs. They can then present the trade-offs to the business to learn how they would want to make those trade-offs. Gradual convergence of requirements allows for deeper learning about some of the finer details that may be overlooked until the user can be presented with the finished product. Feedback on graphical mockups may yield new and more detailed requirements. These interactions, combined with technical design effort, reveal the most important trade-offs that must be learned in order to converge current requirements into the final requirements that will be used for the system validation at the end of the project.

This approach dramatically changes the dynamics between the development team and the business. Both sides should recognize that the learning comes from both directions. As both the team and the business learn, they narrow the target ranges to the final requirements at a point in the process when they have the knowledge to make decisions that would not need to be revisited late.

Technical Specifications Definition

A similar approach can be applied to the specifications of the system and its hierarchy of subsystems, components, subcomponents, and modules. Set-based specifications are defined in terms of ranges or lists of options that together define a set of possible designs that are evaluated as a whole set, rather than a set of point-designs that are each being evaluated as individual points. Prepare the final specifications based on the learning gained from investigating the alternatives within those sets of possible designs[5]. The developers can then feel comfortable working within those sets, free to choose any design in that set that works best, given the issues being addressed at that next level of detail. In this case, the team is placing the minimum amount of constraint on their developers, implicitly acknowledging that a set of solutions is acceptable.

Use set-based specifications in the early phases of the project, and allow the final specifications to emerge from the learning in the convergence process.

This approach eliminates much risk by defining sets of options within which to work. It increases the level of innovation and optimization through increased design freedom. It allows teams to accommodate changing market requirements and scope creep later in the process if the changes do not stray out of the sets. If the team stays within the ranges of the set-based specifications the team knows that the design will work. Once that is established, teams are free to explore and optimize without fear of late design changes.

Accelerated learning

When characterizing Set-Based practices, many people emphasize on the usage of sets of options. If that was all, then Set-Based would be adding workload, not reducing it, and thus would not be an effective learning accelerator. In contrast, we argue that Set-Based practices, leveraged properly, are a powerful mechanism for minimizing workload and increasing concurrency, and thereby accelerating learning[5].

The Set-Based paradigm replaces traditional Point-Based practices with a convergent design discovery process.

Development team must decide to what degree they are going to satisfy each of the user and business requirements. To do that, they sometimes need to decide what trade-offs to make on behalf of both. They must decide which Ideas to use based on each of their Capability Limits, given the underlying decisions that must be made in the design of each Idea.

However, early in product development, there are gaps in the knowledge of each of those. Most importantly, there are gaps in the understanding of their interconnections and dependencies. Ultimately, it is the Capability Limits that force the trade-offs. It is those trade-offs that will drive the decision-making on which solutions will best satisfy the requirements, and to what degree those can be satisfied in concert.

The key point is that knowledge gaps must not be left undiscovered. If there are knowledge gaps left undiscovered that will lead to rework due to acquiring new information late in the process that invalidates earlier decisions.

Do research using already prior knowledge.from textbooks, published academic papers, news articles, review articles, and meta analyses. Systematically identify the limits of technologies, development process capabilities, user preferences, market conditions, and so forth before making key decisions on the technical design. In this way critical information is far less likely to be uncovered late in the project.

Replace design-then-test with test-before-design to accelerate learning in the early phases.

The design-build-test cycles remain common today. Typically involve engineers rushing to the next full design in the hope that it will be the last. This thinking results in inherently long learning cycles. Furthermore, because many design factors are changing in each learning cycle, the amount of learning in each is frequently minimal because the effects are confounded[3]. Run tests with isolated design changes, such that the cause-and-effect relationship becomes clear. The goal is to understand the effect that each design decision would have on the performance.

Your goal is to:

• Understand the design limits of new technologies before incorporating them into a new product.
• Understand technical tradeoffs for product subsystems early in the design cycle before settling on subsystem requirements.
• Extract the learning acquired from each development cycle into design guidelines that are used in the development of next generation products.
• Relate decision variables to performance measures.

Focus on learning first via careful consideration of a variety of alternatives. Investigate alternative ideas in parallel when uncertainty is high or when teams must select from among fundamentally different technologies or design approaches, but do so with a focus on quickly identifying and eliminating the weak alternatives.

Learn sets of possibilities rather than single points, capturing set-based knowledge that covers the full range of possible designs.

Define what to build and what to use off-the-shelf. Have a body of knowledge from which to design a new product to meet any given set of specifications or know quickly that the specifications were infeasible.

For each functional requirement know what your customers need and what your capabilities are. Then based on that knowledge, enter development.

This approach is more like “design of experiments” (DOE) than traditional product design. The goal of DOE is to achieve the maximum learning with the least amount of testing effort[3]. The key is a focus on maximizing learning rather than on hopefully satisfying the final specifications.

The most common objections to the test-before-design strategy are that there is not enough time or that it will be too expensive. The key is to focus on designing the minimal tests that will yield sufficient data needed to close the identified knowledge gaps. This does not mean designing, building, and testing full system prototypes (which is time-consuming and expensive) but rather innovating ways to test (via prototype, simulation, or analysis) the critical elements of a system quickly and inexpensively. Identify the minimal set of tests that will yield the desired information. Often the testing required is surprisingly small.

Concurrent engineering

One major cause of rework is when professionals of one specialty impose excessive restrictions on those of another domain.

When teams collaborate on projects, they often interact with professionals from various domains. It's a common, yet under-recognized issue: specialists sometimes inadvertently handcuff their counterparts by imposing stringent restrictions, setting the stage for rework down the line. What if there was a better way?

Distinguishing between point-based and set-based collaborations can be enlightening. In the set-based approach, architects don't just present specifications and inquire if the lower-level teams or vendors can meet them. Such an approach only seeks a yes-or-no answer, possibly leading to rework. Rather, architects describe their goals and ask, "What options can you offer?" By outlining their objectives and genuinely inquiring about available options, it encourages a collaborative exploration of possibilities. This paves the way for diverse solutions and informed decisions. Thus, set-based knowledge seamlessly connects different areas of expertise, enhancing communication.

Leverage set-based knowledge to communicate the key issues from one area of expertise to another, breaking down the walls.

Perhaps the key to effective collaboration isn't in the answers we seek, but the questions we ask.

Summary

In summary, adopting set-based practices in a software development process that encourages learning first before committing to early decisions can eliminate rework at its root causes. Better yet, the next development project targeting a similar problem will be able to leverage the reusable knowledge of what your customers need and what your capabilities are. Hence, since the set-based knowledge generated is often reusable on future projects, the positive benefits often multiply several times over.

Putting the solutions into action can be challenging because it represents a radical change in thinking. The entire organization must abandon the traditional point-based thinking that forces premature decision making.

Works Cited

1. Boehm, B. W. (1988). 'A Spiral Model of Software Development and Enhancement'. IEEE. Computer, 21 (5), 6-–72

2. Larman, C., & Basili, V.R. (2003). Iterative and incremental developments. a brief history. Computer, 36, 47-56.

3. Antony, J. (2014). Design of Experiments for Engineers and Scientists (2nd edition). Elsevier.

4. Ward, A. C., & II, D. K. S. (2014). Lean Product and Process Development (2nd edition). Lean Enterprises Inst Inc.

5. Cloft, P. W., Kennedy, M. N., & Kennedy, B. M. (2018). Success is Assured: Satisfy Your Customers On Time and On Budget by Optimizing Decisions Collaboratively Using Reusable Visual Models (1st edition). Productivity Press.

6. T. Sedano, P. Ralph and C. Péraire, "Software Development Waste," 2017 IEEE/ACM 39th International Conference on Software Engineering (ICSE), Buenos Aires, Argentina, 2017, pp. 130-140, doi: 10.1109/ICSE.2017.20.