Five benefits of agile practices in software intensive systems development

IBM Software December 2011
Thought Leadership White Paper

Five benefits of agile practices
in software-intensive systems
development
Achieve enhanced productivity, predictability, and flexibility

2 Five benefits of agile practices in software-intensive systems development

For the past decade, agile methods have proved beneficial for performance requirements for each. Agile practices can be
helping Information Technology (IT) software teams deliver, on applied to both types of product development, despite their
schedule, high quality software that satisfies stakeholder needs. differences.
Software teams pursue agile methods because they need a
process that can respond efficiently to change to the product As markets get more competitive, products get more sophisti-
under development. Agile methods afford more flexibility cated, and ensuring quality becomes a more significant chal-
compared to traditional plan-driven approaches, which lock in lenge, software-intensive systems teams need to evolve their
the project details early and are less able to adjust to stakehold- development methodologies in order to succeed. With the
ers’ evolving needs, market changes, and unplanned technology appropriate tooling support, agile methods can deliver a
challenges. successful solution and add significant benefits, which will be
explained in detail in this paper:
Software-intensive and real-time and embedded systems teams
(software-intensive systems teams) face many of the same ●● Agile methods can work for teams governed by industry
challenges. But can agile methods work for them? standards because they put into practice a regular cadence of
time-boxed development phases called “iterations.” This
Different constraints define how traditional IT software teams requires teams to establish and achieve a set of “done” criteria
and software-intensive systems teams develop their products. In for each iteration that can be used to track progress toward
this context “products” means both software systems written for final delivery.
IT operations as well as devices and systems that depend on ●● The agile focus on not accumulating technical debt and
embedded software at the core of their capabilities, such as cell “delivering just enough” helps drive overall quality
phones, automobiles and jet fighter planes. Teams that co- improvements.
develop software and hardware must ensure the combined ●● Project timelines become more predictable because risk is
solution works on specific hardware/software configurations and better managed through visible, prioritized backlogs and
delivers the required real-time performance. IT software teams parallel risk assessment methods.
must typically deliver a software solution on a variety of platform
configurations (hardware, operating systems, etc.) and meet

IBM Software 3

●● As teams adopt agile methods, they learn to work together practices is recommended. On closer examination, we see that
as a whole team to deliver working software at every iteration, these practices are lean, and because each must be completed
which results in a high productivity profile throughout with each iteration, the regular delivery pattern established helps
the project. ensure that critical process steps are completed on time and
●● Tools that work together seamlessly throughout the lifecycle, consistently. At first, teams beginning to adopt agile practices
from the requirements to the delivered product, further may feel the new method is more process intensive, because the
enhance team collaboration and productivity. same steps are executed repeatedly. Instead of completing the
planning activity at the beginning of the process, and constantly
These benefits have been successfully realized in IT software readjusting the plan, agile practice requires planning at each
development and can also be enjoyed by software-intensive iteration while allowing the plans to self-adjust as the project
systems development organizations. progresses and issues are discovered. Teams that become familiar
with the lean but repetitive processes drive better predictability
If your development organization has already invested heavily in at every iteration.
tools and development processes, how do you safely and
cost-effectively evolve your development processes to adopt agile Up-front plans, especially detailed ones that span the entire
practices? This paper will answer that question by examining five lifecycle in traditional projects, are expensive to update as
key business benefits in moving to agile practices. requirements change, and they typically need to change numer-
ous times throughout a project. Agile planning, by contrast,
Five key business benefits of agile takes into account the likelihood that plans will change as the
1. Streamlined process overhead software takes shape over the course of the project, so detailed
Teams working to create products regulated by industry plans are avoided at the outset. Change is managed as one of
standards including DO-178B, ISO 26262 and ISO 62304 must many factors that determine project outcome. The net benefit is
be able to demonstrate compliance with those standards. These a process that:
types of teams often adopt considerable process overhead to
ensure that they meet stringent code mandates. Agile methods ●● Can adapt to the changes that inevitably arise.
can help them meet industry standards with less overhead using ●● Requires less end-to-end process overhead.
short, time-boxed iterations. At first glance, an agile approach ●● Leads to less rework as the project’s end-date draws near.
may appear to be “process light,” because a limited set of


Traditional projects often require a resource just to track the “shippable” functionality with each iteration is important,
schedule. This is not needed for agile projects because stakeholders need to review those functions and provide
early and regular feedback during the project lifecycle. The
The elements of iterative planning iterative process affords this sort of review, and allows for
As noted above, an agile development process divides the project midstream course correction as needed. Experienced agile teams
timeline into short, time-boxed iterations. In the context of target work that is achievable and relevant for each time-boxed
software development, an “iteration” is a phase during which a iteration across the product stack. In other words, they aim to
functional part of the software under development is created and complete a thin slice of work that includes the entire product
tested. Iterations are designed for whole teams to complete stack so that some portion of the evolving product starts to
planned work. Whole teams include everyone who is required to work, and the team can identify the critical integration issues
bring work to completion, and they typically include developers early. Working this way from the beginning of the development
to write the code, testers to validate the code, builders to cycle helps identify cross-product issues early and verify that the
compile the code (i.e., make it functional and testable), writers to planned architecture works. It is worth noting, however, that
document how to use the code, and so forth. In the case of software-intensive systems teams may find it difficult to be able
systems software this would also include the hardware team. For to complete a thin enough slice of work that crosses the soft-
each iteration, the whole team targets completion of the planned ware/hardware boundaries in a single iteration. They may find
work. Most product teams include all the members of each it necessary to use techniques such as software/hardware
component who contribute to the product. The distinction in simulation to provide the mechanism to work across the
agile development is that these component teams work together boundaries at each iteration.
as a “whole team” throughout the product lifecycle, which
means that the planned work is an integration of the Challenges and benefits of whole-team collaboration
components. Building the product across the product stack at the beginning
of the development cycle is a challenging way for teams to work.
In an ideal agile scenario, teams should be able to complete and In traditional software and hardware development projects, the
ship their work at each iteration. But that is rarely achievable
with large projects, especially when the product includes
embedded systems. Nevertheless, the goal of completing

IBM Software 5

component teams develop in isolation at the beginning of the practices. Engaging the whole team to work together across the
project. Design, integration points, and interfaces are completed product stack may delay finalizing design and implementation
early in the project then each component team typically develops decisions, but it provides key benefits by helping to ensure that:
separately to meet the design specifications. By contrast, agile
methods prescribe working across the architecture boundary ●● The architecture works early in the process.
from the beginning of the project. Instead of completely ●● Stakeholders become educated about how the product works.
developing individual components that are expected to work ●● Product limitations are revealed during the development
together based on their pre-established interfaces, agile practice process.
recommends building thin slices of functionality that cross the
architecture each iteration. Whole teams of people from across Improved compliance with standards and mandates
the architecture work together from the beginning of the Projects with processes and artifacts governed by standards and/
project. A critical advantage is that the team tests the architec- or compliance mandates are well-suited to the iterative develop-
ture through integration early in the project and can make ment model, because standards-driven deliverables can be
adjustments when the impact is the smallest. This presents a specifically identified for completion at the beginning of each
challenge for IT project teams, who are not accustomed to iteration. For example, if compliance with a given standard
breaking down work down in this fashion. It poses the same if requires the ability to associate a requirement with a specific
not harder challenges for software-intensive systems teams, code segment and its related testing and documentation, then
because they have to integrate across the software and hardware each of these deliverables can be enumerated as tasks in the
boundaries. iteration plan. If the work is not successfully completed then it
most typically moves to the beginning of the next iteration to be
Nevertheless, integration risks are high in hardware and software finished. This rule is only broken if other work is reprioritized
co-development efforts, and iteration-based whole-team higher and pushes this unfinished work into the “backlog.”
integration can potentially yield great benefits to these teams
since their integration challenges are significant. Once teams get
experience working in this manner, they typically discover issues
very early and see the value of continuing with these agile


As previously noted, agile teams establish “done” criteria for Code refactoring means restructuring code to improve maintain-
work that to be completed with each iteration. This may include ability and architecture without changing its behaviour. Code
things like completing all code reviews, automating all unit tests refactoring can be considered technical debt if it is never
and achieving 100 percent pass rates, all document reviews and prioritized and addressed. Agile methods recommend that you
updates to be completed, etc. The “done” criteria can also add work items such as code refactoring to the backlog so they
include all elements required for compliance with mandated can be prioritized as work items equivalent to new feature
standards. Using this mechanism allows teams to not only functionality. In many cases, these items improve the product by
validate that the standards processes are completed as the project making it easier to fix or maintain.
progresses but, with the right tools, it can provide an audit trail
for compliance activities. Minimal functionality, high quality
Consider delivering “just enough”: That is, deliver the minimal
2. Improved quality functionality with high quality. Minimal functionality does not
Agile development practices deliver just enough functionality to imply poor functionality; it implies enough to get the job done.
meet stakeholders needs with high quality. There are several Software projects suffer frequently when teams try to meet all
aspects to delivering high quality that can benefit software- stakeholder needs and anticipate all problems that might be
intensive systems development in the same way that they benefit encountered. Known as “gold plating,” this behavior often
IT development. produces code and hardware that does more than is needed and
subsequently requires more work to maintain it, or even to
Technical debt provide the essential functionality of the product.
Technical debt refers to any unfinished work that the product
tracks. Examples of technical debt include defect backlogs that Stakeholders tend to believe they know what they want as they
are carried from release to release, code refactoring that never specify high-level requirements for an IT or software-intensive
gets scheduled, unwritten tests, and incomplete documentation. product. But most of the time, when they see the finished
“No technical debt,” a well-known agile mantra, means that product it often does not quite solve the problem; they simply
teams need to get into the habit of removing technical debt
before it collects to the point that it slows product development.
Agile methods recommend that technical debt be addressed
immediately or eliminated altogether.

IBM Software 7

did not imagine the problem accurately, or the problem has early in the project can enable the team to change their plans
changed, or the technology was not quite as promised, or the more easily if the risks cannot be managed, or allow the team to
product does not actually work the way the stakeholder have the time to find an alternate solution if the need arises.
intended—even though they thought they described their
requirements clearly. Developing in short, time-boxed iterations High risk items do not have to be completed before the next risk
and demonstrating to stakeholders early and often enables teams item is tackled. For instance, your team may have to tackle
and stakeholders to agree when the product has met each of several risk items, such as using a new technology, finding a
the needs. solution to a performance problem, or meeting new security
mandates across the architecture. Each such item must be at the
3. Improved predictability through better risk management top of the backlog, but it is not necessary to complete the work
When development projects miss their release target dates, there on each item before you move on to the next. Figure out what
are often many justifiable reasons. The team did not understand user stories (the agile term for a requirement or set of require-
how hard the new technology would be to use; the requirements ments) or work items are required to tackle the risky questions;
were not clear; the customers changed their minds after develop- and do just enough reconnaissance work to make that determi-
ment was nearly finished. However, businesses demand that nation, then do the same for the next high risk item, and so
products meet shipping deadlines so that related business plans forth. Do not complete the work on each risk item serially. For
can be met. There are several ways that agile methods can help example, the team wonders whether or not the new technology
IT projects achieve release predictability that can also be applied can be built with the existing build system, integrated with the
to software-intensive systems development projects. existing architecture, and finally passing data successfully in the
most complex scenario. They tackle this question by producing
Prioritizing risk just enough working code and hardware to demonstrate that the
Agile practice prioritizes high-risk aspects of development risk has been addressed, and they leave it there and move on to
enabling early risk reduction. The product backlog is generally the next risk area. You must devise a working plan for all the risk
prioritized in order of highest demand from stakeholders. areas, then move back to the item of highest stakeholder demand
However, critical items considered a risk to successful imple- and complete that work.
mentation due to technology or architecture challenges are also
prioritized at the top of the list. Addressing the risky problems


Parallel risk assessment complete the testing and fix the defects. By that time, they’ve
For risk areas where there might be multiple solutions and the missed the deadline by weeks or months, and the business may
team cannot agree on the right path, consider multi-set develop- have missed a critical opportunity
ment. This requires that multiple teams work in parallel on
solving the same problem with different solutions. Most teams By working together as a whole team on vertical slices of the
will not even consider this approach because they are convinced product from the beginning of the product cycle, the traditional
that the time and cost required to do the parallel evaluation are hockey stick productivity cycle is avoided. Agile teams tend to be
too great. In fact, teams that try this method often find that they very productive from the first iteration throughout the release
not only discover the best solution for the problem fairly rapidly, and their pace has to be managed so that burnout does not
they also are able to leverage good aspects from each approach, occur. Agile teams that maintain working code with every
which ultimately saves project time. Parallel development of iteration enable performance and system testing to start in the
alternatives is likely to bring key decisions forward. earliest iterations as well. Critical defects such as integration
issues are discovered sooner, the overall product quality is
4. Improved productivity profile higher, and the team works productively throughout the
Agile teams are more productive than teams using traditional development cycle.
methods throughout the development cycle. Traditional
development often demonstrates a hockey-stick pattern of work, Consistent, staged delivery is better for the team and the
starting with a design cycle up front, moving into a prototyping business. An agile planning approach and a focus on delivering
phase, then a long development cycle, followed by an unpredict- working increments of functionality can lead to improved
able cycle of integrating the pieces, and on to a final test phase. productivity compared to “high-ceremony” processes. Emphasis
As the project progresses, teams have to work together more on incrementally delivering working software products means
coherently and hope that all the pieces work together as you can quantify progress—making projects easier to manage
expected. But this is rarely the case, so team interaction increases and improving stakeholder confidence.
as integration problems are addressed, and ultimately the test
phase gets squeezed, which requires a cross-team scramble to

IBM Software 9

5. Ability to leverage existing tooling investments (OSLC) interface that allows OSLC-enabled tools to integrate
Adopting agile techniques successfully requires strong tool seamlessly. Rational Team Concert provides the team with
support. Most teams have already invested heavily in good proven, visible agile planning; its adoption for just that purpose
software tools, and they need to leverage that investment and has been viral within IBM Software Group. Rational Team
reduce the amount of change as they begin to adopt agile Concert provides work item management, team planning
methods. The most critical investment is a good planning and associated with work, and project visibility, all critical elements
work management tool that provides a visible team backlog and in agile projects. Work items in Rational Team Concert are very
will associate work with each item in the backlog. Ideally, the flexible in their usage and can be associated with releases, teams,
planning tool integrates with other development tooling, which sub-work items and so forth.
enables teams to maintain traceability from the backlog to other
artifacts including: In particular, most teams have heavily invested in configuration
and change management software such as IBM Rational
●● The requirements that drive it. ClearCase, Rational ClearQuest, Rational Synergy, and Rational
●● The architecture under development. Change. These products can work well with agile processes and
●● The software that delivers the solution. specifically with Rational Team Concert. Agile processes
●● The testing that validates the solution. managed in a process tool must link to real assets that deliver the
work so that teams can quickly validate progress on the work
Rational tools work well together and with other products to and later be able to audit what was completed. The work that
help successfully deliver agile projects. IBM Rational Team
Concert™ is the core workflow and collaboration component of
the IBM Rational solution for systems and software engineering.
It provides a flexible Open Services for Lifecycle Collaboration


delivers product requirements must be easily discovered and greater productivity and predictability, reduced cycle-time, and
tracked. From the planned work, it must also be easy to discover improved quality without adding implementation risk to the
the associated code that delivers the required capability, the projects. Agile methods offer a proven approach that can help
builds that deliver the code, and the tests that validate the builds. deliver such business benefits to software-intensive systems
development, while mitigating delivery risk through consistent
Rational Team Concert software also interoperates closely with and staged delivery. Agile techniques can also help overcome
other components of the Rational solution for systems and process overheads in meeting regulatory and standards
software engineering to provide agile tooling support for other compliance.
aspects of the software-intensive systems software development
lifecycle, including requirements management, model-driven The Rational solution for systems and software engineering
architecture and design and quality management. supports organizations moving to agile methods with flexible
tooling and processes that cover the full development lifecycle.
Agile methods help organizations face an By adopting agile planning and management solutions alongside
array of challenges existing tooling investments for change and configuration
Organizations developing software-intensive systems face a management, teams can transform their delivery processes while
perfect storm of rising competition, product complexity, and helping to minimize investment cost and implementation risk.
customer expectations—coupled with development resource and
time constraints that are stretching development organizations
to the limit. To meet the challenges of this new reality, new
development approaches are required. Teams need to deliver

For more information
To learn more about IBM Rational agile solutions, please contact
your IBM marketing representative or IBM Business Partner,
or visit the following website: ibm.com/software/rational/agile

To learn more about IBM solutions for © IBM Corporation
Software Group
software intensive systems development visit: Route 100
ibm.com/software/rational/workbench/systems Somers, NY 10589 U.S.A.

Produced in the United States of America
December 2011

IBM, the IBM logo, ibm.com, ClearCase, ClearQuest, and Rational are
trademarks of International Business Machines Corporation in the United
States, other countries or both. If these and other IBM trademarked terms
are marked on their first occurrence in this information with a trademark
symbol (® or ™), these symbols indicate US registered or common law
trademarks owned by IBM at the time this information was published.
Such trademarks may also be registered or common law trademarks in
other countries. A current list of IBM trademarks is available on the web at
“Copyright and trademark information” at ibm.com/legal/copytrade.shtml

Other product, company or service names may be trademarks or service
marks of others.

Please Recycle

RAW14298-USEN-00

Five benefits of agile practices in software intensive systems development

Recommended

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to Five benefits of agile practices in software intensive systems development (20)

More from IBM Rational software (20)

Recently uploaded (20)

Five benefits of agile practices in software intensive systems development