Myths about time and material model

Myth 1 – Iterative product development using agile methodology must be done using the T & M model. “Fixed bid agile” is an oxymoron.
T & M has certain intrinsic inefficiencies listed in the myths below. It works better for outsourcing work to “body-shops” than to the tech savvy providers of product development service. It is possible to do agile development in the fixed bid model using the first iteration to elaborate requirements and estimate costs. DSDM ( www.dsdm.org ) which is one of the agile methodologies prescribes this too.

Myth 2 - Fixed Bid model can’t whereas the T & M model can address loosely defined requirements which is the case with most of the product development work.
Nothing can be more untrue than this. Most of the customers and product managers know most of what they want when they decide to approach the developer. Many of them have elaborate requirements document covering most of the core functionality to be delivered. The developer can estimate and submit a fixed bid on the basis of such a document. Its true that requirements change and estimates need to be revised and the requirements document becomes outdated. But having an outdated document and an initial estimate is better than not having any document or estimate.

Myth 3 – Customers own the team and the IP held by the team-members. Team member’s tacit knowledge is more valuable than explicit knowledge stored in the document form.
Agile gives more importance to people over processes and working code over documents. But relying on people as the only way of holding IP is dangerous particularly when you are using off shore teams where factors such as attrition and low loyalty and low experience need to be accounted for. Teams must maintain documents that give insight into the code being developed or else it will be difficult to induct new members into the team.

Myth 4 – Why spend time on elaborating requirements, design and delivery plan as required in case of the Fixed Bid model? Requirements change; thus making the design documents outdated and throwing the delivery plans off course.
Design documents not only record what is going to be delivered in the code but also force the developers to organize their thoughts. Similarly not having a plan with milestones and completion dates is not a good idea. Over all management and cost control would be difficult without a plan. Design and plan documents provide the basis of comparison to estimate extra efforts required when the requirements change. Story point based flexible plan with no completion dates can lead to “gaming”.

Myth 5 – Delays happen mainly due to the phenomenon of “requirements creep”; hence customers must allow teams to postpone part of the time-boxed deliverables to the next sprint – in other words, customers pay for the delay.
Developers should share the risk of such delays too. Its the developers’ responsibility to extract requirements in the first iteration by asking the right questions. Quick methods of estimation such as “Planning Poker” lack the opportunity for product owner to go back to business analysts and other customers for answers to some of the questions posed by the developers. Time boxing prescribed by the agile model is possible only when enough effort has been taken on elaborating the requirements. Leniency on what is delivered in each sprint leads to inefficient utilization of development resources and hence it should be avoided. There should be some restriction on when and how much to re estimate.

Myth 6 – Test Driven Development. Unit tests can always be written before code and they serve as a substitute for an elaborate requirements document
Many a times developers can’t think of a test before they write the code. By their very nature developers think of “how things work” unlike the testers who think of “where things can go wrong”. Unit tests coverage is rarely 100%. Developers decide not to write unit tests for certain functionalities under extreme time pressure. Unit tests can become outdated just like design documents and are even harder to maintain.