Week 4 Assignment - Software Development PlanScenario-Your team has be.docx

Week 4 Assignment - Software Development Plan
Scenario:
Your team has been tasked with delivering a Section 508-validated application for U.S.
Department of Homeland Security field officers to check potential immigrants for connections to
criminal or terrorist behavior. This application must meet these requirements:
Â· Conform with Section-508 accessibility guidelines.
Â· Allow wireless real-time bidirectional data transfer and database queries with secure servers.
Â· Have a secure login and, after two minutes of non-use, have autolocking that reactivates a
secure login.
Â· Allow for officers working on any day and at any time in offices, from vehicles, and on foot
along the U.S. border and in cities across the country.
Overview
In Week 2, you defined how you will determine user applicability and needs. This week, you
will map out a plan for your project.
Instructions:
Create a 2â€“3-page software development plan for the application you are developing. Include
the following:
Â· List 8â€“10 steps the project will follow from proposal to post-implementation stages for
proper design of the application. Be sure to account for all application constraints in the project
planning steps.
Â· Explain the outcome, process, and resources involved in accomplishing each step. Incorporate
at least 3 credible and relevant resources to support your statements.
Â· Create a Gantt chart that includes each step in the process, the resources involved, and the
estimated duration of time it will take to complete each step. It is recommended that you use
Microsoft Excel to create your chart. You may copy and paste it into your software development
plan document or submit a separate file.
Â· Remember, your audience is your companyâ€™s IT executive. Your writing should be
professional and free of grammar, punctuation, and spelling errors.
Figure 1. The evolution of the Waterfall Model (a) and its long development cycles (analysis,
design, implementation, test) to the shorter, iterative development cycles within, for example,

the Spiral Model (b) to Extreme Programmingâ€™s (c) blending of all these activities, a little at
a time, throughout the entire software development process.
0018-9162/99/$10.00 Â© 1999 IEEE70 Computer
I n the beginning was the waterfall (Figure 1a). We would get the users to tell us once and for all
exactly what they wanted. We would design the system that would deliver those features. We
would code it. We would test to make sure the
features were delivered. All would be well. All was not well. The users didnâ€™t tell us once
and
for all exactly what they wanted. They didnâ€™t know. They contradicted themselves. They
changed their minds. And the users werenâ€™t the only problem. We programmers could think
we were making great progress only to discover three-fourths of the way through that we were
one-third of the way through.
If long development cycles were bad because they couldnâ€™t adapt to changes, perhaps what
we needed was to make shorter development cycles. As Figure 1b
shows, the waterfall begat iterations. The waterfall model didnâ€™t just appear. It was a
rational reaction to the shocking measurement that the cost of changing a piece of software rose
dramatically over time. If thatâ€™s true, then you want to make the biggest, most far-reaching
decisions as early in the life cycle as possible to avoid paying big bucks for them.
The academic software engineering community took the high cost of changing software as a
challenge, creating technologies like relational databases, mod- ular programming, and
information hiding. What if all that hard work paid off? What if we got good at reducing the
costs of ongoing changes? What if we didnâ€™t have to settle for taking a cleaver to the water-
fall? What if we could throw it in a blender?
Extreme Programming turns the conventional software process sideways. Rather than planning,
analyzing, and designing for the far-flung future, XP programmers do all of these activitiesâ€”a
little at a timeâ€”throughout development.
Cover Feature
Embracing Change with Extreme Programming
Kent Beck First Class Software
Co ve
r F ea

tu re
Analysis
Design
Implementation
Test
Time
Scope
IterativeWaterfall XP
(c)(b)(a)
October 1999 71
We might get a picture like the one shown in Figure 1c. Itâ€™s called Extreme Programming.
ANATOMY OF XP XP turns the conventional software process side-
ways. Rather than planning, analyzing, and designing for the far-flung future, XP exploits the
reduction in the cost of changing software to do all of these activities a little at a time, throughout
software development. (The â€œXP Practicesâ€• sidebar will give you a quick grasp of the
practices and philosophy underlying XP. These practices are designed to work together, and
trying to examine any one soon leads you to the rest. The â€œRoots of XPâ€• sidebar on page
73 traces the historical antecedents of these practices.)
XP development cycle Figure 2 shows XP at timescales ranging from years
to days. The customer picks the next release by choosing the most valuable features (called
stories in XP) from among all the possible stories, as informed by the costs of the stories and the
measured speed of the team in implementing stories.
The customer picks the next iterationâ€™s stories by choosing the most valuable stories
remaining in the release, again informed by the costs of the stories and the teamâ€™s speed. The
programmers turn the stories into smaller-grained tasks, which they individually
XP Practices
Here is a quick summary of each of the major practices in XP.

Planning game. Customers decide the scope and timing of releases based on estimates provided
by programmers. Programmers implement only the functionality demanded by the stories in
this iteration.
Small releases. The system is put into production in a few months, before solving the whole
problem. New releases are made oftenâ€”anywhere from daily to monthly.
Metaphor. The shape of the system is defined by a metaphor or set of metaphors shared between
the customer and programmers.
Simple design. At every moment, the design runs all the tests, communi- cates everything the
programmers want to communicate, contains no
duplicate code, and has the fewest possible classes and methods. This rule can be summarized as,
â€œSay everything once and only once.â€•
Tests. Programmers write unit tests minute by minute. These tests are collected and they must
all run correctly. Customers write functional tests for the stories in an iteration. These tests
should also all run, although practically speaking, sometimes a business decision must be made
comparing the cost of shipping a known defect and the cost of delay.
Refactoring. The design of the system is evolved through transformations of the existing design
that keep all the tests running.
Pair programming. All production code is written by two people at one screen/keyboard/mouse.
Continuous integration. New code is integrated with the current system after no more than a few
hours.
When integrating, the system is built from scratch and all tests must pass or the changes are
discarded.
Collective ownership. Every programmer improves any code anywhere in the system at any
time if they see the opportunity.
On-site customer. A customer sits with the team full-time.
40-hour weeks. No one can work a second consecutive week of overtime. Even isolated
overtime used too frequently is a sign of deeper problems that must be addressed.
Open workspace. The team works in a large room with small cubicles around the periphery. Pair
programmers work on computers set up in the center.
Just rules. By being part of an Extreme team, you sign up to follow the rules. But theyâ€™re just
the rules. The team can change the rules at any time as long as they agree on how they will
assess the effects of the change.

accept responsibility for. Then the programmer turns a task into a set of test
cases that will demonstrate that the task is finished. Working with a partner, the programmer
makes the test cases run, evolving the design in the meantime to maintain the simplest possible
design for the system as a whole.
Stories XP considers the period before a system first goes
into production to be a dangerous anomaly in the life of the project and to be gotten over as
quickly as possible. However, every project has to start somewhere.
The first decisions to make about the project are what it could do and what it should do first.
These decisions are typically the province of analysis, hence the thin blue analysis rectangle at
the top of Figure 1c. You canâ€™t program until you know what youâ€™re programming.
You put the overall analysis together in terms of stories, which you can think of as the amount of
a use case that will fit on an index card. Each story must be business-oriented, testable, and
estimable.
A month is a good long time to come up with the stories for a 10 person-year project. Itâ€™s
true that it isnâ€™t enough to explore all of the possible issues thoroughly. But forever
isnâ€™t long enough to explore all of the issues thoroughly if you never implement.
72 Computer
Release Notice in Figure 2 that we donâ€™t implement all of
the stories at first. Instead, the customer chooses the smallest set of the most valuable stories that
make sense together. First we implement those and put them into production. After that weâ€™ll
implement all the rest.
Picking the scope for a release is a little like shop- ping for groceries. You go to the store with
$100 in your pocket. You think about your priorities. You look at the prices on the items. You
decide what to buy.
In the planning game (the XP planning process), the items are the stories. The prices are the
estimates on the stories. The budget is calculated by measuring the teamâ€™s output in terms of
estimated stories delivered per unit time.
The customer can either load up a cart (pick a set of stories) and have the programmers calculate
the finish date or pick a date and have the programmers calculate the budget, then choose
stories until they add up.
Iteration The goal of each iteration is to put into production

some new stories that are tested and ready to go. The process starts with a plan that sets out the
stories to be implemented and breaks out how the team will accomplish it. While the team is
implementing, the customer is specifying functional tests. At the end of the iteration, the tests
should run and the team should be ready for the next iteration.
Iteration planning starts by again asking the customer to pick the most valuable stories, this
time out
of the stories remaining to be implemented in this release. The team breaks the stories down into
tasks, units of implementation that one person could implement in a few days. If there are
technical tasks, like upgrading to a new version of a database, they get put on the list too.
Next, programmers sign up for the tasks they want to be responsible for implementing. After all
the tasks are spoken for, the programmer responsible for a task estimates it, this time in ideal
programming days. Everyoneâ€™s task estimates are added up, and if some programmers are
over and some are under, the under- committed programmers take more tasks.
Over the course of the iteration, the programmers implement their tasks. As they complete each
task, they integrate its code and tests with the current system. All tests must run or the code
cannot be integrated.
As the customer delivers the functional tests during the iteration, they are added to the suite. At
the end of the iteration, all unit tests and all functional tests run.
Task To implement a task, the responsible programmer
first finds a partner because all production code is written with two people at one machine. If
there is any question about the scope or implementation approach, the partners will have a short
(15-minute) meeting with the customer and/or with the programmers most knowledgeable about
the code most likely to be touched during implementation.
Release
Years
Months
Weeks
Days
Iteration
Implementation
Stories

Tasks
Tests
Figure 2. XP according to various timescales. At the scale of months and years, you have the
stories in this release and then the stories in future releases. At the scale of weeks and months,
you have stories in this iteration and then the stories remaining in this release. At the scale of
days and weeks, you have the task you are working on now and then the rest of the tasks in the
iteration. And at the scale of minutes and days, you have the test case you are working on now
and then the rest of the test cases that you can imagine.
From this meeting, the partners condense the list of test cases that need to run before the task is
done. They pick a test case from the list that they are confident they can implement and that will
teach them something about the task. They code up the test case. If the test case already runs,
they go on. Normally, though, there is work to be done.
When we have a test case and it doesnâ€™t run, either
â€¢ we can see a clean way to make it run, in which case we make it run; or
â€¢ we can see an ugly way to make it run, but we can imagine a new design in which it could be
made to run cleanly, in which case we refactor the system to make it run cleanly; or
â€¢ we can see an ugly way to make it run, but we canâ€™t imagine any refactoring, in which
case we make it run the ugly way.
After the test case runs, if we see how to refactor
the system to make it even cleaner, we do so. Perhaps during the implementation of this test case
we imagine another test case that should also run. We note the new test case on our list and
continue. Perhaps we spot a bigger refactoring that doesnâ€™t fit into the scope of our current
test. We also note that and continue. The goal is to remain focused so we can do a good job and
at the same time not lose the ben- efits of the insights that come during intense interac- tion with
code.
Test If there is a technique at the heart of XP, it is unit
testing. As you saw above, unit testing is part of every programmerâ€™s daily business. In XP,
however, two twists on conventional testing strategies make tests far more effective:
Programmers write their own tests and they write these tests before they code. If programming
is about learning, and learning is about getting lots of feedback as quickly as possible, then you
October 1999 73
Roots of XP

The individual practices in XP are not by any means new. Many people have come to similar
conclusions about the best way to deliver software in environments where requirements change
vio- lently.1-3
The strict split between business and technical decision making in XP comes from the work of
the architect Christo- pher Alexander, in particular his work The Timeless Way of Building,4
where he says that the people who occupy a structure should (in conjunction with a building
professional) be the ones to make the high-impact decisions about it.
XPâ€™s rapid evolution of a plan in response to business or technical changes echoes the Scrum
methodology5 and Ward Cunninghamâ€™s Episodes pattern language.6
The emphasis on specifying and sched- uling projects from the perspective of features comes
from Ivar Jacobsonâ€™s work on use cases.7
Tom Gilb is the guru of evolutionary delivery. His recent writings on EVO8
focus on getting the software into production in a matter of weeks, then growing it from there.
Barry Boehmâ€™s Spiral Model was the initial response to the waterfall.9 Dave
Thomas and his colleagues at Object Technology International have long been champions of
exploiting powerful technology with their JIT method.10
XPâ€™s use of metaphors comes from George Lakoff and Mark Johnsonâ€™s books, the latest
of which is Philosophy in the Flesh.11 It also comes from Richard Coyne, who links metaphor
with software development from the perspective of postmodern philosophy.12
Finally, XPâ€™s attitude toward the effects of office space on programmers comes from Jim
Coplien,13 Tom DeMarco, and Tim Lister,14 who talk about the impor- tance of the physical
environment on programmers.
References 1. J. Wood and D. Silver, Joint Application
Development, John Wiley & Sons, New York, 1995.
2. J. Martin, Rapid Application Development, Prentice Hall,Upper Saddle River, N.J.,1992.
3. J. Stapleton, Dynamic Systems Develop- ment Method, Addison Wesley Longman, Reading,
Mass., 1997.
4. C. Alexander, The Timeless Way of Build- ing, Oxford University Press, New York, 1979.
5. H. Takeuchi and I. Nonaka, â€œThe New Product Development Game,â€• Harvard
Business Rev., Jan./Feb. 1986, pp. 137- 146.

6. W. Cunningham, â€œEpisodes: A Pattern Language of Competitive Development,â€• Pattern
Languages of Program Design 2, J. Vlissides, ed., Addison-Wesley, New York, 1996.
7. I. Jacobsen, Object-Oriented Software Engineering, Addison-Wesley, New York, 1994.
8. T. Gilb, Principles of Software Engineer- ing Management, Addison-Wesley, Wok- ingham,
UK, 1988.
9. B. Boehm, â€œA Spiral Model of Software Development and Enhancement,â€• Com- puter,
May 1988, pp. 61-72.
10. D. Thomas, â€œWeb Time Software Devel- opment,â€• Software Development, Oct. 1998,
p. 80.
11. G. Lakoff and M. Johnson, Philosophy in the Flesh, Basic Books, New York, 1998.
12. R. Coyne, Designing Information Tech- nology in the Postmodern Age, MIT Press,
Cambridge, Mass., 1995.
13. J.O. Coplien, â€œA Generative Development Process Pattern Language,â€• The Patterns
Handbook, L. Rising, ed., Cambridge Uni- versity Press, New York, 1998, pp. 243- 300.
14. T. DeMarco and T. Lister, Peopleware, Dorset House, New York, 1999.
74 Computer
can learn much from tests written by someone else days or weeks after the code. XP primarily
addresses the accepted wisdom that programmers canâ€™t possibly test their own code by
having you write code in pairs.
Some methodologies, like Cleanroom,1 prohibit programmers testing or in some cases even
com- piling their own programs. The usual process has a programmer write some code, compile
it, make sure it works, then pass it on to a testing organization. The bench testing takes the form
of single- stepping through the code and watching variables, or interpreting the results of print
statements, or poking a few buttons to make sure the list item turns green.
The XP testing strategy doesnâ€™t ask any more work than the usual bench testing strategies. It
just changes the form of the tests. Instead of activities that evapo- rate into the ether as soon as
they are finished, you record the tests in a permanent form. These tests will run automatically
today, and this afternoon after we all integrate, and tomorrow, and next week, and next
year. The confidence they embody accumulates, so an XP team gains confidence in the behavior
of its system over time.
As I mentioned earlier, tests also come from the customers. At the beginning of an iteration, the
customers think about what would convince them that the stories for an iteration are completed.

These thoughts are converted into systemwide tests, either directly by the customer using a
textual or graphical scripting language or by the programmers using their own testing tools.
These tests, too, accumulate confidence, but in this case they accumulate the customerâ€™s
confidence in the correct operation of the system.
WHEN SOMETHING GOES WRONG Talking about how a method works when it works
perfectly is about like describing precisely how you will descend a monstrous patch of white
water. What is interesting is precisely what you will do when the unexpected or undesired
happens. Here are some common failures and possible Extreme reactions.
Acxiom: Working toward a Common Goal
Jim Hannula, Acxiom
On top of a data warehouse, Acxiom built a campaign management application using
FortÃ©â€™s distributed OO development tool. The small development teamâ€”consisting of
10 developersâ€”built the application by relying on sound OO principles and a strong team
development approach.
During the final two years of the appli- cationâ€™s three years of development, the
teamâ€”comprised of managers, business analysts, developers, testers, and technical
writersâ€”used Extreme Programming techniques, which proved to be instru- mental in our
success.
We know we have a good design if itâ€™s simple. Some of our past designs tried even to
account for future iterations of our application. We discovered that we were not very good at
that. If we use patterns and communicate well, we can develop a sound application that is flexi-
ble and can still be modified in the future.
Refactoring is a major part of our development effort. It was evident to us that if we were afraid
to change some code because we did not know what it
did, we were not very good developers. We were letting the code control us. If we donâ€™t
know what the code does now, we break it and find out. It is better to implement a solid piece
of code than it is to let a piece of code control the application.
Unit testing was a hard piece to implement because FortÃ© did not have a ready- built testing
framework. We developed our own testing framework and have been successful implementing it.
Recently we started using Java as a development language and now use JUnit as a testing tool.
The key to XP is setting developer and team expectations. We have found all developers on the
team must buy into Extreme or it doesnâ€™t work. We tell prospective developers if they do not
want to follow our development style, this is not a good team for them. One person not buying
in to the approach will bring down the whole team. XP focuses on the team working together to
come up with new ideas to develop the system.

When we first started with XP, some of the developers did not want to follow it. They felt that it
would hurt their development style and that they would not be as productive. What happened
was that their pieces of the application were producing the most problem reports. Since
they were not developing in pairs, two people had not designed the subsystem and their skills
were falling behind the other developers who were learning from each other. Two well-trained
developers working together and with the rest of the team will always outperform one â€œintel-
ligentâ€• developer working alone.
A misconception about XP is that it sti- fles your creativity and individual growth. Itâ€™s
actually quite the contrary. XP stimu- lates growth and creativity and encourages team members
to take chances. The key is to decide the direction of the corporation and stand behind the hard
decisions.
XP is not extreme to our team. Itâ€™s a method that uses a common-sense development
approach. Everyone works together toward a common goal.
Team: managers, business analysts, developers, testers, and technical writers
Application: campaign management dbase
Time: three years
October 1999 75
Underestimation From time to time you will commit to more than
you can accomplish. You must reduce the occurrence of underestimation as much as possible by
getting lots of practice estimating. If you are overcommited, you first try to solve the problem in
the family. Have you slipped away from the practices? Are you testing, pairing, refactoring,
and integrating as well as you can? Are you delivering more than the customer needs in places?
If you canâ€™t find any way to go faster, you have to ask the customer for relief. Staying
committed to more work than you can confidently complete is a recipe for frustration, slipping
quality, and burnout. Donâ€™t do that. Re-estimate based on what youâ€™ve learned, then ask
the customer to reschedule. We can only complete two out of three stories, so which two should
we finish and which one goes in the next iteration or release? Is there a story that has more
critical parts and less
critical parts so we can split it and deliver the most important parts now and the less important
parts later?
Uncooperative customers What if you get a customer who just wonâ€™t play the
game? They wonâ€™t specify tests, they wonâ€™t decide on priorities, they wonâ€™t write
stories. First, by complet- ing functionality iteration after iteration, and by giving the customer

clear control over development, you are trying to build a trust relationship with the customer. If
trust begins to break down, figure out if itâ€™s your fault. Can you do a better job of
communicating?
If you canâ€™t solve the problem on your own, you have to ask the customer for help. Extreme
programmers simply donâ€™t go ahead based on their own guesses. Explain or demonstrate the
consequences to the customer. If they donâ€™t change, make your concerns more visible. If no
one cares enough to solve the problem, perhaps the project isnâ€™t a high enough priority to go
on.
DaimlerChrysler: The Best Team in the World
Chet Hendrickson, DaimlerChrysler
The C3 project began in January 1995 under a fixed-priced contract that called for a joint team of
Chrysler and contract partner employees. Most of the development work had been completed
by early 1996. Our contract partners had used a very GUI-centered development methodology,
which had ignored automated testing. As a result, we had a payroll system that had a lot of very
cool GUIs, calculated most employeesâ€™ pay incorrectly, and would need about 100 days to
generate the monthly payroll. Most of us knew the program we had written would never go into
production.
We sought Kent Beck to help with performance tuning. He found what he had often found
when brought in to do performance tuning: poorly factored code, no repeatable tests, and a
management that had lost confidence in the project. He went to Chrysler Information Services
management and told them what he had found, and that he knew how to fix it. Throw all the
existing code away! The first full XP project was born.
We brought Kent in as head coach; he would spend about a week per month with us. Ron Jeffries
was brought in as
Kentâ€™s full-time eyes and ears. The fixed- price contract was cancelled, and about one-half of
the Chrysler developers were reassigned. Martin Fowler, who had been advising the Chrysler
side of the project all along and clashing with the fixed-price contractor, came in to help the
customers develop user stories. From there, we fol- lowed Kent as he made up the rules of XP. A
commitment schedule was developed, iterations were laid out, rules for testing were established,
and paired programming was tried and accepted as the standard.
At the end of 33 weeks, we had a system that was ready to begin performance tuning and
parallel testing. Ready to begin tuning because it was well factored and backed up by a full
battery of unit tests. And, ready to begin parallel testing because a suite of functional tests had
shown the customers that the required functionality was present.
That increment of C3 launched in May 1997, not as soon as we had hoped. We were slowed by
two factors. First, we had decided to replace only the internals of the payroll system. We left all
of the external interfaces intact. Matching up the output from our new system to the old payroll

master ended up being a much larger task then we had originally estimated. Second, we decided
not to launch during any pay period with special processing require-
ments, such as W-2 processing, profit sharing, or general merit pay increases. This effectively
eliminates November through April.
Since the launch of the monthly system, weâ€™ve added several new features, and we have
enhanced the system to pay the biweekly paid population. We have been paying a pilot group
since August 1998 and will roll out the rest before the Y2K code freeze in November 1999.
Looking back on this long development experience, I can say that when we have fallen short of
keeping our promises to our management and our customers, it has been because we have
strayed from the principles of XP. When we have driven our development with tests, when we
have written code in pairs, when we have done the simplest thing that could possibly work, we
have been the best software development team on the face of the earth.
Team: 10 programmers, 15 total Application: large-scale payroll system
Time: four years
Turnover What if someone leaves? Wonâ€™t you be stuck with-
out documents and reviews? First, a certain amount of turnover is good for the team and for the
people on the team. However, youâ€™d like people to leave for positive reasons. If
programmers go home at the end of every week seeing the concrete things they have accom-
plished for the customer, they are less likely to get frus- trated and leave.
When someone leaves an XP project, it isnâ€™t like they can take away any secrets that only
they know. Two people were watching every line go into the system. And whatever
information does walk out the door, it canâ€™t hurt the team too much because they can run the
tests to ensure that they havenâ€™t broken anything out of ignorance.
New people on an XP team spend the first couple of iterations just pairing with more
experienced people, reading tests, and talking with the customer. When they feel ready, they
can accept responsibility for tasks. Over the course of the next few iterations, their personal
velocity will rise as they demonstrate that they can deliver their tasks on time. After a few
months, they are indistinguishable from the old salts.
Programmers that donâ€™t work out with the team are a problem, too. XP is an intensely social
activity, and not everyone can learn it. It also requires aban-
doning old habits, which can be difficult, especially for high-status programmers. In the end,
though, the many forms of feedback in XP make it clear who is working out and who isnâ€™t.
Someone who consis- tently doesnâ€™t complete tasks, whose integrations cause problems for
other people, who doesnâ€™t refactor, pair, or test â€¦. Everyone on the team knows the score.
And the team is better off without that person, no matter how skilled.

Changing requirements The bugaboo of most software development is just
not a problem in XP. By designing for today, an XP system is equally prepared to go any
direction tomorrow. Things that are like what youâ€™ve already done will be easier, just by the
nature of refactoring to satisfy â€œonce and only once,â€• but those are precisely the things that
are most likely to happen. However, should a radically new requirement arise, you wonâ€™t
have to unwind (or live with) a lot of mechanism built on speculation.
I didnâ€™t initially realize the extent to which XP can adapt to changing requirements. The first
version of XP assigned stories to all the iterations in a release, as part of release planning. The
team discovered that they could get better results with less planning by only asking the customer
to pick which stories should be in the present iteration. If a new story comes up, you
76 Computer
Ford Motor: A Unique Combination of Agility and Quality
Don Wells, Ford Motor
Finance Systems at Ford Motor has been developing the Vehicle Costing and Profit System
(VCAPS), an analysis tool that produces reports on production rev- enues, expenses, net income,
and profit. The input is a bill of materials, fixed costs and expenses, and variable costs such as
labor hours. VCAPS assembles this data into detailed cost analysis reports to support corporate-
level forecasting and decision making.
Ford started VCAPS in 1993 and built it with VisualWorks and GemStone Smalltalk. VCAPS is
now being maintained with a small staff and is to be replaced with a newer system.
The VCAPS project challenged us two ways. First, the analysts wanted modifica- tions and new
functionality before each run. Constantly changing requirements kept us in reaction mode. We
never caught
up. Second, the system needed to be run in a limited span of time. But the system took a long
time to process and required lengthy manual input before producing final output. A bug could
waste precious time by requiring a rerun.
XP offered us a unique combination: agility to meet the volatile requirements on time and quality
to avoid the dreaded rerun.
We began XP with the planning game. It was a failure. Customers and management were
unaccustomed to negotiating schedules. The commitment schedule pro- duced was perceived as
lacking credibility and utility. We had to swap in Microsoft Project schedules, which could be
modified without large meetings and could produce the kinds of artifacts management was
used to seeing and taking action on.

We continued by adding a few unit tests. Automated unit testing was an enormous success. After
a year, we had 40 percent test coverage and management had measured a 40 percent drop in
bug reports. XP was being noticed.
We solved problems by adding XP practices. Tests enabled continuous integration and small
releases. These allowed us to roll in collective ownership and refactoring. We were working
toward simple design. Building momentum, we tried pair programming. We had to work hard to
get pair programming going. Our developers found it awkward; it took a while to become
comfortable.
After a year and a half, the decrease in system failures had reduced the number of emergency
releases to a point where customers and managers noticed far greater system stability. Overall,
XP was very successful in our environment.
Team: 12 programmers, 17 total Application: cost analysis system Time: six years
October 1999 77
Tariff System: Tests You Can Read Rob Mee, Independent consultant
Tariff System is a subsystem of a large Smalltalk/GemStone project at a major international
container-shipping company. Using XP practices, Tariff System was taken from inception to
production in three months by a team of three. The resulting system proved to be unusually
stable and easy to maintain.
At the outset of the project, the team resolved to adhere to several core XP practices: always
program in pairs, use the simplest design possible, refactor aggressively, and write extensive
unit tests. All of these practices were very effective. One XP idea that initially seemed far-
fetched was writing tests before writing the code that sat- isfied them. We were surprised to
find that in fact this helped bring our designs into focus, enabling us to work more quickly.
Another practice we employed from the beginning was collecting requirements from users in the
form of user stories. We
had mixed results with this. As programmers focused on coding, we found the role of
facilitating and negotiating with users difficult. More important was the fact that users needed
lots of help writing stories that were both relevant and unambiguous. In the end, we felt that
perhaps XP was missing a project role. We needed someone from the development team whose
primary focusâ€”and particular talentâ€” was interacting with users.
In our efforts to refactor test cases and fix- tures, we discovered that creating little languages
for our major domain objects dramatically improved the readability and brevity of our test code.
It also practically eliminated the time we spent thinking about how to create object instances
when writing tests. We defined grammars for about ten of our domain classes. Hereâ€™s a
simple example used to construct a Service Offering:

newFromString: â€˜from Oakland to Tokyo shipping toys: 20ft containers $500; 40ft containers
$1000â€™.
The constructor uses a parser, automatically generated from a grammar, to produce the
domain object. The code to instantiate this object using standard con- structors would have taken
many lines, would have been difficult to read, and would have distracted from the test case itself.
Eventually, we discovered that we could combine the individual domain languages into a larger
description of the system as a whole, which proved to be a valuable tool in the expression of
functional tests.
donâ€™t have to shuffle the remainder of the iterations, you just put it in the pile. One or two
weeks later, if the story still seems urgent, the customer will pick it.
Planning one iteration at a time also introduces a pleasing self-similarity. At the scale of months
and years, you have the stories in this release and then the stories in future releases. At the scale
of weeks and months, you have stories in this iteration and then the stories remaining in this
release. At the scale of days and weeks, you have the task you are working on now and then the
rest of the tasks in the iteration. And at the scale of minutes and days, you have the test case you
are working on now and then the rest of the test cases that you can imagine.
X P is by no means a finished, polished idea. The limits of its application are not clear. To try it
today would require courage, flexibility, and a
willingness to abandon the project should your use of XP be failing.
My strategy is first to try XP where it is clearly applicable: outsourced or in-house development
of small- to medium-sized systems where requirements are vague and likely to change. When we
begin to refine XP, we can begin to try to reduce the cost of change in more challenging
environments.
If you want to try XP, for goodness sake donâ€™t try to swallow it all at once. Pick the worst
problem in your current process and try solving it the XP way. When it isnâ€™t your worst
problem any more, rinse and repeat. As you go along, if you find that any of your old practices
arenâ€™t helping, stop doing them.
This adoption process gives you a chance to build your own development styleâ€”which you will
have to do in any caseâ€”to mitigate the risks should XP not work for you and to continue
delivering as you change. â•–
Reference 1. S. Prowell et al., Cleanroom Software Engineering,
Addison Wesley Longman, Reading, Mass., 1999.
Kent Beck owns and operates First Class Software, your typical one-person consulting company
mas- querading behind a fancy name and an answering machine. In addition to two books and 50

articles, he is the author of the forthcoming Extreme Program- ming Explained: Embrace Change
(Addison Wesley Longman, Reading, Mass., 2000). Contact him at [emailÂ protected]
Team: three developers Application: shipping tariff cal-
culation system Time: three months
Copyright Â© 2002 Poppendieck.LLC Page 1
Principles of Lean Thinking
Mary Poppendieck Poppendieck.LLC
7666 Carnelian Lane Eden Prairie, MN 55346 USA
952-934-7998 [emailÂ protected]
Abstract
In the 1980â€™s, a massive paradigm shift hit factories throughout the US and Europe. Mass
production and scientific management techniques from the early 1900â€™s were questioned as
Japanese manufacturing companies demonstrated that â€˜Just-in-Timeâ€™ was a better
paradigm. The widely adopted Japanese manufacturing concepts came to be known as â€˜lean
productionâ€™. In time, the abstractions behind lean production spread to logistics, and from
there to the military, to construction, and to the service industry. As it turns out, principles of
lean thinking are universal and have been applied successfully across many disciplines.
Lean principles have proven not only to be universal, but to be universally successful at
improving results. When appropriately applied, lean thinking is a well- understood and well-
tested platform upon which to build agile software development practices.
Introduction
Call a doctor for a routine appointment and chances are it will be scheduled a few weeks later.
But one large HMO in Minnesota schedules almost all patients within a day or two of their call,
for just about any kind of medical service. A while ago, this HMO decided to worked off their
schedule backlogs by extending their hours, and then vary their hours slightly from week to week
to keep the backlog to about a day. True, the doctors donâ€™t have the comforting weeks-long
list of scheduled patients, but in fact, they see just as many patients for the same reasons as they
did before. The patients are much happier, and doctors detect medical problems far earlier than
they used to.
The idea of delivering packages overnight was novel when Federal Express was started in 1971.
In 1983, a new company called Lens Crafters changed the basis of competition in the eyeglasses
industry by assembling prescription glasses in an hour. The concept of

shipping products the same day they were ordered was a breakthrough concept when LL Bean
upgraded its distribution system in the late 1980â€™s. Southwest Airlines, one of the few
profitable airlines these days, saves a lot of money with its unorthodox method of assigning seats
as people arrive at the airport. Dell maintains profitability in a cutthroat market by manufacturing
to order in less than a week. Another Austin company builds custom homes in 30 days.
The common denominator behind these and many other industry-rattling success stories is lean
thinking. Lean thinking looks at the value chain and asks: How can things be structured so that
the enterprise does nothing but add value, and does that as rapidly as possible? All the
intermediate steps, all the intermediate time and all the intermediate people are eliminated. All
thatâ€™s left are the time, the people and the activities that add value for the customer.
Origins of Lean Thinking Lean thinking got its name from a 1990â€™s best seller called The
Machine That Changed the World : The Story of Lean Production1. This book chronicles the
movement of automobile manufacturing from craft production to mass production to lean
production. It tells the story of how Henry Ford standardized automobile parts and assembly
techniques, so that low skilled workers and specialized machines could make cheap cars for the
masses. The book goes on to describe how mass production provided cheaper cars than the craft
production, but resulted an explosion of indirect labor: production planning, engineering, and
management. Then the book explains how a small company set its sights set on manufacturing
cars for Japan, but it could not afford the enormous investment in single purpose machines that
seemed to be required.
1 The Machine That Changed the World : The Story of Lean Production, by Womack, James P.,
Daniel T. Jones, and Daniel Roos, New York: Rawson and Associates; 1990.
Nor could it afford the inventory or large amount of indirect labor that seemed necessary for
mass production. So it invented a better way to do things, using very low inventory and moving
decision-making to production workers. Now this small company has grown into a large
company, and the Toyota Production System has become known as â€˜lean productionâ€™.
â€œThe mass-producer uses narrowly skilled professionals to design products make by unskilled
or semiskilled workers tending expensive, single-purpose machines. These churn out
standardized products at high volume. Because the machinery costs so much and is so intolerant
of disruption, the mass-producer adds many buffers â€“ extra supplies, extra workers, and extra
space â€“ to assure smooth productionâ€¦. The result: The customer gets lower costs but at the
expense of variety and by means of work methods that most employees find boring and
dispiriting.â€•2
Think of the centralized eyeglasses laboratory. Remember that Sears used to take two or three
weeks to fill orders from its once-popular catalog. Recall the long distribution channel that used
to be standard in the computer market. Think dinosaurs. Centralized equipment, huge
distribution centers and lengthy distribution channels were created to realize economies of scale.
They are the side effects of mass-production, passed on to other industries. What people tend to

overlook is that mass-production creates a tremendous amount of work that does not directly add
value. Shipping eyeglasses to a factory for one hour of processing adds more handling time by
far than the processing time to make the glasses. Adding retail distribution to the cutthroat
personal computer industry means that a manufacturer needs six weeks to respond to changing
technology, instead of six days. Searsâ€™ practice of building an inventory of mail orders to fill
meant keeping track of stacks of orders, not to mention responding to innumerable order status
queries and constant order changes.
â€œThe lean producer, by contrast, combines the advantages of craft and mass production, while
avoiding the high cost of the former and the rigidity of the laterâ€¦ Lean production is
â€˜leanâ€™ because it uses less of everything compared with mass production â€“ half the
human effort in the factory, half the manufacturing space, half the investment in tools, half the
engineering hours to develop a new product in half the time. Also, it requires keeping far less
than half the inventory on site, results in many fewer defects, and
2 Womack (1990) p 13.
produces a greater and ever growing variety of products.â€•3
While on a tour of a large customer, Michael Dell saw technicians customizing new Dell
computers with their companyâ€™s â€˜standardâ€™ hardware and software. â€œDo you think
you guys could do this for me?â€• his host asked. Without missing a beat, Dell replied,
â€œAbsolutely, weâ€™d love to do that.â€•4 Within a couple of weeks, Dell was shipping
computers with factory-installed, customer- specific hardware and software. What took the
customer an hour could be done in the factory in minutes, and furthermore, computers could be
shipped directly to end-users rather than making a stop in the corporate IT department. This
shortening of the value chain is the essence of lean thinking.
Companies that re-think the value chain and find ways to provide what their customers value
with significantly fewer resources than their competitors can develop an unassailable competitive
advantage. Sometimes competitors are simply not able to deliver the new value proposition.
(Many have tired to copy Dell; few have succeeded.) Sometimes competitors do not care to copy
a new concept. (Southwest Airlines has not changed the industryâ€™s approach to seat
assignments.) Sometimes the industry follows the leader, but it takes time. (Almost all direct
merchandise is shipped within a day or two of receiving an order these days, but the Sears
catalog has been discontinued.)
Lean Thinking in Software Development eBay is a company which pretty much invented
â€˜leanâ€™ trading by eliminating all the unnecessary steps in the trading value chain. In the
mid 1990â€™s, basic eBay software capabilities were developed by responding daily to
customer requests for improvements.5 Customers would send an e-mail to Pierre Omidyar with a
suggestion and he would implement the idea on the site that night. The most popular features of
eBay, those which create the highest competitive advantage, were created in this manner.
Digital River invented the software download market in the mid 1990â€™s by focusing on
â€˜leanâ€™ software delivery. Today Digital River routinely designs and deploys

3 Womack (1990) p 13. 4 Direct from Dell, by Michael Dell with Catherine Fredman, Harper
Business, 1999, p 159 5 Q&A with eBay's Pierre Omidyar, Business Week Online, December 3,
2001.
sophisticated web sites for corporate customers in a matter of a weeks, by tying the
corporationâ€™s legacy databases to standard front end components customized with a â€˜look
and feelâ€™ specific to each customer.
In the mid 1990â€™s, Microsoft implemented corporate- wide financial, purchasing and human
resource packages linked to data warehouses which can be accessed via web front-ends. Each
was implemented by â€œa handful of seasoned IT and functional expertsâ€¦ (who got) the job
done in the time it takes a â€¦ committee to decide on its goals.â€•6
In each of these examples, the focus of software development was on rapid response to an
identified need. Mechanisms were put in place to dramatically shorten the time from problem
recognition to software solution. You might call it â€˜Just-in-Timeâ€™ software development.
The question is â€“ why isnâ€™t all software developed quickly? The answer is â€“ rapid
development must be considered important before it becomes a reality. Once speed becomes a
value, a paradigm shift has to take place, changing software development practices from the
mass production paradigm to lean thinking.
If your company writes reams of requirements documents (equivalent to inventory), spends
hours upon hours tracking change control (equivalent to order tracking), and has an office which
defines and monitors the software development process (equivalent to industrial engineering),
you are operating with mass- production paradigms. Think â€˜leanâ€™ and you will find a better
way.
Basic Principles of Lean Development
There are four basic principles of lean thinking which are most relevant to software
development:
The Basic Principles of Lean Development Add Nothing But Value (Eliminate Waste) Center
On The People Who Add Value
Flow Value From Demand (Delay Commitment) Optimize Across Organizations
6 Inside Microsoft: Balancing Creativity and Discipline, Herbold, Robert J.; Harvard Business
Review, January 2002.
Add Nothing But Value (Eliminate Waste) The first step in lean thinking is to understand what
value is and what activities and resources are absolutely necessary to create that value. Once this
is understood, everything else is waste. Since no one wants to consider what they do as waste,

the job of determining what value is and what adds value is something that needs to be done at a
fairly high level. Letâ€™s say you are developing order tracking software. It seems like it would
be very important for a customer to know the status of their order, so this would certainly add
customer value. But actually, if the order is in house for less than 24 hours, the only order status
that is necessary is to inform the customer that the order was received, and then that it has
shipped, and let them know the shipping tracking number. Better yet, if the order can be fulfilled
by downloading it on the Web, there really isnâ€™t any order status necessary at all.
To develop breakthroughs with lean thinking, the first step is learning to see waste. If something
does not directly add value, it is waste. If there is a way to do without it, it is waste. Taiichi
Ohno, the mastermind of the Toyota Production System, identified seven types of manufacturing
waste:
The Seven Wastes of Manufacturing Overproduction
Inventory Extra Processing Steps
Motion Defects Waiting
Transportation
Here is how I would translate the seven wastes of manufacturing to software development:
The Seven Wastes of Software Development Overproduction = Extra Features
Inventory = Requirements Extra Processing Steps = Extra Steps
Motion = Finding Information Defects = Defects Not Caught by Tests Waiting = Waiting,
Including Customers
Transportation = Handoffs
Extreme Programming (XP) is a set of practices which focuses on rapid software development. It
is interesting to examine how XP works to eliminate the seven wastes of software development:
Waste in Software Development
How Extreme Programming Addresses Waste
Extra Features Develop only for todayâ€™s stories
Requirements Story cards are detailed only for the current iteration
Extra Steps Code directly from stories; get verbal clarification directly from customers

Finding Information Have everyone in the same room; customer included
Defects Not Caught by Tests
Test first; both developer tests and customer tests
Waiting, Including Customers Deliver in small increments
Handoffs Developers work directly with customers
â€˜Do It Right The First Timeâ€™ XP advocates developing software for the current need, and
as more â€˜storiesâ€™ (requirements) are added, the design should be â€˜refactoredâ€™7 to
accommodate the new stories. Is it waste to refactor software? Shouldnâ€™t developers â€œDo
It Right the First Time?â€•
It is instructive to explore the origins of the slogan â€œDo It Right the First Time.â€• In the
1980â€™s it was very difficult to change a mass-production plant to lean production, because in
mass production, workers were not expected to take responsibility for the quality of the product.
To change this, the management structure of the plant had to change. â€œWorkers respond only
when there exists some sense of reciprocal obligation, a sense that management actually values
skilled workers, â€¦ and is willing to delegate responsibility to [them].â€8 The slogan â€œDo It
Right the First Timeâ€• encouraged workers to feel responsible for the products moving down
the line, and encourage them to stop the line and troubleshoot problems when and where they
occurred.
7 Refactoring is improving the design of software without changing functionality. 8 Womack
(1990) p 99.
In the software industry, the same slogan â€œDo It Right the First Time,â€• has been misused
as an excuse to apply mass-production thinking, not lean thinking to software development.
Under this slogan, responsibility has been taken away from the developers who add value, which
is exactly the opposite of its intended effect. â€œDo It Right the First Timeâ€• has been used as
an excuse to insert reams of paperwork and armies of analysts and designers between the
customer and the developer. In fact, the slogan is only properly applied if it gives developers
more, not less, involvement in the results of their work.
A more appropriate translation of such slogans as â€œZero Defectsâ€ and â€œDo It Right the
First Timeâ€ would be â€œTest Firstâ€. In other words, donâ€™t code unless you
understand what the code is supposed to do and have a way to determine whether the code
works. A good knowledge of the domain coupled with short build cycles and automated testing
constitute the proper way for software developers to â€œDo It Right the First Timeâ€•.
Center On The People Who Add Value Almost every organization claims itâ€™s people are
important, but if they truly center on those who add value, they would be able to say:
The people doing the work are the center of Resources Information

Process Design Authority Decision Making Authority
Organizational Energy
In mass-production, tasks are structured so that low skilled or unskilled workers can easily do the
repetitive work, but engineers and managers are responsible for production. Workers are not
allowed to modify or stop the line, because the focus is to maintain volume. One of the results of
mass-production is that unskilled workers have no incentive to volunteer information about
problems with the manufacturing line or ways to improve the process. Maladjusted parts get
fixed at the end of the line; a poor die or improperly maintained tool is managementâ€™s
problem. Workers are neither trained nor encouraged to worry about such things.
â€œThe truly lean plant has two key organizational features: It transfers the maximum number of
tasks and responsibilities to those workers actually adding value to the car on the line, and it has
in place a system for
detecting defects that quickly traces every problem, once discovered, to its ultimate cause.â€•9
Similarly in any lean enterprise, the focus is on the people who add value. In lean enterprises,
traditional organizational structures give way to new team-oriented organizations which are
centered on the flow of value, not on functional expertise.
The first experiment Taiichi Ohno undertook in developing lean production was to figure out a
way to allow massive, single-purpose stamping machines to stamp out multiple parts. Formerly,
it took skilled machinists hours, if not days, to change dies from one part to another. Therefore,
mass production plants had many single purpose stamping machines in which the dies were
almost never changed. Volume, space, and financing were not available in Japan to support such
massive machines, so Ohno set about devising simple methods to change the stamping dies in
minutes instead of hours. This would allow many parts of a car to be made on the same line with
the same equipment. Since the workers had nothing else to do while the die was being changed,
they also did the die changing, and in fact, the stamping room workers were involved in
developing the methods of rapid die changeover.
Ohno transferred most of the work being done by engineers and managers in mass-production
plants to the production workers. He grouped workers in small teams and trained the teams to do
their own industrial engineering. Workers were encouraged to stop the line if anything went
wrong, (a management job in mass- production). Before the line was re-started, the workers were
expected to search for the root cause of the problem and resolve it. At first the line was stopped
often, which would have been a disaster at a mass- production plant. But eventually the line ran
with very few problems, because the assembly workers felt responsible to find, expose, and
resolve problems as they occurred.
It is sometimes thought that a benefit of good software engineering is to allow low skilled
programmers to produce code while a few high skilled architects and designers do the critical
thinking. With this in mind, a project is often divided into requirements gathering, analysis,

design, coding, testing, and so on, with decreasing skill presumably required at each step. A
â€˜standard processâ€™ is developed for each step, so that low-skilled programmers, for
example, can translate design into code simply by following the process.
9 Womack (1990) p 99. Italics in the original.
This kind of thinking comes from mass-production, where skilled industrial engineers are
expected to design production work for unskilled laborers. It is the antithesis of lean thinking and
devalues the skills of the developers who actually write the code as surely as industrial engineers
telling laborers how to do their jobs devalues the skills of production workers.
Centering on the people who add value means upgrading the skills of developers through training
and apprenticeships. It means forming teams that design their own processes and address
complete problems. It means that staff groups and managers exist to support developers, not to
tell them what to do.
Flow Value From Demand (Delay Commitment)
The idea of flow is fundamental to lean production. If you do nothing but add value, then you
should add the value in as rapid a flow as possible. If this is not the case, then waste builds up in
the form of inventory or transportation or extra steps or wasted motion. The idea that flow should
be â€˜pulledâ€™ from demand is also fundamental to lean production. â€˜Pullâ€™ means that
nothing is done unless and until a downstream process requires it. The effect of â€˜pullâ€™ is
that production is not based on forecast; commitment is delayed until demand is present to
indicate what the customer really wants.
Pulling from demand can be one of the easiest ways to implement lean principles, as LL Bean
and Lens Crafters and Dell found out. The idea is to fill each customer order immediately. In
mass-production days, filling orders immediately meant building up lots of inventory in
anticipation of customer orders. Lean production changes that. The idea is to be able to make the
product so fast that it can be made to order. True, Dell and Lens Crafters and LL Bean and
Toyota have to have some inventory of sub-assemblies waiting to be turned into a finished
product at a moments notice. But itâ€™s amazing how little inventory is necessary, if the
process to replenish the inventory is also lean. A truly lean distribution channel only works with
a really lean supply chain coupled to very lean manufacturing.
The â€œbatch and queueâ€• habit is very hard to break. It seems counterintuitive that doing a
little bit at a time at the last possible moment will give faster, better, cheaper results. But anyone
designing a control system knows that a short feedback loop is far more effective at maintaining
control of a process than a long loop. The problem with batches and queues is that they hide
problems. The idea of lean production is to expose
problems as soon as they arise, so they can be corrected immediately. It may seem that lean
systems are fragile, because they have no padding. But in fact, lean systems are quite robust,

because they donâ€™t hide unknown, lurking problems and they donâ€™t pretend they can
forecast the future.
In Lean Software Development, the idea is to maximize the flow of information and delivered
value. As in lean production, maximizing flow does not mean automation. Instead, it means
limiting what has to be transferred, and transferring that as few times as possible over the
shortest distance with the widest communication bandwidth as late as is possible. Handing off
reams of frozen documentation from one function to the next is a mass-production mentality. In
Lean Software Development, the idea is to eliminate as many documents and handoffs as
possible. Documents which are not useful to the customer are replaced with automated tests.
These tests assure that customer value is delivered both initially and in the future when the
inevitable changes are needed.
In addition to rapid, Just-in-Time information flow, Lean Software Development means rapid,
Just-in-Time delivery of value. In manufacturing, the key to achieving rapid delivery is to
manufacture in small batches pulled by a customer order. Similarly in software development, the
key to rapid delivery is to divide the problem into small batches (increments) pulled by a
customer story and customer test. The single most effective mechanism for implementing lean
production is adopting Just-in-Time, pull-from-demand flow. Similarly, the single most effective
mechanism for implementing Lean Development is delivering increments of real business value
in short time-boxes.
In Lean Software Development, the goal is to eliminate as many documents and handoffs as
possible. The emphasis is to pair a skilled development team with a skilled customer team and
give them the responsibility and authority to develop the system in small, rapid increments,
driven by customer priority and feedback.
Optimize across Organizations Quite often, the biggest barrier to adopting lean practices is
organizational. As products move from one department to another, a big gap often develops,
especially if each department has its own set of performance measurements that are unrelated to
the performance measurements of neighboring departments.
For example, letâ€™s say that the ultimate performance measurement of a stamping room is
machine productivity. This measurement motivates the stamping room to build up mounds of
inventory to keep the machines running at top productivity. It does not matter that the inventory
has been shown to degrade the overall performance of the organization. As long as the stamping
room is measured primarily on machine productivity, it will build inventory. This is what is
known as a sub-optimizing measurement, because it creates behavior which creates local
optimization at the expense of overall optimization.
Sub-optimizing measurements are very common, and overall optimization is virtually impossible
when they are in place. One of the biggest sub-optimizing measurements in software
development occurs when project managers are measured on earned value. Earned value is the
cost initially estimated for the tasks which have been completed. The idea is that you had better
not have spent any more than you estimated. The problem is, this requires a project manager to
build up an inventory of task descriptions and estimates. Just as excess inventory in the stamping

room slows down production and degrades over time, the inventory of tasks required for earned
value calculations gets in the way of delivering true business value and also degrades over time.
Nevertheless, if there is an earned value measurement in place, project tasks are specified and
estimated, and earned value is measured. When it comes to a choice between delivering business
value or earned value (and it often does), earned value usually wins out.
To avoid these problems, lean organizations are usually structured around teams that maintain
responsibility for overall business value, rather than intermediate measurements such as their
ability to speculate and pad estimates. Another approach is to foster a keen awareness that the
downstream department is a customer, and satisfying this internal customer is the ultimate
performance measurement.
The paradigm shift that is required with lean thinking is often hindered if the organization is not
structured around the flow of value and focused on helping the customer pull value from the
enterprise. For this reason, software development teams are best structured around delivering
increments of business value, with all the necessary skills on the same team (eg. customer
understanding / domain knowledge, architecture / design, system development, database
administration, testing, system administration, etc.).
Software Development Contracts Flow along the value stream is particularly difficult when
multiple companies are involved. Many times I have heard the lament: â€œEverything you say
makes sense, but it is impossible to implement in our environment, because we work under
contracts with other organizations.â€• Indeed, the typical software development contract can be
the ultimate sub- optimizing mechanism. Standard software contracts and supplier management
practices have a tendency to interfere with many lean principles.
Manufacturing organizations used to have the same problem. For example, US automotive
companies once believed the best way to reduce the cost of parts in an automobile was with
annual competitive bidding. If the only thing that is important is cheap parts, competitive bidding
may seem like the best way to achieve this goal. However, if overall company performance is
more important, then better parts which integrate more effectively with the overall vehicle are
more valuable. In fact, there is an direct correlation between an automotive companyâ€™s
profitability and its degree of collaboration with suppliers.10 When Chrysler moved from
opportunistic to collaborative relationships with its suppliers in the late 1990â€™s, itâ€™s
performance improved significantly.
The software industry has some lessons to learn in the area of contractual agreements between
organizations. It needs to learn how to structure collaborative relationships which maximize the
overall results of both parties. A key lesson the software industry needs to learn is how to
structure contracts for incremental deliveries that are not pre-defined in the contract, yet assure
the customer of prompt delivery of business value appropriate to their investment. Here again,
we can learn from lean production.

Lean manufacturing organizations develop a limited number of relationships with â€˜trustedâ€™
suppliers, and in turn, gain the â€˜trustâ€™ of these suppliers. What does â€˜trustâ€™ mean?
â€œTrust [is] one partyâ€™s confidence that the other party in the exchange relationship will
fulfill its promises and commitments and will not exploit its vulnerabilities.â€•11
â€œâ€¦trustâ€¦[is] not based on greater interpersonal trust, but rather greater trust in the
10 Collaborative Advantage, by Jeffrey H. Dyer, Oxford University Press; 2000, p 6. 11 Dyer
(2000) p 88.
fairness, stability, and predictability of [the companyâ€™s] routines and processes.â€•12
It has been the practice of legal departments writing software contracts to put into contractual
language all of the protections necessary to keep the other side â€˜honest.â€™ However, the
transaction costs associated with creating and monitoring such contracts are enormous. Many
contracts all but demand a waterfall process, even if both companies believe this is not the best
approach. Itâ€™s time that the software development industry learned the lesson of Supply
Chain Management â€“ â€œExtraordinary productivity gains in the production network or value
chain are possible when companies are willing to collaborate in unique ways, often achieving
competitive advantage by sharing resources, knowledge, and assetsâ€¦. Today competition occurs
between value chains and not simply between companies.â€•13
Summary and Conclusion The lean production metaphor is a good one for software
development, if it is applied in keeping with the underlying spirit of lean thinking. In the past, the
application of some manufacturing concepts to software development (â€˜Do It Right the First
Timeâ€™ comes to mind) may have lacked a deep understanding of what makes lean principles
work. The underlying principles of eliminating waste, empowering front line workers,
responding immediately to customer requests, and optimizing across the value chain are
fundamental to lean thinking. When applied to software development, these concepts provide a
broad framework for improving software development.
12 Dyer (2000) p 100 13 Dyer (2000) p 5
Week 2 Assignment - Proposal
Executive Summary
Homeland security officers include law enforcement officers, first responders, and federal
personnel who work in the country's borders to manage the movement of people in and out and
ensure the security of the borders, seaports, and airports checking potential immigrants for
connections to terrorists or criminal behavior. The research aims to develop an app, designed for
delivering and sharing timely intelligence information with law enforcement officers and first
responders across the country. The app specifications include an interactive interface element
that allows the user to use, modify and edit navigation control tools. The study sample includes 2
senior leaders per department, from the 22 departments of the homeland security officers due to
their sufficient information on the necessary app specification necessary for investigating,
disrupting, and dismantling terrorists' transnational and other criminal investigations. The study

will employ both parametric and non-parametric statistical tests to evaluate the data collected
from app users.
The app users include homeland security officers which include law enforcement officers, first
responders, and federal personnel. The officers work in the country's borders to manage the
movement of people in and out of the countryâ€™s homeland security officers help to secure the
borders, seaports, and airports checking potential immigrants for connections to terrorist or
criminal behavior. The research aims to develop an app, designed for delivering and sharing
timely intelligence information with law enforcement officers and first responders across the
country. The app must allow easy and faster access to information and must be secure for any
device. It should have a feature that permits real-time collaboration between the partners and
offer key technologies for protecting the citizens from adversarial threats facilitating coordinated
responses and helping law enforcement officer to secure the country's borders.
The app specification includes an interactive interface element that allows the user to use,
modify and edit. For instance, the navigation controls such as the links and buttons and editable
content. This interactive element includes keyboard access and labels for assistive technologies.
Other elements are non-test interface elements such as images and the text tendered such as
graphs, charts, images audio and video files, and animations. (3) the app should permit the use of
colors for conveying meaningful information and provides alternative means for users who
cannot distinguish the different colors. Another important component is the flashing elements
that flicker and blink repetitively.
The study sample includes 2 senior leaders per department, from the 22 departments of
homeland security officers. The senior executives have sufficient information on the necessary
app specification necessary for investigating, disrupting, and dismantling terrorists' transnational
and other criminal investigation that seeks to or threatens to exploit the customs and immigration
laws. The research will employ the use of interviews for the data collection process. (1) an
interview helps a researcher to explain, understand and explore the research subjectâ€™s
experiences and opinions and collect in-depth information.
The interview will include questions surrounding the challenges experienced by the security
officers in checking potential immigrants for connections to terrorist or criminal behaviors. The
limitation of the present apps, and the recommendation for future apps. The users need an app
that will improve their convenience by proving a new tool for accessing information quickly and
easily and securely from any device. In most instances, field security officers are in an
operational environment and require easy and secure access to intelligence updates, reports, and
relevant breaking information. This is in line with the goal of the research w will be to provide a
user-friendly application that meets the customer's needs.
Two applicable tests for evaluating the data collected from users are the parametric and the non-
parametric statistical tests. Parametric tests make specific assumptions about the collected data
while the non-parametric do not make any assumptions. The two tests assist in making
inferences about the collected data from the sample population (2). The parametric test permits
the researcher in making generalizations from the sample and does not need interval data to be
transformed into rank data. Equally this statistical test provides real information.

In conclusion, the purpose of research is to outline the app specification required by the
homeland security officers to guide in the process of developing the app. the app needs to have
interactive interface elements that permit the users in delivering and sharing timely intelligence
information with the law enforcement officers checking potential immigrants for connection to
criminal behavior. Both parametric and non-parametric statistical tests are used for evaluating
the data collected during the interview.
Sources
1. Jain, N. (2021). Survey versus interviews: Comparing data collection tools for exploratory
research. The Qualitative Report , 26 (2), 541-554.
2. Kelter, R. (2021). Analysis of type I and II error rates of Bayesian and frequentist parametric
and nonparametric two-sample hypothesis tests under preliminary assessment of normality.
Computational Statistics , 36 (2), 1263-1288.
3. Swalwell, E. M., & Alagood, R. K. (2021). Homeland security twenty years after 9/11:
Addressing evolving threats. Harv. J. on Legis. , 58 , 221.

Week 4 Assignment - Software Development PlanScenario-Your team has be.docx

More Related Content

Similar to Week 4 Assignment - Software Development PlanScenario-Your team has be.docx (20)

More from estefana2345678 (20)

Recently uploaded (20)

Week 4 Assignment - Software Development PlanScenario-Your team has be.docx