Agile Management and the Toyota Way for
Agile Management and the Toyota Way for Software Project
Roy Morien
Centre for Extended Enterprise and Business Intelligence, Curtin University of Technology, Perth, Australia
e-mail: roymorien@hotmail..com
However, in many respects, the answer has been
available to be seen for some 20 years or more. If
we seek the solution in manufacturing, then The
Toyota Way of management, and the Lean
Manufacturing practices of The Toyota Production
System, as applied to software development,
provides the inspiration. The Toyota Company is
currently the world’s most successful and wealthy
motor vehicle manufacturing company, whose
manufacturing and product development methods
are now widely studied.
Development methods, which can be described
generally as system evolution, have been written
about, proposed, discussed and researched since the
1970’s, in fact. There is significant research
evidence to support the proposition that these
methods are much more likely to produce
successful systems development outcomes than the
traditional structured development approach.
Abstract: This paper will discuss these various
statements, illustrating the dismal record of
failure, the underlying causes of these failures,
and the history of research into alternative
development approaches, now generally termed
‘Agile Development Methods’.
It is also proposed that Agile Development
requires Agile Management, and I will discuss
this concept and practice of Agile Management.
This
approach
to
managing
software
development projects can be seen to have roots
in the Lean Manufacturing thinking and
practice, derived in many respects from what is
known as The Toyota Manufacturing Process.
This foundation in a demonstrably successful
and long-standing product development and
manufacturing process gives strength and
credibility to the concept and practice of Agile
Development, and Agile Project Management.
II. THE TRADITIONAL APPROACH – FEATURES
AND FAILURES
Keywords: Agile Project Management, Methods,
Toyota Way
What is being termed ‘The Traditional Approach’
are the Structured Development Life Cycle
approaches that were developed and published in
the late 1970’s [3, 4, 13]. Given the linearly phased
approach to development, these approaches have
been generally termed the Waterfall Approach. The
Waterfall Model can be illustrated in the following
manner:
I. INTRODUCTION
The record of failure of information systems
development over the last 20 years is well recorded.
Literally billions of dollars have been wasted on
development projects that failed. The Information
Systems and Technology industry (IST) has, in the
main, failed to find a solution to this situation.
Require ment s
Definit ion
Syst em & Soft ware
Design
Implement at ion &
Unit Test ing
Int egrat ion &
Syst em Test ing
Operat ion &
Maint enance
Disappoint ment
& Rej ect ion
Figure 1: The Traditional Waterfall Model
There are a number of characteristics and aspects
of this model that are important to consider. First, in
this development approach, the major emphasis is on
‘up front’ requirements determination. The entire
project activity from the beginning to the end is
almost entirely predicated on getting the requirements
fully ascertained and stated, and locked in, at the start
of the project, before further activity takes place.
The second important characteristic is the linear
nature of the phases. The ‘pure’ Waterfall Model
goes through each phase in turn, only proceeding to
the next phase after careful consideration of the
outcome of the phase, and after a ‘sign off’ of the
outcomes of that phase has been done. Over time,
some changes were made to this model to allow
limited feedback.
You might notice that final phase; Disappointment
and Rejection. I have put that in the model,
somewhat whimsically. I doubt if the original
author’s of these development methods would
approve, but, long and bitter experience over a quarter
of a century seems to indicate that this phase is almost
inevitable.
There are a variety of reasons for this, and the first
and foremost is the problem of requirements
determination.
The traditional project management model,
appropriate to this development method, is focused on
locking the scope of the project. The other project
dimensions, of Time, Budget and Resource Allocation
are usually considered to be negotiable and able to
vary.
delivering on time, and remaining within budget. The
baseline time and budget that are being used as the
basis of this definition of project success are the
outcomes of the estimating activity, which has an
uncertainty factor of anything up to 200%.
IV. REQUIREMENTS DETERMINATION
No one in a business situation, contracting for the
provision of goods and services, will be rash enough
to hand the supplier a blank cheque with the
instruction ‘spend it’, and fail also to provide specific
instructions and understandings about the product
being purchased, its fitness for use, and conformity to
specification. Due diligence must always prevail.
There has never been any argument that the
determination of requirements is an absolute essential
activity. The question that must be asked, however, is
‘When is it appropriate to undertake this activity?’
A study of the factors that have lead to project
failure has shown, probably unsurprisingly, that the
major cause of system failure is failure to properly
determine requirements. This is illustrated in Figure 2.
Coding
7%
Other
10%
Design
27%
III. ESTIMATING UNCERTAINTY
Incomplete Requirements
When the scope of the project is defined first, up
front, and the scope of the project is seen to be locked
in, the project manager is forced to provide estimates
of cost and time, and the level of effort necessary to
transform those requirements into a working system.
Estimates are prone to uncertainty. The estimating
activity in software development projects has been
described as ‘the weakest link in the chain’ [9].
Historically the requirement to control projects to
accord with estimates has been seen as a substantial
problem.
For example, Rakos [8] states ‘It is
remarkable that in our …computer industry one third to
one half of its effort and cost is out of control’. Putnam
also states ‘…two hundred to three hundred percent
cost overruns and up to one hundred percent time
slippages have been common, frequent, almost
universal’.
These problems do not seem to have been solved in
the intervening 20 or so years.
Despite this
acknowledged weakness, and these historically
recorded problems, the outcomes of the estimating
activity are of such importance that one author has
described the situation as ‘…more projects are doomed
by poor cost and schedule estimates than by technical,
political or team problems’ (Roetzheim, 2000).
Nonetheless, success (as in the successful completion
of such projects) is defined as meeting requirements,
56%
Figure 2: Sources of Error in Software Projects
The Waterfall Model of development predicates that
this is done in the first phase. The assertion seems to
be ‘tell us your requirements in their entirety, fully
detailed, without contradiction or error, once and for all
at the start of the project, and we will proceed to deliver
a system according to those requirements’.
There are many practical problems associated with
this assumption that the requirements can be properly
and correctly ascertained in this manner. First, it is
frequently the case that the system client is unable to
provide that information, in the detail and to the level
of completeness and accuracy required. Second, even
if this could be the case, the longer the timeframe
between the requirements determination activity and
the completion of the project, the more likely it is that
these requirements will have become invalid, due to
changes in the business, changes in the method of
business operations by the potential user, changes in
the target user, change of the client, and so forth. The
traditional approach does not easily accept changes
over time, and the outcome is frequently that the gap
between contemporary requirements at the time of
delivery of the system, and the requirements that the
system features are based, is at maximum variance, and
that gap is large.
V. SYSTEM DEVELOPMENT SUCCESS
The record of system development success, or, more
to the point, system development failure, is appalling.
As is illustrated in Figure 3, only 61% of required
features, on average, were achieved.
AAcchhie
ievveeddFea
Feattu
urrees...
oonnly
s...
ly6611%
%!!
% of Systems Achieving
40
35
30
25
20
VI. THE UNCERTAINTY OF CERTAINTY
15
10
5
0
< 25%
25%- 49%
50%- 74%
75%- 99%
100%
% of Required Features Achieved
*
An interesting quote can be taken from one of the
major players in IT education, publishing and
consulting, who said, back in 1991 …’RAD (Rapid
Application Development) has been demonstrated … to
be so superior to traditional development that it seems
irresponsible to continue to develop systems the old
way’
‘It seems astonishing that the majority of IS
organizations are still building systems so painfully
slowly.’[6].
This sentiment is echoed and repeated many times
in the literature, where there is a significant amount of
published research to support the idea that the
traditional approach to systems development, and
project management approach, has failed.
Source: St andish Group, Inc. .
(Applicat ion Development T rends • January 1995)
Figure 3: Features Achieved in Software Projects
This actual percentage on a project basis shows a
variation of between less than 25% of required features
being achieved in about 5% of projects, and only 38%
or so of project achieving between 75% and 99% of
requirements. Only about 7% of projects delivered
100% of the requirements. Another view of this
situation is illustrated in Figure 4. Here we see that the
percentage of systems considered to have been a
success rose from 16% to 28% over the period 1994 to
2000. An achievement, but hardly a triumph! The
percentage of challenged projects decreased from 53%
t0 49%, which really cannot be said to be a significant
decrease.
Indeed, what these figures show is that the record of
systems development success has really not improved
by any great factor in the last 10 years.
There is even little consolation in the statistic that
failed projects decreased from 31% to 23% during that
period, 1994 to 2000.
00
28%
23%
49%
98
26%
28%
46%
96
27%
40%
33%
94
16%
0%
10%
31%
20%
30%
40%
53%
50%
Succeeded
60%
Failed
70%
80%
90%
Challenged
Figure 4: System Development Outcomes
100%
When contracting for the provision of a computer
system, especially software, clients will naturally tend
to do everything they can to reduce future risk and
uncertainty. It is still more usual for organisations to
prefer fixed price contracts for the development of
computer systems, with the price, duration and scope
apparently fixed in an ‘up front’ contract.
Having a contract that specifies such fixed
numbers, the client feels safe, feels that certainty has
been introduced into the equation. Certainty that the
system will cost the specified and agreed amount.
Certainty that the system will be delivered by a
specified and agreed date. Certainty that the features
of the system will be useful, useable and according to
business requirements. There is the further sense of
certainty that the delivered system, perhaps to be
delivered in one or two year’s time, will be
appropriate at that future time.
To achieve this certainty, it is contractually
required and agreed that a complete analysis of
requirements will be performed ‘up front’. After all,
how can there be a successful development project
outcome if all of the requirements are not fully
understood and agreed upon?
With all this certainty in place, there will be no risk
involved. However, just in case all does not go
according to plan, penalties can be inserted into the
contract. After all, how can we really be sure that the
supplier is to be trusted and is able to deliver
according to the scope, price and timeframe
stipulated? Due diligence surely also includes a
healthy scepticism and mistrust of the supplier’s
ability to deliver as contracted, and so the client must
protect themselves against selecting an incompetent
supplier, unwittingly of course. The real competence
of the supplier is probably the only uncertain thing
about all this.
On the other hand, such a ‘fixed features’ contract
provides certainty for the supplier. The contract
provides certainty of scope and features, such that the
supplier knows exactly what it is they are required to
deliver. The supplier is able to budget for the
development, plan resources at the appropriate times
in the fixed development period, know with certainty
when the product is to be delivered, is certain of the
revenue to be earned, and knows that the client can be
held to account in accordance with the contract if they
fail to live up to their side of the bargain. After all,
for whatever reason, clients can really put
unreasonable and unanticipated demands on the
supplier, and the supplier must be contractually
protected against that.
At least, that is the theory of the thing.
The reality is somewhat different, and a lot less
certain. Long experience has shown that software
development costs are very difficult to specify up
front with any certainty, especially on long-running
projects. It has been clearly demonstrated that clients
really cannot state all of their requirements up front,
in full detail, without ambiguity; therefore certainty of
requirements is almost impossible. The bigger the
project, the more people involved in the project, the
longer the timeframe until delivery, all contribute to
one very important and almost overwhelming
realisation – Certainty is a myth and is the most
uncertain part of any project.
Another demonstrable fact is that over the time of
the project, change is inevitable. There are many
reasons for change, and it cannot be avoided. One
way to handle change is to ignore it, which inexorably
leads to disappointment, dissatisfaction and project
failure, when the finished and delivered system is no
longer according to the requirements of the client and
the business.
Some contracts acknowledge the possibility of
changing requirements, and factor in a change process
that allows changes to be asked for, and charged for
additionally. No one feels that this is the dreaded
scope creep, because it provides an orderly and
certain method by which to handle change. But to use
such a change control mechanism is begging the
question about the certainty implied in a fixed price,
fixed scope, fixed time contract.
Any contractual relationship based on this attempt
to state matters in such a way as to ensure certainty of
features, scope and cost (and quality and fitness for
use), is a futile venture, based on erroneous and
inappropriate thinking, and probably more than a little
fear and uncertainty on the part of the contracting
parties as well. Such contracts are in reality just a
basis for trying to sort out the almost inevitable mess
at the end, to justify and support legal action, and are
clearly based on initial lack of trust and cooperation
between supplier and client.
It is also the most risky for all concerned, and also
usually the most costly for the client.
The probability and even inevitability of change is
acknowledged readily by developers, but almost the
entire way of thinking about project management is
based on trying to factor change out, to refuse to
allow change. For example, a quote from an article
from a prominent web site that discusses project
management issues (Phillips, 2005): ‘How do you
manage a client who throws your whole project plan
off because they can't commit to a specification, or
worse — they commit and then keep changing their
minds. … (this author) comes to the rescue with an
article on time management for project managers.
He'll help you get control over project schedules and
maybe even help you how to say ‘no’.
What this project management advice is really
saying is that clients who change their minds and ask
for things to be changed should be denied, because
that disrupts the project plan. Obviously the project
plan is more important than a project outcome of a
working, useful, useable system that meets business
requirements. This sentiment emphasises the aspect
of the traditional development approaches that the
scope is fixed and locked in at the start of the project,
regardless of what events or changes impact on the
real requirements during the project period. Every
‘no’ to a requested change takes the resultant system
one more step away from what the client really wants.
This demonstrates the fundamental difference
between predictive planning and adaptive planning.
What, however, may be worse, is that there is an
implication of wrongdoing and incompetence on the
part of the client if they ‘keep changing their minds’.
What this article implies is that customers frequently,
if not usually, behave in an unacceptable fashion, and
should be denied. This really needs explanation. Is
the client constantly changing their mind about the
same thing, thus we have what is known as ‘design
thrashing’? Or is the client changing their mind once
for each of a number of things? Why is the client
changing their mind? Could it be that the business
requirements have changed? Could it be that the client
now understands their requirements better? One may
even ask why the developer wasn’t bright enough to
discover what was really wanted first time. However,
whatever is read into such statements, it is certainly
the fact that such statements and sentiments are the
foundation for an adversarial approach to
development, and conflict between client and
developer. This leads people to the conclusion that it
is necessary to have strict fixed dimension contracts
that attempt to enforce greater rigour on the
development process, which is exactly what the
experience and research shows is the cause of most
development failures.
VII. AGILE PROJECT MANAGEMENT
The traditional approach to project management that
focuses on up-front requirements determination and
locking in the scope of the project reflect the PMI and
ISO-9000 models for project management. The view
of adherents to the agile project management paradigm
is that these models … PMI and ISO-9000 have created
the worst possible environment for project managers
[2]. These have forced managers to try to achieve
greater accuracy of estimation, which is seen by many
as being a fundamentally vain and flawed task.
Changes to the requirements and scope of the project
are to be avoided, and bear the ignominious title of
‘scope creep’, which is the bane of all project
managers, and is seen to indicate that proper
requirements determination was not carried out.
Agile project management adopts a different view.
This approach accepts that the scope of the project
cannot be realistically ascertained in all and full detail
up front, and may vary as actual requirements change
over the duration of the project. Change is accepted as
an inevitable aspect of the project, and the project
manage must accommodate this.
In an agile development project, the project factors
of Time and Budget can be set before scope is set. In
fact, scope is seen as being substantially variable, and
no detailed scope is attempted to be struck.
Traditionalists may view this as anathema, and may
continue to pursue the object of certainty in estimation
and scope statement.
However, agile project
management pursues the production of high-priority
requirements being delivered into the hands of clients,
on a regular and evolutionary basis, whilst working to a
fixed time for completion, or a fixed budget for
expenditures. In this manner, the most necessary
features of the system are delivered, at all times the
client is aware of what is likely to be delivered by the
project end date, and the project manager is always
aware of the resources still available to him (time and
budget) and the tasks to be completed with those
resources. Decisions are constantly made as to priority
of features to be delivered.
VIII. THE PROJECT MANAGER’S NEW ROLE
Agile Project Management is not about creating a
list of tasks, guaranteed to be complete and accurate,
and then being driven by clearly inaccurate estimates
that predict the total cost, to create a Gantt Chart that
visually and neatly predicts the end date. The continual
maintenance of the Gantt Chart throughout the project
is no longer part of the job. All of this is now obsolete.
[2].
Basically, the Agile Project Manager is to facilitate
and ensure a constant flow of throughput by
maintaining what may be termed a Project Backlog.
This is a term used in the SCRUM Agile Development
Method [10, 11]. According to Schwaber, Scrum is an
agile, lightweight process that can be used to manage
and control software and product development using
iterative, incremental practices. Wrapping existing
engineering
practices,
including
Extreme
Programming and RUP, Scrum generates the benefits
of agile development with the advantages of a simple
implementation.
IX. IN THE SCRUM – SOME FEATURES OF AN AGILE
METHOD
Scrum significantly increases productivity and
reduces time to benefits while facilitating adaptive,
empirical systems development.
The rules and
practices from Scrum - a simple process for managing
complex projects - are few, straightforward, and easy
to learn [11]. A major artefact used in Scrum is the
Project Backlog List. This is a list of all of the tasks
that are currently known about, that have yet to be
completed. Each task is defined in such a way as to be
a discrete statement of a particular requirement,
prioritised against all tasks in the Backlog List, together
with an estimate of time and cost to develop. This
Backlog List is continually updated as change requests
are made, new requirements are discovered, and
completed tasks are delivered. At all times it is
possible for the Project Manager to see the highest
priority tasks, and have those developed and delivered
first. Also, at all times, it is possible for the Project
Manager to compare estimated time and cost to
complete against the stated Completion Date and
project Budget. Where estimated time to complete
exceeds the stated Completion Date, then the lowest
priority tasks will probably not be delivered, or the
Completion Date is moved.
Whilst this may appear to be just another way to
allow delivery schedules to slip, the reality is that the
client is always kept informed of the situation, and may
make decisions about scope and delivery dates on an
informed basis. It means that the highest value features
are delivered, and any tasks not completed are of the
lowest priority. One significant advantage of this latter
point is that the delivered product is ‘lean’, and the
undelivered features are often, if not usually, found to
be unnecessary anyway, and the system can function
quite happily without them. This is a major feature of
the Lean Manufacturing / Lean Software Development
thinking and practice.
X. LEAN DEVELOPMENT – THE TOYOTA WAY OF
THINKING
Lean
production
was
a
manufacturing
methodology developed originally by the Toyota
Motor Company. It is also known as the Toyota
Production System. The goal of lean production is
stated as ‘to get the right things to the right place at
the right time, the first time, while minimizing waste
and being open to change’.
The Toyota Production System was masterminded
by Taiicho Ohno, who is credited with developing the
principles of lean production, discovered that in
addition to eliminating waste, his methodology led to
improved product flow and better quality.
What might easily be seen as the leading text on
The Toyota Way is by Likert [5]. The overall
management philosophy and practice, stated as 14
management principles, is discussed at length in this
book.
Instead of devoting resources to planning what
would be required for future manufacturing, Toyota
focused on reducing system response time so that the
production system was capable of immediately
changing and adapting to market demands. The
principles of lean production enabled the company to
deliver on demand, minimize inventory, maximize the
use of multi-skilled employees, flatten the
management structure and focus resources where they
were needed. Ten rules of lean production were
stated. These were:
1. Eliminate waste
2. Minimize inventory
3.
4.
5.
6.
7.
Maximize flow
Pull production from customer demand
Meet customer requirements
Do it right the first time
Empower workers
8. Design for rapid changeover
9. Partner with suppliers
10. Create a culture of continuous improvement
Techtarget Network, 2005 [12]
This set of ten features has been summarised and condensed into:
The Basic Principles of Lean Development
1.
2.
3.
Add nothing but value, eliminate waste
Centre on the people who add value
Flow value from demand, delay commitment to
inventory
4. Optimise across the organisation
Poppendieck, 2002 [7]
These principles were stated by Engineer Ohno in this manner:
The Seven Wastes of Manufacturing
1.
2.
3.
4.
5.
6.
Overproduction
Inventory
Extra Processing Steps
Motion
Defects
Waiting
7. Transportation
These principles have been applied to software project management in this manner: Poppendieck, 2002 [7]
The Seven Wastes of Software Development
Overproduction
Extra features, unnecessary features, gold plating. Develop
according to JIT requirements statements, develop according to
immediate client requirements.
Inventory
System requirements waiting to be developed, excessive
documentation. Develop code not documentation, deliver frequently,
don’t accumulate code.
Extra Processing Steps
Code directly from user statements, get clarification directly from
clients, implies clients are an integral part of the development team.
Motion
Remove extra lines of communication, have developers together
with clients in close proximity
Defects
Test early and test often. Release nothing until it has been
thoroughly tested. Test-driven development.
Waiting
Don’t make clients wait, deliver frequently, fast iteration cycles
Transportation
Deliver work directly to the client, avoid hand-offs between
participants (eg: analyst to programmer to tester to implementer to
customer)
XI. THE AGILE DEVELOPMENT MANIFESTO
Agile Alliance, 2005 [1]
We follow these principles:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer's
competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the
shorter timescale.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust
them to get the job done.
The most efficient and effective method of conveying information to and within a development team is faceto-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers and users should be able to
maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity--the art of maximizing the amount of work not done--is essential.
The best architectures, requirements and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour
accordingly.
It is the fundamental task of the Agile Project
Manager to observe these canons, and implement them.
If the Toyota Manufacturing Company can arise from
the ashes of being a small manufacturer of knitting
looms, to become the world’s best and most efficient
manufacturer of quality motors vehicles, by embedding
this agile management, lean manufacturing concepts in
the business, then it seems relevant and beneficial for
software project managers to take heed and implement.
XII. FURTHER RESEARCH
It is my view that the fundamentals of agile
software development, agile project management, and
evolutionary development have been proven and
demonstrated to be highly successful. However, a
concern is that these methods are still not prevalent
and preferred. Why is this? I will undertake an
extensive research project to analyse the curriculum
content, educational and academic aspects of the
teaching of these approaches and philosophies to
potential ITS professionals. This will be done in
Australia, Singapore and China. I will also convene
an Agile Development SIG in Perth, Singapore and
Hong Kong. The facts are stated, it should only
remain to educate.
XIII. CONCLUSION
In brief, the traditional approaches to system
development have proven unsuccessful too often. The
agile development approaches, that emphasise lean,
change-oriented development, have been demonstrated
to be effective. Management of projects undertaken in
this manner i.e.: by the Agile Manager, demands a new
way of managing with greater emphasis on the
facilitation of product flow; development and delivery
of working features continuously.
XIV. REFERENCES
Agile Alliance (2005) http://agilemanifesto.org/ , accessed
19th May, 2005
2.
Anderson, D.J. (2003) Agile Management for Software
Engineering, Prentice-Hall.
3.
De Marco, T. (1979), Structured Systems Analysis and System
Specification. New York: Yourdon
4.
Gane C. and Sarson, T. (1979), Structured Systems Analysis:
Tools and Techniques, 1st Edition, Prentice-Hall
5.
Liker, Jeffrey K., 2004, The Toyota Way, McGraw-Hill.
6.
Martin, J. (1991), Rapid Application Development,
MacMillan Publishing.
7.
Poppendieck, M. (2002), Principles of Lean Thinking,
http://www.poppendieck.com/papers/LeanThinking.pdf,
accessed May 19th, 2005
8.
Putnam, Lawrence (1980), Software Cost Estimating & Life
Cycle Control: Getting the Software Numbers, IEEE
9.
Rakos, John J. (1996), Software Project Management for
Small to Medium Sized Projects, publisher unknown.
10. Schwaber, K. & Beedle M. (2001) Agile Development with
Scrum, Prentice-Hall, 1st Ed.
11. SCRUM Home Page, 2005, http://www.controlchaos.com/,
accessed May 19th, 2005.
12. (Techtarget
Network,
2005)
http://searchcio.techtarget.com/sDefinition/0,,sid19_gci81051
9,00.html
13. Yourdon, Edward and Constantine L.L. (1979), Structured
Design : Fundamentals of a Discipline of Computer Program
and System Design, Prentice-Hall, Englewood Cliffs, N.J.
(1979).
1.
Roy Morien
Centre for Extended Enterprise and Business Intelligence, Curtin University of Technology, Perth, Australia
e-mail: roymorien@hotmail..com
However, in many respects, the answer has been
available to be seen for some 20 years or more. If
we seek the solution in manufacturing, then The
Toyota Way of management, and the Lean
Manufacturing practices of The Toyota Production
System, as applied to software development,
provides the inspiration. The Toyota Company is
currently the world’s most successful and wealthy
motor vehicle manufacturing company, whose
manufacturing and product development methods
are now widely studied.
Development methods, which can be described
generally as system evolution, have been written
about, proposed, discussed and researched since the
1970’s, in fact. There is significant research
evidence to support the proposition that these
methods are much more likely to produce
successful systems development outcomes than the
traditional structured development approach.
Abstract: This paper will discuss these various
statements, illustrating the dismal record of
failure, the underlying causes of these failures,
and the history of research into alternative
development approaches, now generally termed
‘Agile Development Methods’.
It is also proposed that Agile Development
requires Agile Management, and I will discuss
this concept and practice of Agile Management.
This
approach
to
managing
software
development projects can be seen to have roots
in the Lean Manufacturing thinking and
practice, derived in many respects from what is
known as The Toyota Manufacturing Process.
This foundation in a demonstrably successful
and long-standing product development and
manufacturing process gives strength and
credibility to the concept and practice of Agile
Development, and Agile Project Management.
II. THE TRADITIONAL APPROACH – FEATURES
AND FAILURES
Keywords: Agile Project Management, Methods,
Toyota Way
What is being termed ‘The Traditional Approach’
are the Structured Development Life Cycle
approaches that were developed and published in
the late 1970’s [3, 4, 13]. Given the linearly phased
approach to development, these approaches have
been generally termed the Waterfall Approach. The
Waterfall Model can be illustrated in the following
manner:
I. INTRODUCTION
The record of failure of information systems
development over the last 20 years is well recorded.
Literally billions of dollars have been wasted on
development projects that failed. The Information
Systems and Technology industry (IST) has, in the
main, failed to find a solution to this situation.
Require ment s
Definit ion
Syst em & Soft ware
Design
Implement at ion &
Unit Test ing
Int egrat ion &
Syst em Test ing
Operat ion &
Maint enance
Disappoint ment
& Rej ect ion
Figure 1: The Traditional Waterfall Model
There are a number of characteristics and aspects
of this model that are important to consider. First, in
this development approach, the major emphasis is on
‘up front’ requirements determination. The entire
project activity from the beginning to the end is
almost entirely predicated on getting the requirements
fully ascertained and stated, and locked in, at the start
of the project, before further activity takes place.
The second important characteristic is the linear
nature of the phases. The ‘pure’ Waterfall Model
goes through each phase in turn, only proceeding to
the next phase after careful consideration of the
outcome of the phase, and after a ‘sign off’ of the
outcomes of that phase has been done. Over time,
some changes were made to this model to allow
limited feedback.
You might notice that final phase; Disappointment
and Rejection. I have put that in the model,
somewhat whimsically. I doubt if the original
author’s of these development methods would
approve, but, long and bitter experience over a quarter
of a century seems to indicate that this phase is almost
inevitable.
There are a variety of reasons for this, and the first
and foremost is the problem of requirements
determination.
The traditional project management model,
appropriate to this development method, is focused on
locking the scope of the project. The other project
dimensions, of Time, Budget and Resource Allocation
are usually considered to be negotiable and able to
vary.
delivering on time, and remaining within budget. The
baseline time and budget that are being used as the
basis of this definition of project success are the
outcomes of the estimating activity, which has an
uncertainty factor of anything up to 200%.
IV. REQUIREMENTS DETERMINATION
No one in a business situation, contracting for the
provision of goods and services, will be rash enough
to hand the supplier a blank cheque with the
instruction ‘spend it’, and fail also to provide specific
instructions and understandings about the product
being purchased, its fitness for use, and conformity to
specification. Due diligence must always prevail.
There has never been any argument that the
determination of requirements is an absolute essential
activity. The question that must be asked, however, is
‘When is it appropriate to undertake this activity?’
A study of the factors that have lead to project
failure has shown, probably unsurprisingly, that the
major cause of system failure is failure to properly
determine requirements. This is illustrated in Figure 2.
Coding
7%
Other
10%
Design
27%
III. ESTIMATING UNCERTAINTY
Incomplete Requirements
When the scope of the project is defined first, up
front, and the scope of the project is seen to be locked
in, the project manager is forced to provide estimates
of cost and time, and the level of effort necessary to
transform those requirements into a working system.
Estimates are prone to uncertainty. The estimating
activity in software development projects has been
described as ‘the weakest link in the chain’ [9].
Historically the requirement to control projects to
accord with estimates has been seen as a substantial
problem.
For example, Rakos [8] states ‘It is
remarkable that in our …computer industry one third to
one half of its effort and cost is out of control’. Putnam
also states ‘…two hundred to three hundred percent
cost overruns and up to one hundred percent time
slippages have been common, frequent, almost
universal’.
These problems do not seem to have been solved in
the intervening 20 or so years.
Despite this
acknowledged weakness, and these historically
recorded problems, the outcomes of the estimating
activity are of such importance that one author has
described the situation as ‘…more projects are doomed
by poor cost and schedule estimates than by technical,
political or team problems’ (Roetzheim, 2000).
Nonetheless, success (as in the successful completion
of such projects) is defined as meeting requirements,
56%
Figure 2: Sources of Error in Software Projects
The Waterfall Model of development predicates that
this is done in the first phase. The assertion seems to
be ‘tell us your requirements in their entirety, fully
detailed, without contradiction or error, once and for all
at the start of the project, and we will proceed to deliver
a system according to those requirements’.
There are many practical problems associated with
this assumption that the requirements can be properly
and correctly ascertained in this manner. First, it is
frequently the case that the system client is unable to
provide that information, in the detail and to the level
of completeness and accuracy required. Second, even
if this could be the case, the longer the timeframe
between the requirements determination activity and
the completion of the project, the more likely it is that
these requirements will have become invalid, due to
changes in the business, changes in the method of
business operations by the potential user, changes in
the target user, change of the client, and so forth. The
traditional approach does not easily accept changes
over time, and the outcome is frequently that the gap
between contemporary requirements at the time of
delivery of the system, and the requirements that the
system features are based, is at maximum variance, and
that gap is large.
V. SYSTEM DEVELOPMENT SUCCESS
The record of system development success, or, more
to the point, system development failure, is appalling.
As is illustrated in Figure 3, only 61% of required
features, on average, were achieved.
AAcchhie
ievveeddFea
Feattu
urrees...
oonnly
s...
ly6611%
%!!
% of Systems Achieving
40
35
30
25
20
VI. THE UNCERTAINTY OF CERTAINTY
15
10
5
0
< 25%
25%- 49%
50%- 74%
75%- 99%
100%
% of Required Features Achieved
*
An interesting quote can be taken from one of the
major players in IT education, publishing and
consulting, who said, back in 1991 …’RAD (Rapid
Application Development) has been demonstrated … to
be so superior to traditional development that it seems
irresponsible to continue to develop systems the old
way’
‘It seems astonishing that the majority of IS
organizations are still building systems so painfully
slowly.’[6].
This sentiment is echoed and repeated many times
in the literature, where there is a significant amount of
published research to support the idea that the
traditional approach to systems development, and
project management approach, has failed.
Source: St andish Group, Inc. .
(Applicat ion Development T rends • January 1995)
Figure 3: Features Achieved in Software Projects
This actual percentage on a project basis shows a
variation of between less than 25% of required features
being achieved in about 5% of projects, and only 38%
or so of project achieving between 75% and 99% of
requirements. Only about 7% of projects delivered
100% of the requirements. Another view of this
situation is illustrated in Figure 4. Here we see that the
percentage of systems considered to have been a
success rose from 16% to 28% over the period 1994 to
2000. An achievement, but hardly a triumph! The
percentage of challenged projects decreased from 53%
t0 49%, which really cannot be said to be a significant
decrease.
Indeed, what these figures show is that the record of
systems development success has really not improved
by any great factor in the last 10 years.
There is even little consolation in the statistic that
failed projects decreased from 31% to 23% during that
period, 1994 to 2000.
00
28%
23%
49%
98
26%
28%
46%
96
27%
40%
33%
94
16%
0%
10%
31%
20%
30%
40%
53%
50%
Succeeded
60%
Failed
70%
80%
90%
Challenged
Figure 4: System Development Outcomes
100%
When contracting for the provision of a computer
system, especially software, clients will naturally tend
to do everything they can to reduce future risk and
uncertainty. It is still more usual for organisations to
prefer fixed price contracts for the development of
computer systems, with the price, duration and scope
apparently fixed in an ‘up front’ contract.
Having a contract that specifies such fixed
numbers, the client feels safe, feels that certainty has
been introduced into the equation. Certainty that the
system will cost the specified and agreed amount.
Certainty that the system will be delivered by a
specified and agreed date. Certainty that the features
of the system will be useful, useable and according to
business requirements. There is the further sense of
certainty that the delivered system, perhaps to be
delivered in one or two year’s time, will be
appropriate at that future time.
To achieve this certainty, it is contractually
required and agreed that a complete analysis of
requirements will be performed ‘up front’. After all,
how can there be a successful development project
outcome if all of the requirements are not fully
understood and agreed upon?
With all this certainty in place, there will be no risk
involved. However, just in case all does not go
according to plan, penalties can be inserted into the
contract. After all, how can we really be sure that the
supplier is to be trusted and is able to deliver
according to the scope, price and timeframe
stipulated? Due diligence surely also includes a
healthy scepticism and mistrust of the supplier’s
ability to deliver as contracted, and so the client must
protect themselves against selecting an incompetent
supplier, unwittingly of course. The real competence
of the supplier is probably the only uncertain thing
about all this.
On the other hand, such a ‘fixed features’ contract
provides certainty for the supplier. The contract
provides certainty of scope and features, such that the
supplier knows exactly what it is they are required to
deliver. The supplier is able to budget for the
development, plan resources at the appropriate times
in the fixed development period, know with certainty
when the product is to be delivered, is certain of the
revenue to be earned, and knows that the client can be
held to account in accordance with the contract if they
fail to live up to their side of the bargain. After all,
for whatever reason, clients can really put
unreasonable and unanticipated demands on the
supplier, and the supplier must be contractually
protected against that.
At least, that is the theory of the thing.
The reality is somewhat different, and a lot less
certain. Long experience has shown that software
development costs are very difficult to specify up
front with any certainty, especially on long-running
projects. It has been clearly demonstrated that clients
really cannot state all of their requirements up front,
in full detail, without ambiguity; therefore certainty of
requirements is almost impossible. The bigger the
project, the more people involved in the project, the
longer the timeframe until delivery, all contribute to
one very important and almost overwhelming
realisation – Certainty is a myth and is the most
uncertain part of any project.
Another demonstrable fact is that over the time of
the project, change is inevitable. There are many
reasons for change, and it cannot be avoided. One
way to handle change is to ignore it, which inexorably
leads to disappointment, dissatisfaction and project
failure, when the finished and delivered system is no
longer according to the requirements of the client and
the business.
Some contracts acknowledge the possibility of
changing requirements, and factor in a change process
that allows changes to be asked for, and charged for
additionally. No one feels that this is the dreaded
scope creep, because it provides an orderly and
certain method by which to handle change. But to use
such a change control mechanism is begging the
question about the certainty implied in a fixed price,
fixed scope, fixed time contract.
Any contractual relationship based on this attempt
to state matters in such a way as to ensure certainty of
features, scope and cost (and quality and fitness for
use), is a futile venture, based on erroneous and
inappropriate thinking, and probably more than a little
fear and uncertainty on the part of the contracting
parties as well. Such contracts are in reality just a
basis for trying to sort out the almost inevitable mess
at the end, to justify and support legal action, and are
clearly based on initial lack of trust and cooperation
between supplier and client.
It is also the most risky for all concerned, and also
usually the most costly for the client.
The probability and even inevitability of change is
acknowledged readily by developers, but almost the
entire way of thinking about project management is
based on trying to factor change out, to refuse to
allow change. For example, a quote from an article
from a prominent web site that discusses project
management issues (Phillips, 2005): ‘How do you
manage a client who throws your whole project plan
off because they can't commit to a specification, or
worse — they commit and then keep changing their
minds. … (this author) comes to the rescue with an
article on time management for project managers.
He'll help you get control over project schedules and
maybe even help you how to say ‘no’.
What this project management advice is really
saying is that clients who change their minds and ask
for things to be changed should be denied, because
that disrupts the project plan. Obviously the project
plan is more important than a project outcome of a
working, useful, useable system that meets business
requirements. This sentiment emphasises the aspect
of the traditional development approaches that the
scope is fixed and locked in at the start of the project,
regardless of what events or changes impact on the
real requirements during the project period. Every
‘no’ to a requested change takes the resultant system
one more step away from what the client really wants.
This demonstrates the fundamental difference
between predictive planning and adaptive planning.
What, however, may be worse, is that there is an
implication of wrongdoing and incompetence on the
part of the client if they ‘keep changing their minds’.
What this article implies is that customers frequently,
if not usually, behave in an unacceptable fashion, and
should be denied. This really needs explanation. Is
the client constantly changing their mind about the
same thing, thus we have what is known as ‘design
thrashing’? Or is the client changing their mind once
for each of a number of things? Why is the client
changing their mind? Could it be that the business
requirements have changed? Could it be that the client
now understands their requirements better? One may
even ask why the developer wasn’t bright enough to
discover what was really wanted first time. However,
whatever is read into such statements, it is certainly
the fact that such statements and sentiments are the
foundation for an adversarial approach to
development, and conflict between client and
developer. This leads people to the conclusion that it
is necessary to have strict fixed dimension contracts
that attempt to enforce greater rigour on the
development process, which is exactly what the
experience and research shows is the cause of most
development failures.
VII. AGILE PROJECT MANAGEMENT
The traditional approach to project management that
focuses on up-front requirements determination and
locking in the scope of the project reflect the PMI and
ISO-9000 models for project management. The view
of adherents to the agile project management paradigm
is that these models … PMI and ISO-9000 have created
the worst possible environment for project managers
[2]. These have forced managers to try to achieve
greater accuracy of estimation, which is seen by many
as being a fundamentally vain and flawed task.
Changes to the requirements and scope of the project
are to be avoided, and bear the ignominious title of
‘scope creep’, which is the bane of all project
managers, and is seen to indicate that proper
requirements determination was not carried out.
Agile project management adopts a different view.
This approach accepts that the scope of the project
cannot be realistically ascertained in all and full detail
up front, and may vary as actual requirements change
over the duration of the project. Change is accepted as
an inevitable aspect of the project, and the project
manage must accommodate this.
In an agile development project, the project factors
of Time and Budget can be set before scope is set. In
fact, scope is seen as being substantially variable, and
no detailed scope is attempted to be struck.
Traditionalists may view this as anathema, and may
continue to pursue the object of certainty in estimation
and scope statement.
However, agile project
management pursues the production of high-priority
requirements being delivered into the hands of clients,
on a regular and evolutionary basis, whilst working to a
fixed time for completion, or a fixed budget for
expenditures. In this manner, the most necessary
features of the system are delivered, at all times the
client is aware of what is likely to be delivered by the
project end date, and the project manager is always
aware of the resources still available to him (time and
budget) and the tasks to be completed with those
resources. Decisions are constantly made as to priority
of features to be delivered.
VIII. THE PROJECT MANAGER’S NEW ROLE
Agile Project Management is not about creating a
list of tasks, guaranteed to be complete and accurate,
and then being driven by clearly inaccurate estimates
that predict the total cost, to create a Gantt Chart that
visually and neatly predicts the end date. The continual
maintenance of the Gantt Chart throughout the project
is no longer part of the job. All of this is now obsolete.
[2].
Basically, the Agile Project Manager is to facilitate
and ensure a constant flow of throughput by
maintaining what may be termed a Project Backlog.
This is a term used in the SCRUM Agile Development
Method [10, 11]. According to Schwaber, Scrum is an
agile, lightweight process that can be used to manage
and control software and product development using
iterative, incremental practices. Wrapping existing
engineering
practices,
including
Extreme
Programming and RUP, Scrum generates the benefits
of agile development with the advantages of a simple
implementation.
IX. IN THE SCRUM – SOME FEATURES OF AN AGILE
METHOD
Scrum significantly increases productivity and
reduces time to benefits while facilitating adaptive,
empirical systems development.
The rules and
practices from Scrum - a simple process for managing
complex projects - are few, straightforward, and easy
to learn [11]. A major artefact used in Scrum is the
Project Backlog List. This is a list of all of the tasks
that are currently known about, that have yet to be
completed. Each task is defined in such a way as to be
a discrete statement of a particular requirement,
prioritised against all tasks in the Backlog List, together
with an estimate of time and cost to develop. This
Backlog List is continually updated as change requests
are made, new requirements are discovered, and
completed tasks are delivered. At all times it is
possible for the Project Manager to see the highest
priority tasks, and have those developed and delivered
first. Also, at all times, it is possible for the Project
Manager to compare estimated time and cost to
complete against the stated Completion Date and
project Budget. Where estimated time to complete
exceeds the stated Completion Date, then the lowest
priority tasks will probably not be delivered, or the
Completion Date is moved.
Whilst this may appear to be just another way to
allow delivery schedules to slip, the reality is that the
client is always kept informed of the situation, and may
make decisions about scope and delivery dates on an
informed basis. It means that the highest value features
are delivered, and any tasks not completed are of the
lowest priority. One significant advantage of this latter
point is that the delivered product is ‘lean’, and the
undelivered features are often, if not usually, found to
be unnecessary anyway, and the system can function
quite happily without them. This is a major feature of
the Lean Manufacturing / Lean Software Development
thinking and practice.
X. LEAN DEVELOPMENT – THE TOYOTA WAY OF
THINKING
Lean
production
was
a
manufacturing
methodology developed originally by the Toyota
Motor Company. It is also known as the Toyota
Production System. The goal of lean production is
stated as ‘to get the right things to the right place at
the right time, the first time, while minimizing waste
and being open to change’.
The Toyota Production System was masterminded
by Taiicho Ohno, who is credited with developing the
principles of lean production, discovered that in
addition to eliminating waste, his methodology led to
improved product flow and better quality.
What might easily be seen as the leading text on
The Toyota Way is by Likert [5]. The overall
management philosophy and practice, stated as 14
management principles, is discussed at length in this
book.
Instead of devoting resources to planning what
would be required for future manufacturing, Toyota
focused on reducing system response time so that the
production system was capable of immediately
changing and adapting to market demands. The
principles of lean production enabled the company to
deliver on demand, minimize inventory, maximize the
use of multi-skilled employees, flatten the
management structure and focus resources where they
were needed. Ten rules of lean production were
stated. These were:
1. Eliminate waste
2. Minimize inventory
3.
4.
5.
6.
7.
Maximize flow
Pull production from customer demand
Meet customer requirements
Do it right the first time
Empower workers
8. Design for rapid changeover
9. Partner with suppliers
10. Create a culture of continuous improvement
Techtarget Network, 2005 [12]
This set of ten features has been summarised and condensed into:
The Basic Principles of Lean Development
1.
2.
3.
Add nothing but value, eliminate waste
Centre on the people who add value
Flow value from demand, delay commitment to
inventory
4. Optimise across the organisation
Poppendieck, 2002 [7]
These principles were stated by Engineer Ohno in this manner:
The Seven Wastes of Manufacturing
1.
2.
3.
4.
5.
6.
Overproduction
Inventory
Extra Processing Steps
Motion
Defects
Waiting
7. Transportation
These principles have been applied to software project management in this manner: Poppendieck, 2002 [7]
The Seven Wastes of Software Development
Overproduction
Extra features, unnecessary features, gold plating. Develop
according to JIT requirements statements, develop according to
immediate client requirements.
Inventory
System requirements waiting to be developed, excessive
documentation. Develop code not documentation, deliver frequently,
don’t accumulate code.
Extra Processing Steps
Code directly from user statements, get clarification directly from
clients, implies clients are an integral part of the development team.
Motion
Remove extra lines of communication, have developers together
with clients in close proximity
Defects
Test early and test often. Release nothing until it has been
thoroughly tested. Test-driven development.
Waiting
Don’t make clients wait, deliver frequently, fast iteration cycles
Transportation
Deliver work directly to the client, avoid hand-offs between
participants (eg: analyst to programmer to tester to implementer to
customer)
XI. THE AGILE DEVELOPMENT MANIFESTO
Agile Alliance, 2005 [1]
We follow these principles:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer's
competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the
shorter timescale.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust
them to get the job done.
The most efficient and effective method of conveying information to and within a development team is faceto-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers and users should be able to
maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity--the art of maximizing the amount of work not done--is essential.
The best architectures, requirements and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour
accordingly.
It is the fundamental task of the Agile Project
Manager to observe these canons, and implement them.
If the Toyota Manufacturing Company can arise from
the ashes of being a small manufacturer of knitting
looms, to become the world’s best and most efficient
manufacturer of quality motors vehicles, by embedding
this agile management, lean manufacturing concepts in
the business, then it seems relevant and beneficial for
software project managers to take heed and implement.
XII. FURTHER RESEARCH
It is my view that the fundamentals of agile
software development, agile project management, and
evolutionary development have been proven and
demonstrated to be highly successful. However, a
concern is that these methods are still not prevalent
and preferred. Why is this? I will undertake an
extensive research project to analyse the curriculum
content, educational and academic aspects of the
teaching of these approaches and philosophies to
potential ITS professionals. This will be done in
Australia, Singapore and China. I will also convene
an Agile Development SIG in Perth, Singapore and
Hong Kong. The facts are stated, it should only
remain to educate.
XIII. CONCLUSION
In brief, the traditional approaches to system
development have proven unsuccessful too often. The
agile development approaches, that emphasise lean,
change-oriented development, have been demonstrated
to be effective. Management of projects undertaken in
this manner i.e.: by the Agile Manager, demands a new
way of managing with greater emphasis on the
facilitation of product flow; development and delivery
of working features continuously.
XIV. REFERENCES
Agile Alliance (2005) http://agilemanifesto.org/ , accessed
19th May, 2005
2.
Anderson, D.J. (2003) Agile Management for Software
Engineering, Prentice-Hall.
3.
De Marco, T. (1979), Structured Systems Analysis and System
Specification. New York: Yourdon
4.
Gane C. and Sarson, T. (1979), Structured Systems Analysis:
Tools and Techniques, 1st Edition, Prentice-Hall
5.
Liker, Jeffrey K., 2004, The Toyota Way, McGraw-Hill.
6.
Martin, J. (1991), Rapid Application Development,
MacMillan Publishing.
7.
Poppendieck, M. (2002), Principles of Lean Thinking,
http://www.poppendieck.com/papers/LeanThinking.pdf,
accessed May 19th, 2005
8.
Putnam, Lawrence (1980), Software Cost Estimating & Life
Cycle Control: Getting the Software Numbers, IEEE
9.
Rakos, John J. (1996), Software Project Management for
Small to Medium Sized Projects, publisher unknown.
10. Schwaber, K. & Beedle M. (2001) Agile Development with
Scrum, Prentice-Hall, 1st Ed.
11. SCRUM Home Page, 2005, http://www.controlchaos.com/,
accessed May 19th, 2005.
12. (Techtarget
Network,
2005)
http://searchcio.techtarget.com/sDefinition/0,,sid19_gci81051
9,00.html
13. Yourdon, Edward and Constantine L.L. (1979), Structured
Design : Fundamentals of a Discipline of Computer Program
and System Design, Prentice-Hall, Englewood Cliffs, N.J.
(1979).
1.