Leaner software development using DevOps

Reduce cycle times and eliminate waste with Rational software

Lean development is a culture; waste reduction is one of the results. Removing waste can improve operational efficiency, but more importantly, it can reduce the development cycle and increase customer value. Shorter cycles can improve innovation, competitiveness, and responsiveness in the marketplace. They can also provide a valuable opportunity for learning and continuous improvement for the development teams.

This article focuses on how IBM® Rational® solutions for DevOps help to reduce waste and cycle time. These tools help people make their time more productive. Face-to-face interactions such as observing projects in action and collaborating about the root causes of problems are also vital aspects of lean development.

The president of Toyota said the two pillars of lean management are continuous improvement and respect for people.

"The essence of [the Toyota system] is that each individual employee is given the opportunity to find problems in his own way of working, to solve them and to make improvements."

Learn more about the thinking and effects of lean development principles in Mary Poppendieck and Tom Poppendieck's publications. (See Resources for other books by these authors.)

Many people use IBM DevOps capabilities with lean development principles, to successfully reduce waste. Forrester Consulting analyzed many IBM customers who use these solutions and found developers, testers, and project managers achieve a time savings of 30 to 50 percent for communication and collaboration activities alone.

Teams and organizations often waste 40 percent or more of their resources. Waste comes in several forms:

  • Unnecessary overhead
  • Unnecessary rework
  • Unnecessary features
  • Building the wrong thing

Often the wrong solution is built because the requirements are not specified correctly. When the wrong solution is built, the business does not realize significant business value from the investment. And, in some cases, entirely misses an important business opportunity.

When you think about waste, consider what parts of the software are visible, how work flows through the system, how one team's work affects another team, and how open communication can foster innovation.

As shown in Figure 1, waste reduction makes it possible for development teams to spend more time doing productive work, an improvement that reduces cycle times and increases the amount of code that can be delivered in a set timeframe. Using these solutions with continuous delivery, the IBM Rational development teams have reduced cycle times from a year to three months.

Figure 1. Lean transformation
Lean transformation reduces                     waste from 50 to 20 pct
Lean transformation reduces waste from 50 to 20 pct

These technologies can remove the tedium of boring tasks, make it easier to stay organized as a team and as an organization, and provide a more sociable and fun way of working.

The following types of waste, as defined by Mary and Tom Poppendieck, explore the common problems of wasted time, of work that does not add value, and unnecessary rework. IBM DevOps can help minimize these problems so that people can focus on the most essential tasks required to quickly and efficiently deliver effective software.

  • Waiting:
    People spend time waiting for others to do something, often because there is no clear handoff of work between teams.
  • Handoffs and task switching:
    When people switch tasks frequently, time is lost in regaining a sense of context and resetting environments. Often tasks are left partially completed. Assigning an individual to work on multiple projects can waste time.
  • Motion:
    When people and artifacts have to be moved, time is wasted. Are subject matter experts and customers easy to access? Can the developer find the results of the tests without walking down several flights of stairs to another office? Where are the relevant documents stored? How are handoffs managed?
  • Extra processes:
    Unnecessary processes, repeated tasks, and unnecessary paperwork can waste time. Is this paperwork actually providing value to the customer?
  • Extra features:
    Implementing a solution that is not required to resolve the business problem wastes time.
  • Partially completed work:
    If a use case scenario is not completed and is not free of defects, it has little or no value. It's not possible to know if the scenario works in the production environment or whether it will provide value to the business.
  • Defects:
    Defects prevent work from being completed. Time is wasted if there are many defects or if the project has significant technical debt. The sooner the defect is detected and fixed, the less waste it creates.

IBM DevOps, a continuous pipeline for accelerating software creation and delivery, includes two core tools:

  • Rational solution for Collaborative Lifecycle Management (CLM): A platform for a code creation pipeline
  • IBM® UrbanCode: A platform for a code delivery pipeline

The article focuses on how the key IBM DevOps capabilities address these wastes. The following software products address the creation and delivery aspects of DevOps tools that remove waste. See Resources for more information about the individual products.

  • IBM® Rational® Quality Manager
  • IBM® Rational® Requirements Composer
  • IBM® Rational Team Concert™
  • IBM® UrbanCode Deploy
  • IBM® UrbanCode Release

You can refer to sections that interest you most or read this article in sequence. The "Measuring value chains" and "Defects" sections are especially useful because they describe tools for analyzing and thinking about any processes, with defects being an example.

Measuring waste and value chains

Value chains are a technique to help teams and organizations develop an understanding of how long tasks take and how much waste is present. Value chains can help a team understand when the work product is not being actively worked on, and by removing the idle times, teams can achieve dramatic reductions in cycle time.

For most organizations, the key value chain is how long it takes to get an idea into production. Figure 2 shows an idea passing through a number of individuals or teams until it gets deployed. At each point the idea is either waiting to be worked on, or some actions are being taken to move the idea toward implementation.

Figure 2. Flow of an idea into production
An idea flows between queues and actual work
An idea flows between queues and actual work

To prevent waste, you need to manage and measure how long work products remain in queues. For your own value chains, consider starting with an idea that requires only a single line of code to be changed. How long would that take to deliver?

Use value chains to look at any aspect of work in your organization. Often, the following value chains have significant waste:

  • Securing approval of new ideas into development
  • Getting signoff on requirements and designs
  • Searching and finding the relevant project information
  • Replicating and fixing defects
  • Acquiring and setting up a test infrastructure
  • Deploying an application to test environments
  • Deploying an application to production

Over the length of the value chain, consider these measures:

  • Process efficiency as measured by the total effort in proportion to the elapsed time
  • Total cycle time

Changes such as automating a manual task can reduce cycle time, but also reduce efficiency, because they fail to reduce any of the waste. Another way to think about cycle time and efficiency is the following formula:

Cycle time = Effort + Waste

Efficiency = Effort / Cycle time

To better understand these metrics, look at the example shown in Figure 3 of the value chain associated with fixing a defect after it has been discovered.

Figure 3. Example of a defect value chain
Value chain diagram showing working time and waste
Value chain diagram showing working time and waste

When using value chains, it's a good practice to measure the effort and the waste (the elapsed time minus the effort). In this example, it takes 4.25 hours of effort on average to fix a defect, but it takes 16.25 hours of elapsed time, resulting in 12 hours of waste.

By concentrating on reducing the average waste and effort across a value chain (for example, a defect fix cycle, stories, or use case scenarios), you can start to make processes significantly leaner and provide more value, quicker, to your business or customer. Shorter cycle times make it possible to get feedback sooner, which can help you steer the project in unexpected, yet beneficial directions.

IBM DevOps can be configured to calculate the average waste and work at each stage of any work product (stories, defects, enhancement requests, use case scenarios, and so on). With these calculations, you can use these measurements to drive improvements. Figure 4 shows an example report from IBM DevOps that reveals the elapsed time, effort, waste, and efficiency for several defects.

Figure 4. Defect efficiency report

Table of defect summary, waste, and efficiency
Table of defect summary, waste, and efficiency

The traditional subjective means of gauging progress can be a poor basis for decision making. Using IBM DevOps to measure the product pipeline (rather than activity pipeline) provides a more honest perspective that leads to better quality feedback and progress. This kind of report is only one example of how you can measure your existing processes. These objective measurements can help steer the project to yield more value and more predictable outcomes.

Waste associated with waiting

Much waste can be attributed to waiting, in particular, these common forms:

  • Waiting for infrastructure
  • Waiting for applications to be deployed
  • Waiting for other teams
  • Waiting for reviews to complete

The first two sources of wait time are about moving code from development to test and into production.

The time it takes for a team to provision machines and deploy software – either to test or to production – is often the cause of long periods of waiting. Using a cloud for development and test makes it possible for teams to rapidly provision infrastructure, on demand, to test their applications. This approach can reduce waiting from days and weeks to minutes. Teams can have access to production-like environments much earlier in the development and testing phases. This access can drive defects out earlier and ultimately reduce deployment risk.

Another source of waste is time spent during application deployment. Manual deployment can be time consuming. If specialist resources such as an application server administrator or a security specialist are used, the process can take additional time because the team has to wait for another team to deploy.

IBM DevOps gives teams the ability to automate the deployment of an application, manage what is deployed to each environment, and promote code between environments. Rather than waiting for a deployment, deployment can happen automatically. One online retailer, for example, reduced the time for each deployment by 95% by using IBM DevOps.

Ultimately these two capabilities – automated deployment and cloud – can dramatically reduce the amount of time teams spend waiting for infrastructure and deployment. As shown in Figure 5, when a button is pressed or code is checked in, the infrastructure is provisioned, the application is deployed, and the tests are rerun. If the application passes, it can easily get promoted through the various test environments and can be deployed to production.

Figure 5. Developer deploying to the cloud
UrbanCode deploys an app to IBM SoftLayer
UrbanCode deploys an app to IBM SoftLayer

Implementing these changes is an evolving process. Some organizations choose to accelerate part of this cycle or to implement the changes for only some environments initially. Automating deployment or using the cloud makes it possible for teams and organizations to significantly reduce their cycle time and to improve their ability to innovate and react.

The third key source of waiting waste is failure of teams to prioritize work based on the effect of that work on others. Often there is no simple way for a team or individual to understand which aspects of their work impact others. The scrum method tries to tackle this problem by having daily stand-up meetings focused on impediments. However, this approach is difficult to scale to distributed teams.

IBM DevOps provides several key features for reducing the time wasted by teams and individuals waiting for others. As shown in Figure 6, a task is marked as being blocked by another task. Teams and individuals monitor three views of tasks: my blocked tasks, my tasks blocking others, and my tasks recently unblocked.

Figure 6. Blocking tasks
Blocked tasks, blocking tasks, and unblocked tasks
Blocked tasks, blocking tasks, and unblocked tasks

This approach dramatically improves the visibility of tasks that are blocking other teams and individuals. The visibility is the first step to helping teams self-organize to reduce waiting time. As shown in Figure 7, at a program or project level, the number of blocking tasks by an owning team can be monitored. Having this measurement on a team's dashboard helps them learn and adapt their approaches to minimize these impediments.

Figure 7. Blocking tasks by team
Bar chart showing blocked work items by team
Bar chart showing blocked work items by team

In many development situations, a task being worked on is blocked and progress cannot be made. In this case, a task can be suspended to make it possible to unwind and store of all the code changes related to the task. After a task is suspended, the developer can then work on another task. When the original task becomes unblocked, the developer can resume the original work and merge in the changes from the original task, if required.

It's possible for a developer to have a large number of suspended changes or change sets. A change set, as shown in Figure 8, is a repository object that collects a related group of files, folders, and component modifications so that they can be applied to a flow target, such as a workspace or stream, in a single operation. Each suspended change set represents waste in the form of unfinished work, but as long as the developer is working on valuable work, this form of waste is less of a concern. Sometimes, waste is required in the short term. Sources of temporary waste can be analyzed in a retrospective.

Figure 8. Pending changes view
View showing suspended change set
View showing suspended change set

Reviewing artifacts can also result in waiting waste, because the authors often have to wait for reviews to finish before they can proceed. Often much time is wasted tracking down people to finish the reviews. IBM DevOps centralizes and automate reviews. Artifacts for review (requirements, design, code, and software assets) can be assigned electronically to a reviewer and their comments can be captured and implemented in a simple fashion. Reviewers are notified and reminded of reviews automatically. As shown in Figure 9, status of any review can be seen at any time. This approach can remove waste from the process of getting artifacts reviewed.

Figure 9. Save time with online reviews
Status of a partially finished review
Status of a partially finished review

Handoffs and task switching

Handoffs and task switching cause similar kinds of waste. A handoff occurs when one team member hands off a piece of work to another (for example, a developer fixes a defect and hands it off to the tester to verify the fix). Task switching is when an individual switches between different tasks.

Ideally, in a small agile project, there are minimal handoffs, because team members tend to take on all project roles (write stories, develop code, test, and other similar tasks). However, on larger projects, or on projects in which there are few multi-skilled individuals, handoffs become necessary. Handoffs can introduce significant waste for several reasons:

  • Rework caused by the need to rekey information between tools or teams
  • Wait time caused by team members being unaware that something is ready
  • Lack of sufficient detail
  • Outdated artifacts
  • Changes that have not been successfully communicated to the team.

IBM DevOps helps to reduce the handoffs waste between development and operations by:

  • Automating the deployment,
  • Providing the capability to promote applications between environments
  • Providing the capability to organize and manage large-scale releases.

These capabilities remove the manual and error-prone activities related to deploying software, and they help manage the governance of releases, changes that ultimately significantly reduce the waste and the risk. Teams can release their software more frequently, so that it can deliver value earlier and so that teams and organizations can get feedback faster. Figure 10 shows how you can visualize the application versions that are in each environment, so that operations can see what is coming, and so that the handoffs between development and operations can be simplified.

Figure 10. Deployment pipeline showing which application versions are in each environment
JPetstore in dev, cert, qa and prod environments
JPetstore in dev, cert, qa and prod environments

With IBM DevOps, team members from any team can view information and follow changes in other teams through RSS, email lists, or viewlets in the web. As shown in Figure 11 and in the following examples, this information can help teams save time.

  • Requirements teams can see which of their requirements have been turned into running, tested code, as show in Figure 11.
  • Design teams can track changing requirements that might impact them, resulting in less wasted effort designing the wrong requirement.
  • Development teams can track new defects reported by the test team, as well as changing requirements, and can easily plan work to implement new requirements and fix defects.
  • Test teams can see which requirements have changed, which stories are ready for testing, which previously broken tests are now ready for retest, and can easily plan testing activities.
  • Operation teams can see the state of the builds, which environments an application is deployed to, and which defect fixes and new features are in each build.
Figure 11. Requirements team view requirements turned into running code and tests
Shows requirements, work items, and test cases
Shows requirements, work items, and test cases

Information that is visible and easily accessible can greatly reduce the time wasted in handoffs, extra processes, and motion, because team members have the information that they require at their fingertips, as shown in Figure 12. They have access to the information without having to disturb other team members for status updates.

Figure 12. Dashboards show immediate updates from other teams
Viewlets of requirements and development changes
Viewlets of requirements and development changes

Handoff between projects and later phases

The previous section focused on how waste can be reduced within projects. This section focuses more on waste between projects, departments, and third parties. As shown in the following examples, handoffs between teams can be wasteful:

  • An application is passed from the development team to another team (either a deployment or operations teams) for it to be deployed
  • An application is transitioned to a support team with insufficient development artifacts, such as requirements, designs, and tests. The support team must figure out how the application works before being able to provide satisfactory support.
  • An application that has not been touched for a while needs to be upgraded, but the original requirements, design, tests, and sometimes even the code can no longer be found.
  • An application has certain non-functional requirements that have been solved elsewhere in the organization, but it is hard to find the other applications that have those requirements or, from there, to find the designs and code that were used to solve them.

Software asset management can help solve these kinds of problems and reduce waste related to not being able to find the right information at the right time. An asset can be used to store any useful group of artifacts; their context; and metadata, such as code, test scripts, service definition, reference architectures, and business models. In particular, using IBM® Rational® Asset Manager can reduce the time that it takes to find existing assets by helping people to use a mixture of formal categorization, tagging, and text searches. This approach makes it very quick to find high-quality assets and download them to a desktop or development environment for use.

By using Rational Asset Manager as a definitive library for all of your software assets, you can start to directly address much of the waste and inefficiencies that occur in handoffs at the project and program levels. Development teams can choose to upload their deployable artifacts to it, and IBM DevOps can be set up to only download and deploy artifacts that have been approved in Rational Asset Manager. This approach improves control and reduces waste and risk. It also provides a single portal for all project documentation, code, and artifacts, so that the support team can have access to all of the development information in one place. This makes it easy to quickly find development artifacts for systems in maintenance. Teams are able to quickly identify other projects that have solved similar problems and reuse their solutions to save time.

As shown in Figure 13, a visual browse diagram, which shows the relationships between assets, makes it simpler and quicker to find related assets.

Figure 13. Rational Asset Manager visual browse
CIM project and related assets in RAM visual browse
CIM project and related assets in RAM visual browse

Task switching

An example of waste from task switching is the situation in which a developer has partially finished coding one function and then switches to another. The developer might have to waste time removing all the original code changes before it's possible to starting work on the new function.

Many personal productivity books (such as Getting Things Done and Do It Tomorrow) emphasise that multitasking is not faster. If you have two jobs to do, it's quicker to do one and then the other, rather than try to do both at the same time. Agile and Kanban development teams follow this tenet to minimize the number of stories being worked on simultaneously.

In an ideal world, there is limited task switching. The way in which people and other resources are managed can help minimize waste from task switching. For example, avoid over-committing teams to prevent the need to juggle too many different tasks. Undertake projects in sequence rather than loading individuals or teams with many projects simultaneously.

If task switching is necessary, CLM can help. With CLM, the waste caused by getting up to speed is minimized, because all artifacts (business processes, requirements, discussion forums, reviews, comments, tests, designs, code, plans, and even people) are linked and related. This arrangement builds in context and shortens the time required to switch from one task to another.

CLM provides excellent support for task switching, because all artifacts are stored in the CLM repository. All file changes (to code, to designs, or to documents) are associated to a task. Changes are managed as change sets. The developer working on the task is able to suspend a set of changes, as shown in Figure 14. A suspension reverts all of the code to its state before the change was started. Therefore, developers can have many code changes running in parallel at one time, with minimal effort required to start work on any individual task. Obviously, it's not ideal to work this way, but if you continually have to wait until some other artifact is available and ready to edit, the suspension function provides a way to minimize the waste from waiting and task switching.

Figure 14. Save task switching time with suspended change sets
Pending changes view with suspended changes sets
Pending changes view with suspended changes sets


Motion waste occurs when people spend time physically moving about. For example, motion waste occurs when a business analyst must walk up a flight of stairs two or three times a day to see the business experts. Motion waste and time wasted in extra processes are strongly correlated. Motion waste occurs when team members attend meetings that are either not required or that require their presence for only a short time. This situation causes motion waste and task-switching waste, because the team member has to regain focus after the meeting.

To reduce motion waste, improve the visibility of project artifacts and improve the collaboration between team members and stakeholders by using CLM to link development artifacts together. These artifacts and information about them are made available through a web browser for stakeholders and team members to see. They can access almost everything from their desks, rather than going to many meetings to review artifacts and information. This ability reduces wasted motion and improves collaboration between people in different locations.

Forrester Consulting interviewed many CLM users and found significant waste reduction because teams are able to easily find the right information when they need it. One customer estimated that they saved around 70 percent of time previously spent communicating.

As shown in Figure 15, because all aspects of the project are available through a browser, CLM makes it possible to tailor dashboards to show the information that managers and stakeholders want to see. This ability promotes business agility because the stakeholders can see the project status whenever they want to. It also reduces the waste by reducing the time that teams and team leaders spend in meetings.

Figure 15. Show team progress in a web browser
Project plan showing individual and team progress
Project plan showing individual and team progress

Browser access to this data can reduce time spent in status meetings. On some projects, meetings are reduced by half, because the team can focus on the amber (caution) and red (alert) areas of the status report. In the transition, the new method of working can feel a little uncomfortable because the data gives a realistic view of progress. Access to a measure of team progress can improve the quality of the decision making and can reduce the time spent collecting data because status updates are automated by CLM.

Extra processes

Extra processes are additional processes that do not deliver value to the customer, for example, producing documents that no one reads, updating plans, manually collecting metrics and progress, organizing reviews that participants don't respond to, and other similar unnecessary tasks. Evaluate each process step in context to understand its importance, using the value chain analysis described earlier or a similar technique.

Determine whether the process adds value to the customer or delays time to value for the customer.

A manual deployment process is a great example of process waste. Someone has to write a long, detailed, and complete document that describes how to deploy the application and the instructions must be manually followed for every deployment of an application to test or to production. In some cases, organizations double up on the deployment to make sure that the instructions are followed correctly. IBM DevOps simplifies application deployment by providing a graphical process editor, as shown in Figure 16, to create the deployment automation. IBM DevOps includes hundreds of ready-to-use steps. These capabilities help to reduce defects created through the build or deployment process and significantly reduce the risk of failed deployments.

Figure 16. IBM UrbanCode deployment process
Steps to deploy an application to Tomcat
Steps to deploy an application to Tomcat

CLM can also be configured to enact an organization's process, a function that helps teams be guided seamlessly through the process. Sometimes tools makes it harder to follow a process, but CLM makes it easier to follow the process than to not follow the process. For example, if a team decides that they need 70 percent code coverage from their unit tests, CLM can prohibit code from being delivered if it doesn't meet this criteria.

CLM also gives teams the flexibility to overwrite the process if they want to work a certain way, or if they find that some elements of process aren't working for them. In the previous example, a team might decide that they want a higher level of coverage for certain components, or that they want to selectively enforce the code coverage requirement.

CLM supports a method of requirements definition that focuses on waiting to define features in detail until the iteration in which they are implemented. It also supports writing customer tests as an alternative to detailed requirements definition.

Other IBM® Rational® tools that make improvements to automation throughout the lifecycle can remove processes that are currently performed manually. Removing manual processes can make it easier to implement smaller, more frequent releases, continuous integration, integration testing, test virtualization, and automated testing. These practices can also reduce waste, because they enable cycle times to be reduced and they make it possible to receive feedback more frequently. Assess automation improvements in the context of the overall process by looking at the value chains.

It's a good practice for teams to use their retrospectives to analyze the process and determine what could be changed to continuously improve. CLM helps by collecting data across all tasks and providing the capability to analyze the data to determine whether there are processes or tasks that aren't adding value.

Extra features

Use the following approaches to reduce extra features:

  • Set up a repository of business ideas to feed into an adaptive and iterative planning approach. Implement the important ideas first.
  • Start with a clear vision.
  • Actively steer the design of functionality based on feedback.
  • Allow the solution to evolve.
  • Actively involve a range of stakeholders early and often with frequent course-correction to produce better results.
  • Encourage stakeholders to collaborate and converge on moving targets.
  • Use visual representations and scenario-based requirements definitions, rather than large text documents, as shown in Figure 18.
  • Delay detailed specifications until the sprint of implementation.

A repository of business ideas is especially for organizations where any given business idea might be implemented across a number of systems or applications. As shown in Figure 17, CLM makes it possible for the business to collaborate around a set of high-level business ideas, to prioritize them, manage the approval process for them, and ultimately commit them to development. After the idea is in development, the business can view the progress across a number of teams to understand the status of the idea. This approach helps the business to focus on the ideas that represent the best investment and to minimize the number of items that are committed to development. It helps to ensure that unwanted features are not developed. The business retains a large degree of agility to respond to changing market conditions and to seek feedback from existing ideas that are in production.

Figure 17. Pairwise comparison of business ideas
Comparison of                 ideas by priority
Comparison of ideas by priority

As shown in Figure 18, visual representations and scenario-based requirements definitions make it easier to understand the value a requirement brings.

Figure 18. Visual scenarios aid understanding
Techniques for visual and rich-text definition
Techniques for visual and rich-text definition

The other approaches to help reduce extra features shift the focus from complying with a complete requirement specification to choosing to deliver only requirements that offer significant value to the business. In particular, the shorter cycle from requirements to delivery means that extra features are less likely to be implemented at all.

CLM supports defining features in many forms, from user stories or use cases, storyboards, UI sketches, process diagrams, text, images, and even audio or video. Not only can stakeholders find what's new and changed recently, they can also discover the wider context of the requirements in terms of links to both internal and external artifacts. For example, they can see the screen mock-ups for a particular user story. Using a range of visual techniques improves success. The visualizations are easier for people to understand how a requirement affects their daily work.

As described earlier, a single repository that can seen by all relevant stakeholders and that can be searched to find content relevant to each individual makes it easier for people to find and comment on what's relevant to them. Dashboards, tagging, and filters encourage active involvement from a broad range of stakeholders. This involvement, especially from business departments and clients, is invaluable because these stakeholders can provide early feedback.

With CLM, features can be easily fed into agile development plans. The plans demonstrate executable code to implement the most important features first and early.

The transparency, collaboration, and context available in CLM help teams to understand the features. This understanding improves the quality of decision making. The priority moves from conforming to the specification to validating with stakeholders the true value of the features and implementing the key features early.

Partially completed work

Waste from partially completed work is the amount of effort invested in features that are not yet implemented. Using the waterfall development approach leads to a significant amount of partially completed work, because early in the process, much time is spent writing requirements, developing, and coding. No working software exists until late in the cycle. This limitation is the primary reason that teams and organizations move to an iterative approach, so that they can finish features quicker and potentially deploy them to start delivering value sooner.

Even if you are using an iterative approach, waste from partially completed work is still important to consider. Within an iteration, the focus should be on finishing each story (or a limited set of stories) in turn, with the team working on as few stories as possible at one time. This approach minimizes partially completed work and means that some completed code is delivered within the iteration or sprint. If the team's work is spread across all of the stories, testing might be left until very late in the iteration cycle and the team might not deliver any new functionality in that iteration because the defects are discovered late, with little time to fix them.

CLM can help in a couple of ways:

  • As shown in Figure 19, with the CLM agile planning taskboard you can easily see the partially finished work.
Figure 19. Agile planning taskboard shows partially completed work
Multiple stories are being worked on
Multiple stories are being worked on
  • To minimize partially finished work, CLM can help teams have a greater number of developers working in the same area of code. In this collaborative approach, each developer gets a sandbox to develop code in isolation, without disrupting others. Developers can deliver code to each other if required, so that they can build on each other's work without sharing with the whole team. This flexibility fosters close collaboration to reduce the partially finished work within a project.


Defects cause two kinds of waste: the waste in repairing the defect and the waste caused by the software not working correctly. IBM DevOps helps reduce the creation of defects by improving the quality of requirements. It also helps to reduce the time taken to resolve defects so that they cause as little waste as possible. The process of finding, fixing, and resolving defects is known as the defect value chain. Often, significant waste occurs resolving defects because several teams or organizations are required to collaborate closely.

IBM DevOps supports lean development by improving the efficiency of the defect value chain. For agile teams story points (the scrum unit of measurement to estimate complexity of user stories) must not be claimed if there are outstanding defects. Defects imply that the code isn't finished and is still counted as work in progress, a state that is undesirable in lean development. Defects must be found and resolved quickly within a sprint. An efficient defect resolution process is a key to preventing an accumulation of technical debt during software development.

At Toyota, for example, people are coached to understand the root causes of problems so that the fixes can prevent future weaknesses from building up. In their famous "Stop the Line" practice, when a defect is discovered, the whole production line can be stopped to fix it then and there. This practice is aimed at reducing additional work downstream. In software development, if the build breaks, every effort should be made to fix it quickly.

Defects cost more to fix, the later they are discovered. The additional cost comes from the extra resources required for context switching and the extra processes that must be repeated if a defect is found late. To find defects earlier and to reduce the waste associated with them, it becomes necessary to test earlier and earlier in the lifecycle, a practice known as left-shift testing.

Integration testing, because it is typically difficult to automate, is often left undone because of the complexity of setting up all dependent applications. IBM DevOps service virtualization capability makes it possible for application services to be virtualized easily and quickly. Any application or component that depends on these services can be easily tested against the virtualized services instead. Using virtualized services requires much less effort to ensure that the application under test will work correctly and integrate. This capability becomes even more powerful when combined with IBM DevOps continuous delivery capability, because early environments can use virtualized services and progressively replace them with the real services as the system under test progresses through the various test environments. For example Forrester Consulting reported on a large European bank that increased their project delivery capacity by 100 percent over three years (scaling from 40 to 80 projects completed annually) as a result of using IBM DevOps test virtualization and integration testing capabilities.

As shown in Figure 20, CLM automates the handoff between the different teams. This automation creates a significant improvement in the overall process efficiency by reducing waiting waste during a manual handoff.

Figure 20. Defect workflow with Rational Quality Manager and IBM Rational Team Concert
Diagram showing tasks to fix defect
Diagram showing tasks to fix defect

In CLM, when the tester reports a defect, that information appears in the developer's IDE inbox of incoming work. Assuming that this is an important defect that can be fixed immediately, the developer can then suspend all current work in a single action, load the baseline in which the defect is found, and work on fixing the defect. When the defect is fixed, the developer can resume the previous work, picking up exactly where he or she left off. After the code has been fixed and built, IBM DevOps automatically deploys the fixed code to a new environment, and the tester is notified where the fix is deployed and which tests can be rerun. This approach means that teams can resolve defects very quickly. In particular, waiting and task switching can be significantly reduced.

Figure 21 shows a hypothetical example of a manual defect fix cycle.

Figure 21. Manual defect fix cycle
Diagram shows working time and waste
Diagram shows working time and waste

In this example, a defect takes 16.25 hours to fix, but 12 hours (nearly 75 percent of the elapsed time) of time is waste. The wasted time significantly increases the time that it takes to fix defects. When this example is scaled across the number of defects normally seen in a project, it can result in significant delays to fixing code and getting a working system delivered to the customer.

Figure 22 shows the same fix cycle when CLM is used to improve the collaboration.

Figure 22. Automated defect fix cycle with CLM
Diagram shows reduced waste and effort with CLM
Diagram shows reduced waste and effort with CLM


In our example using CLM, the effort to fix a defect is reduced from 4.75 hours to 3.25, and the waste is reduced from 12 hours to less than 2 hours. More importantly, it now takes only a little over half a day to fix a defect, which means that within a two-week sprint, it's possible to close defects quite quickly. This time-savings helps keep the technical debt under control and produces high-quality software that is potentially deployable.

If the defect is not impeding progress, it might be argued that task switching for each defect generates more waste because of intellectual restart time for developers. In these cases, defects can be dealt with in small batches and short cycles. Lean development incorporates temporary necessary waste for just such situations.


This article explores various ways that IBM DevOps can help teams become leaner and smarter. IBM DevOps helps teams:

  • Remove waste and automate manual processes so that software can be delivered more efficiently, and with reduced cycle times.
  • More effectively steer the process by helping them to look at the end-to-end picture, to measure and monitor, and to continuously improve their software delivery.

Leave a comment to share how you apply these ideas in your own organization.


Many thanks to Walker Royce, Murray Cantor, David Ziskind, Helen Dai, Anthony Kesterton, and Tony Grout, for reviewing this article and for their comments and support.

Downloadable resources

Related topics

  • Leading Lean Software Development: Results are not the point, by Tom and Mary Poppendieck, Addison Wesley, (31st October 2009).
  • Lean Software Development: An Agile toolkit, by Tom and Mary Poppendieck, Addison Wesley (2003). ISBN: 0-321-15078-3
  • Inside the Mind of Toyota: Management Principles for Enduring Growth, by Satoshi Hino. Productivity Press (2005). ISBN: 978-1563273001
  • Scaling Lean and Agile Development: Thinking and Organizational Tools for Large-Scale Scrum, by Craig Larmen and Bas Vodde, Addison-Wesley Professional; 1 edition (2008). ISBN: 978-0321636409
  • Scaling Software Agility: Best Practices for Large Enterprises, by Dean Leffingwell. Addison-Wesley Professional (2007). ISBN: 978-0321458193
  • Getting Things Done: How to achieve stress free productivity, by David Allen, Piatkus Books (2002), ISBN-10: 9780749922641
  • Do it tomorrow and other secrets of time management, by Mark Forster, Hodder & Stoughton 2006, ISBN-10: 9780340909126
  • Agile Requirements Best Practices, a blog by Scott Ambler.
  • The Total Economic Impact Of The IBM Rational Solution for CLM Report by Forrester Consulting, (June 2013).
  • The Principles of Product Development Flow: Second Generation Lean Product Development by Donald G. Reinertsen, Celeritas Publishing, (29 Mar 2012). ISBN 1935401009
  • Successful software management style: Steering and balance, Walker Royce, The Rational Edge, 2005
  • Learn more about Collaborative Lifecycle Management (CLM), which provides integrations across Jazz-based applications, to connect the work of analysts with development and test teams.
  • Total Economic Impact Study on Service Virtualization and Test Automation Solutions by Forrester Research, (July 2013).
Zone=Rational, DevOps
ArticleTitle=Leaner software development using DevOps