Save £12 Million every year > Save £3 Million every quarter   
The Big Agile Toolkit: no Dogma, no Bias, no Accreditation, no Exams & no Fees   
 Introduction to Agile  Introduction to Agile   Empowerment versus Control   Empowerment versus Control

Introduction   »   Start   »   Contrast to Waterfall

The waterfall model is a rigid and doctrinaire method.

Let us look at it in a bit more detail.

It begins, as does all change, with a change request within the business or generated by the business to alter some process or system. This change will offer some benefits and involve some measure of effort. This is agreed & documented in one form or another and will traditionally be written up in a business case or cost benefit analysis.

In many organisations agile projects undergo this form of early change evaluation but it must be said in other agile approaches there is very much less change rigour, even than this. The sequences and detail of process invariably differ from organisation to organisation but, for the purposes of this description, please bear with this description of the generic process.

Once formal agreement to begin the project is received, inception takes place. In the inception stage the process of requirements capture and early analysis takes place.

Impact analysis of the change in the technical and business areas is performed and an assessment is made of the work, estimates are produced and plans are drafted. These plans divide the work into analysis, design, coding, and testing in a meticulous, linear, planned sequence.

Progress against the plan is commonly measured by the arrival of deliverables or other delivery products such as the requirement specification, design documentation, test strategy, test packs and plans, quality reviews of code output and acceptance reports from the user community. The whole system or solution is delivered at the end of the project and very little sight of, or access to, the system is provided to the user community until after all the requirement specification, analysis, design, test strategy and test planning is complete. Basically it is ready when it is done and that is the first real opportunity the user teams have access to the real results of the projects efforts.

In contrast, agile projects deliver developed, agreed, tested and deployable features which are sections or a subset of the whole solution every few weeks. The objective is to deliver the smallest acceptable element of functionality that will deliver some early business value. The user community is involved in assessment of each of the elements of the solution and feed comments directly back to the development team.

It is important to note that a form of anarchy is a threat to the project here if the scope of the project is not managed closely. The scope and the overall shape of the solution are estimated and an assessment made of the work to deliver it. This still needs to be maintained if the objective is still to build the originally planned and estimated solution. The depth and richness of facilities which comprise the solution are the elements to assess for inclusion in, or elimination from, the next release and from the overall delivery.

Notwithstanding this remark, we have been involved with many successful agile projects that have changed almost the entire scope of a project midstream and gone on to deliver what the business demand to time and to budget. But please let us introduce these concepts gradually. It can be argued at length that it is simpler to walk slowly on your feet on level ground than skip up a mountain on stilts while playing a banjo. Let us walk first and do the banjo routine later.

Almost universally the need to entirely revamp the scope of a project midstream is due to poor assessment in the first place. This could be due to poor assessment by the organisation of either the target area of change or the likely benefits or many other elements. Without an entire assessment of a business area in scope, it is often seen that a new, often small but important, area of impacted business can appear late in the life of a project.

If this event occurs in a waterfall project the newly located or identified business area is casually dismissed as out of scope. This is done because the introduction of the new area threatens scope creep. However, if the area it concerns is an important participant in the project or has an overpoweringly important issue or requirement to be satisfied this almost universally instigates an immediate halt to the project when it is deemed too important to ignore.

This sort of fundamental modification is a significant event to a waterfall project and increases in severity the nearer the project is to the project end date. Due to the linear nature of the project the tasks of replanning, requirements, analysis, design, development and testing have to be fitted into the remaining time. This involves all the people shifting around again and performing handovers to each other at the end of each phase. In an agile project, this phase shift is not a problem at all. If such significant correction is demanded, you replan and start a new timebox with new deliverables with exactly the same group of people. Then the team builds on these deliverables improving and evolving the whole solution as a team, exactly as it was doing before.

Benefits are another infamous difference between well run agile and conventional waterfall projects. Outcomes which directly relate to benefits are regularly reviewed and assessed on a well run agile project. The benefits so confidently promised at the outset of a conventional waterfall project can very easily fade from the projects focus as the deadline of an important and imminent planning milestone appear. In this instance the efforts of the team are directed away from a results driven and benefits focussed delivery towards the gratification of the project manager or some other senior figure to ensure their milestone is achieved. In this way the original benefits of a project get less and less attention.

On a benefits anxious project and especially in blame focussed organisations, what traditionally happens next is that an independent review, project costs assessment or some other type of non invasive project monitoring is performed. This is done primarily to ensure the likely benefits to be realised by the project are going to successfully exceed the projects costs. It also has a disguised objective to pacify all the concerned onlookers so the project and its participants can continue unabated. If this review uncovers a lack of project ability to deliver such benefits or an appraisal that costs are going to be higher then it may propose a different approach or a different scope.

Very rarely in our experience is a project stopped. It happens, for sure. But it is rare. You hear of more poorly delivered projects and projects that were late or were failures than you hear were stopped early to curtail the possibility of the project failing and wasting yet more money. In a well run agile project, if the project is not going to deliver what it planned, it is stopped immediately and all members down tools. Later in the Toolkit, we present the opportunities for project commitment, the techniques to identify waste and the mechanism for stopping a wasteful project.

We discuss this in, not surprisingly, a great deal of detail later. It is an area of much contention and many challenges, naturally. There is no formal technique in the standard agile methods that deals with stopping a project when it gets out of control. It seems they judge the method innocent of this possibility or do not wish to offer a technique to close down a project, as it indicates that problems can occur on agile projects too. This is a comment from marketing people but, in our view, having a project closedown feature is not bad practise. If you always have perfect projects you will never have cause to use the technique. However, at least the technique is there for your use if it is needed. Anyway. We let you decide. Let us move on.

So a waterfall project, we see, treats and deals with scope management differently. It deals with time and quality differently too.

Time is fixed in agile projects. The end date is the end date is the end date, end of story. In a waterfall project the specification of the solution is the fixed element. So, when the team identifies that there is more work or the design has taken the wrong path or some other deviation has taken place, the end date is suitably extended to accommodate the work remaining. So the project is lengthened overall and more time and resource is used, so the costs increase and plans are readjusted to accommodate the new delivery profile. In an agile project, the deepness or richness of the solution is adjusted to accommodate the end date. Therefore the time is fixed and so the costs are known, fixed and much more manageable. This is why you can book your delivery celebration with a level of humble confidence that from the outside seems almost, maybe even totally, arrogant. And so, arrogance for once is good!

Management of the projects is different too. We go into this in some depth later but for now it is sufficient to say that in waterfall projects the plan is the important artefact. You use the plan each day to see what was delivered in the last phase of working and what needs to be delivered next. You allocate people to tasks on the plan, you see how committed they are to their tasks and assign percentages to the level of deliverable completeness. So, for example, if an analyst is half way through her requirement specification you set that as 50% complete. You assess the time remaining taking her planned time-off or bank holidays into account to see if the deliverable is going to be on time. The plan is adjusted again to accommodate any difference in these deliverables and any associated impact this has on other work. The plan shows the emphasis of work skills on the project too with analysts concentrated at the start, moving into designers then coders with testers taking the mantle as the system is released to the awaiting user community. As the project end date is adjusted and end dates of phases within the project are adjusted, the profiles of skills demanded at specific times change too.

In modern matrix management organisations, this invariably means communications need to be made. These will be made to the line management of the various team members sub contracted to the project. Their line managers will want to be made aware of the specific times when their resources are needed on the project and if this demand profile changes. They want to know when their staff members are available and when they will be released from the project. Evidently as end date changes are made, the release date of personnel is altered. This can create a communications and negotiation challenge for the project manager that may, very often, involve many line managers who manage various pools of personnel. All these managers demand and need information on resource allocation, commitment, availability and release arrangements.

This is not the situation with agile projects. The dates are fixed, as we said, so the resource profile is fixed. When you say you need a developer for seven weeks, you need a developer for seven weeks and no more. On the eighth week they are off on another project already. This assurance gives the manager greater confidence in their ability to communicate when deliveries are going to take place and when personnel can be released off a project. This whole positive and assertive ethos gives the whole project and those who interface with it the certainty and elimination of indecision needed. This sort of assured and precise project feedback and values enable more straightforward project control. This encouraging management of the project though comes with some demanding challenges to conventional management of the project, not least the vital need for extraordinary empowerment of all your people on the project. So, let us look at this topic next.


 Introduction to Agile     Introduction to Agile   Empowerment versus Control    Empowerment versus Control

Glossary:     a  »   b  »   c  »   d  »   e  »   f  »   g  »   h  »   i  »   j  »   k  »   l  »   m  »   n  »   o  »   p  »   q  »   r  »   s  »   t  »   u  »   v  »   w  »   x  »   y  »   z

#personas  »   #artefacts  »   #archetypes  »   #patterns  »   #change  »   #personas  »   #increasingoutput  »   #reducingvariation  »   #improveefficiency  »   #abstraction  »   #predictionandcontrol  »   #management  »   #organisations  »   #socialnetworktheory  »   #failfast  »   #quality  »   #waste  »   #complexity  »   #learning  »   #adapt  »   #inspect  »   #improvement  »   #models  »   #complexadaptivesystems  »   #informationflow  »   #sytemsthinking  »   #butterflyeffect  »   #unpredictability  »   #chaos  »   #emergence  »   #emergentbehaviour  »   #distributedcontrol  »   #continuousimprovement  »   #complexityscience  »   #gametheory  »  
 Agile In 6 Steps    |    Projectivity    |    Instant Agile    |    Risks    |    Auditing Agile Projects 
Big Agile Toolkit Book (Amazon Japan)   |   Big Agile Toolkit Book (Barnes and Noble)
Buy the Big Agile Toolkit Book   |   Buy the Big Agile Toolkit Kindle eBook
Contrast to Waterfall


The Big Agile Toolkit

 SPADE: Successful Pragmatic Agile Delivery Everytime™ 
Topic: 10  Page: 11/444  Progress: 2.5%
 About    |    Author 
Follow @BigAgileToolkit

This content can be copied to third parties for personal use if you acknowledge the source of the material with website URL ( and Twitter hashtag (#BigAgileToolkit).
In all other cases, no part of bigagiletoolkit or associated text or website may be copied reproduced or redistributed in any form or by any means without prior permission in writing from the author.
Agile Project Governance for Cost Conscious Companies™

All rights reserved.