Save £12 Million every year > Save £3 Million every quarter   
The Big Agile Toolkit: no Dogma, no Bias, no Accreditation, no Exams & no Fees   
 Agile and Deliverable Features  Agile and Deliverable Features   Agile and Evaluating Waste   Agile and Evaluating Waste

Manage   »   Quality   »   Agile and Identifying Waste

On the traditional project, we also have requirements and invariably a business team have reviewed the business requirements and deemed them to be important. However we need to consider this statement in the light of one important concept. On the traditional project a complete and timely delivery is almost never anticipated. Experienced business personnel expect the project to fail to deliver all their important requirements. This expectation drives another concept: over ordering. A customer or business team will pad out the requirements list to ensure the maximum possible set of features is represented. This is done because they expect the project will hit the rails at some point and start to ditch important features.

The theory goes that if extra sacrificial features are added then these will be jettisoned when the challenges loom. It does not quite work like this though. There are surplus requirements added and each requirement will have extra padding added so each feature has an extra depth of richness, trimmings, add-ons and luxury. A lot of waste is delivered in non essential requirements as well as within the extra polish added to more essential requirements.

These final deliverables may contain an element of the surplus requirements which were expected to be redundant and were not as important as other requirements waiting for funding and development, hopefully, in a next phase. More unessential often superfluous additional functionality is developed in this way and important funds are used on, what is really, unsolicited development that often times uses up the last dregs of the project funds.

You will be aware that on agile projects we also ditch features if the time does not allow but there is a key difference. A traditional project is split into phases or deliverable chunks and these will await sign off from the business. The business will oftentimes only sign off on a phase if all the deliverables of that phase are complete. This means a development team will work extra to deliver the add-ons and polish to make sure the final deliverables are signed off and then the phase is completed.

This work is done under the banner of quality as the deliverable is not said to be of sufficient quality until it is signed off. More waste ensues from this activity. This effort has been used to add unnecessary polish to a deliverable. In an agile project we will use that cost to deliver another priority deliverable and the business will sign off fit for purpose results. We consider this concept when we come to agree acceptance criteria for shipments and deliverables. Fit for purpose is the guideline and it is written in one of our Commitments. Beyond the requirement for a fit for purpose outcome is waste and we avoid this, always.

What we remember, is this. A business manager is spending budget for this financial year, now. The budget for a financial year is often planned well in advance. The project manager may or may not have known that this project was coming along. Nevertheless, that budget is now funding this project. A smart manager will try to use up this years budget ensuring very little is left at the end of the financial year. So often, a manager will try to use up the budget inside a project. This tends not to happen very much on shrink wrapped software. It does happen on bespoke application development. So, a keen manager using up remaining budget is one way that unnecessary features are added and appear.

Another scenario is caused by the requirements process of traditional development. Users define their requirements upfront, once and some time before development begins. Those requirements go into, what is often, a massive requirements document. What we like to call a dull thud document because of the sound it makes when you launch it on to your desk.

The requirements process goes something like this. The business users are instructed to go away in a huddle and come up with the requirements of a new system. In our experience, whether they are knowledgeable of the budget or not, it seems to make little difference.

They do not come up with the number of requirements they can live with as a minimum. They try to come up with a maximum number of requirements they can think of. That is the way to spend someone elses money. Isnt it? Seriously though, it is often done with the best of intentions. They want to ensure that they have explored the full possibilities of the new system, to make the system flexible enough for future requirements, to reach out and to interface with other systems in the organisation and to visualise how the system would actually be operated, in the real world. With such ideas it is not weird to see weird ideas.

Moreover, as we pitched earlier, their experience is that solution developers rarely deliver all the things they request. They know that when things get tight, the solution developers are going to start to drop requirements from the final solution. So, in their mind, it is best to ask for much more than you really want and you will probably get most of what you want after all. So, in this way, extraneous and esoteric requirements are added on the assumption that these will be ditched when the going gets tough. What we find, however, is that the business teams did not share this private information with their solution developers and these weird and wonderful requirements get planned into the first phase. As the first phase is not always the place where requirements are abandoned, these requirements were developed. So, in this way, low priority requirements were developed and will probably form part of the 40 to 50% of functions that are never used. This is waste that could be avoided.

 Agile and Deliverable Features     Agile and Deliverable Features   Agile and Evaluating Waste    Agile and Evaluating Waste

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
Agile and Identifying Waste


The Big Agile Toolkit

 SPADE: Successful Pragmatic Agile Delivery Everytime™ 
Topic: 123  Page: 119/444  Progress: 26.8%
 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.