 | Level: Introductory Per Kroll, Manager of Methods, IBM Rational, IBM
16 Mar 2004 from The Rational Edge: A RUP expert examines the evolutionary changes in responsibilities and perspectives required of software development project members and clients in making a successful switch from a traditional, waterfall approach to an iterative approach.  Successfully adopting iterative development practices requires not only
deploying a set of new techniques but also changing the way team members collaborate
and view their responsibilities. In this article, we will look at the evolutionary
changes in responsibilities and perspectives required of project members and
clients to switch successfully from a traditional, waterfall approach to an
iterative approach.
Referring to these changes broadly as a "new mindset," we'll
focus on the different individuals involved in software development projects:
- Analysts primarily responsible for customer interaction and requirements.
- Developers primarily responsible for design, implementation, and
unit testing.
- Testers primarily responsible for functional, performance, and system
testing.
- Project managers primarily responsible for keeping the project team
on track and focused on key deliverables.
- Quality assurance and methods experts responsible for quality standards
and best practices.
- Clients responsible for clarifying what capabilities will address
their business needs.
A new mindset for analysts
In the traditional, waterfall approach, the analyst interacts with users and
stakeholders external to the project team. The goals are to understand and develop
a solution expressed as a set of requirements, document those requirements,
and then hand them over to the development team. Some development organizations
detail requirements in a long list of "shall" statements; others
express requirements at a high level, leaving a lot of room for interpretation.
In both cases, the underlying assumption is that the analyst understands both
the business and the users, and hence should be the person who specifies what
the system should do.
Once the analyst documents the requirements, he or she asks the users to review
them (even if they cannot fully understand the technical language used to express
the requirements, and/or cannot able to visualize how the many requirements
will address user needs once implemented). Then, it is the developers'
job to implement the specification. Typically, neither developers nor testers
participate in formulating the requirements. And once the requirements are specified,
there is little need for intense interaction between the analyst and the designer.
The analyst simply clarifies what is in the requirements specification.
This traditional model is flawed in several ways that we will examine below.
|
The
analyst's new mindset
- Establish an ongoing dialog with the end user to ensure that developers
will create the right system.
- Encourage early development and implementation of key system capabilities
to deepen your understanding of what requirements will address business
needs.
- From the beginning, work with developers and testers to optimize requirements.
- Choose the right level of detail for requirements, based on the needs
of your project and the current lifecycle phase.
|
|
Analysts should not specify requirements in isolation
First, the waterfall approach fails to recognize the value that stakeholders,
developers, and testers can add to requirements specification. You cannot
build software that will improve your business without an excellent understanding
of both the business and the technology. Unfortunately, few individuals have
in-depth knowledge in both areas. That means analysts, developers, testers,
and stakeholders should work together to supply all the information needed to
ensure that developers will build the "right" software -- that is,
a system that will effectively meet the client's business needs and provide the
potential to radically enhance their business efficiency.
Let's look at a simple example to illustrate the advantages of such teamwork.
Example: Web-based flight booking system
Let's suppose an analyst is charged with specifying requirements for
a Web-based, self-service flight-booking system. The analyst specifies that
users will supply an airport code to specify start and end destinations for
a trip. If they do not know the airport code, they can search for it by supplying
the city name. Then, the analyst specifies, after users book a specific flight,
they will get information on how to contact different agencies to book ground
transportation at the arrival destination.
When the designer reviews the system requirements, he recalls seeing
a Web Service that could provide a partial but proven solution. This low-cost
Service allows users to navigate through airport map displays and rapidly find
an airport that suits their needs, even if they are not familiar with their
destination city or its regional airports.
After verifying the strategy with stakeholders, the analyst and designer change
the requirements to include implementation of this Web Service. Then, after
a few days of development work, the designer discovers another feature of the
Service: When users select an airport, they automatically receive a list of
airport information, including available modes of ground transportation and
booking capabilities for each mode. The designer and analyst discuss this discovery
with stakeholders and the project manager, and all agree to incorporate
this additional feature of the Web Service into their new system instead of
building the ground transportation referral feature they had originally specified.
As you can see from this simple example, involving a system designer/developer
at an early stage can add tremendous value. Such individuals can suggest capabilities
and solutions that the analyst or end user may not have considered. Of course,
it should still be the project manager's and the stakeholders' responsibility
to weigh the merits of prospective scope changes, and the analyst must still
understand the business needs and drive closure on what the system should do.
But he or she will find better solutions by collaborating with the designer/developer.
Analysts and end users should communicate throughout the project lifecycle
Another flaw in the traditional development model is its low bandwidth communication
between analysts and end users. End users are expected to identify requirements
up front and review them, but they then have limited involvement in developing
the solution. In many cases, parties negotiate a contract based on requirements
that are detailed up front, and then changing them later requires a contractual
negotiation.
Far more effective is to maintain an interactive relationship between users
and the analyst throughout the development lifecycle. Both parties should understand
that they share the same objective: to build a solution to a problem (or set
of problems) of a required quality and at an acceptable cost. If their relationship
centers around arguing about what was previously agreed upon and who should
pay for what, rather than on building the right solution, then the project is
in trouble. This does not mean that the analyst should accept all requirements
or that end users should not make change requests. Rather, it means that all
stakeholders should seek a balance between give and take in order to foster
the development of a better solution. They need to recognize when they are being
overly rigid, hold discussions to reach a compromise, and make positive changes
to keep the project on track. Of course, this is easier said than done. But
the first step toward effective team work is to establish a constructive dialog
between the analyst and the end users.
It's not wise to overspecify requirements up front
A traditional development approach calls for detailed requirements up front,
and in the past many felt projects failed because their requirements were not
detailed enough starting out. But there are diminishing returns to increasing
the level of specification detail. At some point the team needs to get on with
building the solution, assuming that the requirements will evolve during the
project lifecycle. Remember: The main objective of a software project is
to produce executable code that solves the business problems at hand, at the
lowest possible cost. Once your requirements have reached a certain level
of refinement, the cheapest way to finalize them is often to make a partial
implementation of the system that you can demonstrate to end users. That way,
you can decide together what other capabilities you might need to provide. Finalizing
requirements often takes several iterations, during which you adjust the requirements,
design, and code, and then conduct tests.
Late in the project lifecycle you may not have to formally document many detailed
requirements; the code itself may provide sufficient documentation, and there
is little risk that the team will misunderstand what needs to be done. This
naturally varies, depending upon the system being developed, the number of people
involved, the system's expected life span, contractual obligations, and
requirements for adhering to quality standards. Finally, and perhaps most important,
early in the project you should focus on driving out business risks as well
as technical ones. Spending too much time detailing the requirements up front
deflects attention from mitigating key risks.
|
The
developer's new mindset
- Broaden responsibilities to include detailed design, implementation,
and unit testing.
- Become part of the requirements effort: Help formulate requirements
and then create solutions that address them.
- Become part of the testing effort: Develop code in accordance with
test-first design principles.
- Whenever possible, reuse existing solutions rather than building from
scratch.
|
|
A new mindset for developers
Iterative development, with its associated best practices and modern tool
technologies, also requires a mindset change for developers. First, as we discussed
in the previous section, developers need to play a more active role in shaping
requirements.
In the past, developers rightfully took pride in coming up with clever solutions
to tricky problems. They produced unique solutions from scratch to maximize
system performance, minimize memory usage, or provide a good graphical user
interface. Of course, developers still need to come up with clever solutions,
but increasingly, their focus needs to move from building solutions from
scratch to finding clever ways of tying together reusable assets, open source
software, common Commercial-off-the-Shelf (COTS) components, and Web Services
into a workable solution. To excel as a developer, you need to know how
best to leverage advanced Interactive Development Environments (IDEs) and modeling
environments. The "not invented here" attitude is counterproductive;
as a developer, your focus needs to be on producing workable solutions by leveraging a variety of reusable assets. Producing quality results
quickly and inexpensively is what is rewarded today.
Quality is the test group's responsibility. In traditional development,
during the final weeks of the project the entire system was thrown at the
poor testers, who were told to identify as many defects as possible. They were
responsible for the quality, and the developers were responsible for fixing
the defects they found. The iterative approach, in contrast, recognizes that
quality is the responsibility of everybody on the project. Today we have
tools and processes that support this concept of shared responsibility, allowing
us to deliver code of much higher quality. New tool technologies allow us to
synchronize code with design. They also enable us to test the code for memory
leaks and performance issues well before the system is completed, something
we could not easily achieve in the past. Modern configuration and change management
environments support daily builds, allowing us to test not only our isolated
code, but also how our code integrates with the rest of the system code.
Modern best practices include test-first design: First you specify what tests
should be carried out, and then you build software that will have to pass these
tests. This creates a strong focus on producing high-quality code. Modern tool
technologies also support quality by design,1
which makes quality an integral part of the design process. It allows you to
make quality measurements early in the design process and automatically generate
tests from the design model. Quality by design enhances the quality and ensures
the completeness of test code.
In summary, with iterative development, the developer's role needs to
expand; rather than simply implementing specifications, developers must take
a much more active role in determining what is necessary for the system overall.
This includes helping to ensure that the requirements are right, and that a
high-quality system is produced at an acceptable cost. To make the best decisions,
developers need a better understanding of the project vision and the business
problems that drive it. Only then will they likely build a solution that addresses
the requirements and resolves the business problems.
|
The tester's new mindset
- Become the team's mentor on quality issues.
- Work with analysts and developers to ensure that the requirements
and design are testable.
- Get involved in the test effort early in the project.
- Continuously automate testing of stable capabilities.
|
|
A new mindset for testers
Earlier, we noted that testers have traditionally been thrown into projects
only toward the end with a mission to "inject quality" by finding
defects. Every tester reading this is probably cringing, because they have learned
through experience how ineffective and frustrating that approach is.
With iterative development, testers are still responsible for determining whether
the system is of sufficient quality for release, but the way they contribute
to achieving high-quality systems is radically different. First, testers are
involved in the project much earlier, since every iteration (with the possible
exception of the first) produces executable results that they can test immediately.
Early on, the testing focuses on finding "big issue" problems rather
than on verifying that the code is ready to be delivered. This means that you
cannot simply hand over code to testers; instead, testers need to work hand-in-hand
with analysts and developers so that they understand what needs to be tested
in each iteration.
In addition, testers must supply feedback to other team members who can make
appropriate improvements to the requirements, design, code, and other supporting
artifacts. Testers are well-equipped to help with these tasks: Often they can
help produce better requirements because they are trained to devise ways to
measure whether a requirement has been satisfied. Also, modern integrated test
and development environments allow them to do continuous testing of work in
progress, using baselined code configurations.
Just as the analyst and developer take on broader roles with more responsibility,
so does the tester. Later in the lifecycle, testers act as quality experts,
providing expertise to the entire development team. For example, they can guide
managers in making quality-related decisions, in addition to actually performing
much of the integration and acceptance testing.
Because the requirements are iteratively identified, detailed, developed, and
tested throughout the project, the team does not focus up front on producing
detailed specifications of all tests to be performed. Instead, the early focus
is on understanding the test objectives—what they want to achieve—for
a certain phase or iteration. This shifts the focus to identifying potential
problem areas in each iteration, and developing tests to explore
those problem areas.
Iterative development means that you start testing the most critical capabilities
early in the project. It also means that you need to test and retest these capabilities
in successive iterations to ensure that problems you consider solved do not
crop up again. Full regression testing is impractical -- and often impossible
-- without effective test automation, so you must develop automated tests
continuously throughout the project. The secret to doing this efficiently
is to understand what elements will remain stable as the iterations proceed;
that way, you can avoid rewriting automated tests for every iteration. This
requires an understanding of the system architecture. Early automated tests
should focus on key aspects of the architecture; in later iterations, tests
should focus on more detailed functionality.
|
The project manager's new mindset
- Be open about risks your project faces, continuously reassess
risks, and use risks to prioritize project work.
- Assess project status by measuring demonstrable results rather than
the number of completed activities.
- Early on, develop high-level plans for the entire project, but produce
detailed plans only for the current and next iteration.
- Assess your investments in requirements, architecture, design, implementation,
and testing at any given time, against how effectively you are addressing
risks.
- Trust your team. Give them enough knowledge and responsibility to
take ownership of product quality. Help them work together as a cohesive
unit.
|
|
A new mindset for project managers
The most important distinction of the iterative development approach is that
it is designed to drive out major risks early in the lifecycle. Leveraging this
distinction requires an openness and honesty about risks the project faces.
Too often our natural tendency to avoid risks leads people to postpone addressing
them in hopes that they will somehow go away -- which almost never happens.
Risks are like an infection: The longer you ignore them, the more serious their
effects can be. Risks must be identified and prioritized continuously throughout
the project; each iteration must be driven by the principal goal of reducing
risks.
Following this approach may require a cultural change. Classical management
style dictates that you should avoid acknowledging risks to a wide audience
because people might infer that you are running a troubled project. That is
a dangerous approach: Pretending that risks do not exist does not make them
go away.
Traditionally, managers have determined the project's status by asking
team members what activities have been carried out. They assume that when all
the activities are done, then the project will be done. But this approach often
leads to project failure. Checking off completed activities is a poor way to
measure progress, because it does not take the quality of the results into account.
This approach might work if managers could accurately plan all the work
a team needed to do and could ensure that nothing would happen to force deviation
from the plan. However, as many managers know, things rarely go as planned.
Even if you create more detailed plans, there will be surprises. No
matter how hard we try to anticipate the future, we can never anticipate everything.
Results-based management
Since we cannot anticipate the future, software project managers need to make
risk management a key element of their strategy. And this requires changing how you measure progress: Instead of assessing progress based on completed
activities, you measure progress based on demonstrable results. This is the
essence of results-based management. Applying a results-based management
strategy means focusing on risks and tackling problems head-on. By deliberately
structuring project activities to address risk, you can uncover hidden problems,
resolve them, and steadily reduce uncertainty as the project proceeds.
In addition, since the primary result of a software development project is
the software itself, the quality of your deliverable should be the primary
measure of success. You can assess this quality with metrics such as the
number of tests your software passed, the number of defects in the code and
their severity, the amount of code churn, and so forth. In other words, a move
to iterative development means assessing status by measuring demonstrable results
against stated objectives and requirements, and not by counting how many
activities, artifacts, or work products you have completed. To assess the stability
of the project (another measure of management effectiveness), you should also
track the amount of churn in requirements, design, and code.
Less may be more
Earlier, we noted that adding detail to requirements may not always be beneficial
to your project. The same goes for other types of documentation. The thoroughness
of your quality assurance plan, software development plan, or requirements management
plan is not a good measure of project health. More is not always better: You
should adjust the level of documentation to the needs of your specific project.
The way to determine the right level is to focus on risks and results: If adding
detail to an artifact will reduce risk or improve the quality of a particular
result, then the investment is worthwhile; otherwise, it is better to spend
the time on more productive activities.
Managers using the waterfall approach pay great attention to planning and specifying
requirements in detail. Those using an iterative approach weigh the time to
spend on refining the requirements, architecture, design, and implementation
at any given point against the risks that work will address. They ask: "Which
types of activities would be most effective right now for mitigating key risks?"
Perhaps by prototyping a solution the team can address risks related to stakeholder
buy-in, or perhaps they need to actually design, implement, and test the architecture
to fully address architectural risks.
Involve every team member in quality assurance
Another mindset change required of managers moving to an iterative approach
is to start thinking of quality assurance as a collective responsibility.
It is surprising how often I hear managers comment that "I need the test
team to keep my developers honest," or "If the analysts don't
write down every single requirement, they will not be implemented." Of
course, you do need a test team to build high-quality applications, and failing
to document and track requirements will cause problems. But you will also run
into quality problems if your developers don't take ownership of quality
as well. To accomplish this, you need to start by trusting team members and
clearly communicating your expectations. If you cannot trust these people, then
they probably don't belong on your team.
Ideally, managers should be able to claim that "My developers are responsible
for delivering high-quality code; to help them, we have a test team that can
transfer competency and verify that the code delivered is of high quality,"
and "Our developers are responsible for implementing an application that
addresses the end user's needs. To help them we have an analyst team documenting
the requirements at an appropriate level of detail, and acting as a conduit
between the end users and the project team." Creating cross-disciplinary
teams -- that is, teams with analysts, developers and testers, who can work
together to achieve high-quality results -- is one of the keys to successful
iterative development.
|
The quality assurance and method experts' new mindset
- Choose an appropriate level of ceremony for your project (more is
not always better).
- Focus on maintaining quality throughout the project lifecycle, but
be flexible. Quality is best achieved not through a maniacal focus on
only reviews and testing, but through a good balance of investments
in requirements, architecture, design, implementation, reviews, and
testing at any given time.
- Adopt a risk-driven process approach. Your process should allow project
managers to adapt tactical activities to the project's current
risk profile.
|
|
A new mindset for quality assurance and method experts
Many organizations have quality experts -- people responsible for achieving
certain standards, such as SEI CMM / CMMI, Six Sigma, Spice, or internal quality
standards. Many have method experts as well who either form a Software Engineering
Process Group (SEPG) or are independently responsible for methods.
Often, these quality and method experts have the biggest problem adopting an
iterative mindset. Many have spent a large portion of their careers driving
organizations to act on the conventional wisdom that "more documentation
is better," "more reviews are better," "for a process
to work, it needs to be thoroughly documented," and "a process should
provide a time-based description of the specific tasks you need to perform to
carry out a project." They believe that by pursuing these principles,
which provide a higher degree of ceremony, they can avoid project failure.
However, these pursuits are counterproductive when taken too far, because high
levels of ceremony tend to increase the cost of iterations and encourage the
use of a waterfall lifecycle. Instead, you need to balance the best practice
of documenting thoroughly with a risk-driven, iterative approach that results
in demonstrable progress for each iteration. Such an approach allows project
teams to increase product quality while reducing both the level of ceremony
and overall costs. We should note, however, that using an iterative approach
does not preclude using a high-ceremony approach, which may be required for
safety-critical applications or others with stringent quality requirements.2
Flexibility is the key
A key change is that software processes and quality approaches should provide
project managers with enough flexibility to accommodate project risks; project
managers should continuously monitor project activities and status, and then
adjust the execution of the process to mitigate key risks. A process can
outline how to react to various risks and produce required results, but risks
are typically unknown up front, so you cannot specify early on exactly what
tasks to perform in which order. You also don't know which requirements
should be specified when or what components to design and implement when. This
means the process you use needs to provide clear management guidelines about
what represents a milestone, how to achieve it, and how to reduce or mitigate
risk -- all the while remaining flexible with respect to the details of
project execution.
You cannot create an effective project plan simply by following directions
embodied in a process. Project planning itself needs to be an iterative process
involving assessments of current risks, progress, test results, and so on, to
gather input for detailed planning of the next iteration.
This also means that project reviews or audits should not focus primarily on
verifying whether the project team has produced a set of artifacts or carried
out a set of activities. Rather, the audit should aim at identifying and verifying
risks, and at ensuring that the right artifacts and activities will be
completed to mitigate the risks. The audit should also review past problems
to identify common patterns of failure, and suggest process modifications to
prevent similar failures in the future.
|
The client's new mindset
- Actively participate in shaping requirements and become an integral
part of the software development team.
- Continuously provide feedback on capabilities that have been developed,
such as working prototypes and user interface designs.
- Leverage a progressive acquisition model that employs an iterative
approach; such models protect the interests of both the buyer and the
seller.
|
|
A new mindset for clients
Clients used to traditional software development approaches expect to have
minimal involvement in the development effort. They want to specify all requirements
up front, determine a fixed price, and then wait for delivery of the final system.
Frequently, this results in large discrepancies between their expectations and
what is actually delivered -- and in a solution that does not address their
true business needs.
Both clients and the development team can avoid a lot of pain by turning to
iterative development, which changes the model for interaction between them.
In an iterative project, the client is an integral part of the team that
builds the application. The client works with the rest of the development
team to make sure that the final application delivers the required business
value. The client organization should have an interest in interacting as much
as possible with the development team to ensure that they understand what is
being built and what risks and issues that entails. If the client does not help
in guiding the development effort, the team may develop the wrong application
-- and then everyone loses.
In the iterative model, clients cannot just specify what they want up front
and wait for it to be delivered. No matter how crisply defined they are, all
requirements are subject to a multitude of interpretations and possible implementations.
Rather than generating even more detailed requirements, it is more effective
for development teams to invest time in interacting more frequently and more
effectively with key stakeholders, including clients. Then, as clients view
the evolving application, they will gain a better understanding of what the
application should do and can provide constructive feedback to improve it. Also,
if business needs evolve rapidly throughout the project, the requirements need
to evolve in tandem and keep pace with the changes.
Clients can also benefit by being open to negotiating iterative contractual
agreements, an approach referred to as progressive acquisition. With
this approach, the parties first negotiate an umbrella agreement for the entire
project that outlines legal conditions governing the business relationship between
them. Then the project is divided into two or more subcontracts. Earlier contracts
specify payments based on time and materials, since neither party knows enough
at that point about the overall solution and probable development costs to make
intelligent upfront commitments. The later contracts are fixed price, which
minimizes risks on both sides for overruns or disagreements about what should
be delivered.3
Conclusion
We have discussed how adopting an iterative approach to software development
requires more than simply following a set of guidelines. Iterative development,
and the modern tool technology that supports it, changes the rules of the software
development game and invalidates many axioms that prevailed in previous decades.
Successfully switching from the waterfall approach to an iterative development
approach requires software development teams to change their perspective on
their individual roles and how they should interact with other team members.
In other words,
it requires significant and enduring changes in the behavior and values of all
team members.
Organizations can accomplish these changes only if each team member understands
the fundamental principles of iterative development that make the changes necessary.
At the beginning of each project, it is beneficial for the project team to openly
discuss the required behavioral and perceptual changes we have described in
this article in iterative development training sessions. This article can serve
as a springboard for those discussions: The project team should agree upon which
of the mindset changes and practices described above make sense for their specific
project.
Ultimately, this article is about how you can build the "right"
software by using an iterative approach to development, and by ensuring that
the entire team shares a vision of what to accomplish and will collaborate
closely to realize that vision. A manager can encourage changes in working procedures,
but ultimately it is up to the team members to accept and effectively implement
those changes.
Acknowledgments
I would like to thank Kurt Bittner, Anthony Kesterton, and Glen Tattersall
for their valuable reviews of this article, as well as Marlene Ellin for an
excellent editing job.
Additional reading
If you would like to understand iterative development better, I recommend these
resources.
- The Rational Unified Process Made Easy: A Practitioner's Guide
to RUP, by Per Kroll and Philippe Kruchten (Addison-Wesley, 2003).
- Software Leadership: A Guide to Successful Software Development,
by Murray Cantor (Addison-Wesley, 2002).
- Software Project Management: A Unified Framework, by Walker Royce
(Addison-Wesley, 1998).
Notes
1 For more information on the Quality by Design best practice, see Brian
Bryson's article on the topic in The Rational Edge, January 2001,
http://www-106.ibm.com/developerworks/rational/librarycontent/RationalEdge/jan01/QualitybyDesignJan01.pdf.
2 For a more detailed discussion on this topic, see Chapter 3 in The
Rational Unified Process Made Easy—A Practitioner's Guide to RUP,
by Kroll and Kruchten, Addison-Wesley, 2003.
3 See R. Max Wideman's article series on Progressive Acquisition
in The Rational Edge, http://www-106.ibm.com/developerworks/rational/librarycontent/RationalEdge/apr03/ProgressiveAcq_TheRationalEdge_Apr2003.pdf
About the author | 
| | Per Kroll is the director of the Rational Unified Process development and product management teams at IBM Rational Software. He's been working with customers as a trainer, mentor, and consultant on the RUP and its predecessors since 1992 and was the original product manager for the RUP when the product team was launched in 1996. He's also been heavily involved in certifying partners and training Rational personnel to deliver services around the RUP. |
Rate this page
| |
