Save £12 Million every year > Save £3 Million every quarter   
The Big Agile Toolkit: no Dogma, no Bias, no Accreditation, no Exams & no Fees   
 DELIVER Develop  DELIVER Develop   Build and Fix List   Build and Fix List

Lifecycle   »   DELIVER   »   Build and fix

Traditional methodologies deal with the processes of build and bug repair separately. They have a process for build called development. They have processes for defect management, defect tracking, defect fixing and management and so on. Here we differ.

Working on a project using the Toolkit, when we are building something or when we are fixing something, we are still developing. So we treat them in the same way. We do not do this just to be different. We do this for cost saving purposes. There is no cost effective reason to treat the development of a new feature and the repair of an existing feature, in two totally different ways. Now that we are working in an agile fashion we are assessing our deliverables earlier, so there is no need to wait for bugs to appear. They will be identified and caught earlier, so you have the opportunity to knock them out earlier, so just do it.

In traditional projects, developers are asked to build new features then, later on, to spend a full day (or more) purely fixing bugs. Think about it. The developer may not have worked on that specific feature, before. It may have been developed by someone else altogether. So, the first thing they have to do is understand the feature and how it was built before they can identify the error and its cause. That is wasted effort. It is always more cost effective to get the person who created the bug, to fix it. Evidence those who create errors often too!

The other reason why we treat these two activities, build and fix, the same is that we plan and report on them together, in the Toolkit. We identify the requirements for build from our project requirements list. We review the project requirements list and the stories we are going to build, as part of our assessment. The assessment provides us with feedback on the development and allows the business team an opportunity to revise the stories for build and the project requirements list. Let us look now at the build and fix list.


 DELIVER Develop     DELIVER Develop   Build and Fix List    Build and Fix List

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
Build and fix


The Big Agile Toolkit

 SPADE: Successful Pragmatic Agile Delivery Everytime™ 
Topic: 284  Page: 243/444  Progress: 54.7%
 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.