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
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.
Keywords: Agile Project Management, Methods, Toyota Way
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.
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.
II. THE TRADITIONAL APPROACH –FEATURES AND FAILURES
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
:
Require ment s Def init ion
Syst em & Sof t ware Design
Implement at ion & Unit Test ing
Int egrat ion & Syst em Test ing
Oper at ion & Maint enance
Disappoint ment & Rej ect ion
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.
III. ESTIMATING UNCERTAINTY
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,
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.
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
Incomplete Requirements 56%
Coding
7% Other
10%
Design
27%
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.
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.
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.
VI. THE UNCERTAINTY OF CERTAINTY
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 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%
Figure 4: System Development Outcomes
* Source: St andish Group, Inc. . (Applicat ion Development T rends • January 1995)
% of Required Features Achieved
Achieved Features.
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
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
:
3. Maximize flow
4. Pull production from customer demand 5. Meet customer requirements
6. Do it right the first time 7. 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. Add nothing but value, eliminate waste 2. Centre on the people who add value
3. 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. Overproduction 2. Inventory
3. Extra Processing Steps 4. Motion
5. Defects 6. Waiting
7.
TransportationThese 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
XI. THE AGILE DEVELOPMENT MANIFESTO Agile Alliance, 2005 [1]
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
1. 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).
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 face-to-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.
