 |
 |
|
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.
|
|
SPADE: Successful Pragmatic Agile Delivery Everytime™ 