In an earlier post, I had touched upon TDD very briefly, and had promised some practical tips on implementing TDD in a future post….Here you go…

Having managed teams implementing TDD, Yours Truly has learnt the hard way, that implementing TDD is not cakewalk, the glamour and hype attached to it notwithstanding. So if you are contemplating on implementing TDD, here are some practical tips:

1) There will be starting-trouble, since this calls for a complete paradigm shift in the minds of the developers. Most ( if not all) of us have grown up by hearing and practicing this – Write code, then test. TDD turns that completely topsy-turvy. It says, write a test case (it will obviously fail since it is checking for code which is still not there). Then write code which will just satisfy the test case and make it run (note that the code should do nothing more than barely making the test case run). Then write the next test case, and make it pass by writing the corresponding code. This concept requires some unlearning, and so pls be prepared to add sufficient buffer in your deliverables for implementing this, and don’t crucify your developers for taking some extra time in the beginning of your TDD roll-out. This extra time will come down once they are comfortable with this approach, and then they’ll reach a desirable mindset where they’ll find it difficult to write code without writing test cases, but till then, patience….

2) Better to involve those experienced folks who know Unit Testing (eg NUnit, JUnit). If they have worked on Unit Testing for some duration, and have been writing the test cases after the code was written, then they would definitely have faced issues where they’ve had to refactor the code in order to increase the code coverage from the unit test cases written. This is a constant pain, and TDD removes this by having tests initially, so code-coverage is not an issue (in case you are wondering, ‘code-coverage’ gives a measure of how much of the codebase is covered/tested by the unit-test-cases-suite).

3) Start with a very small but determined pilot team. Starting with a big team is not really manageable, because of the delivery pressures…

4) It is very easy for them to slip back into the traditional way of coding, if there is a schedule pressure….so watch out closely for that.

5) Go for a code coverage of about 70-80%…more than that could become an overkill in the initial stages… looks like the Pareto rule is kind-of applicable here too — you can achieve 80% of code coverage with 20% of effort, but the remaining 20% will take about 80% of the effort. Do I have a big array of statistics to prove this? Nope…Just a few metrics collected in those projects, and a gut feel evolved over time. I have seen the enthusiasm die down because of the amount of additional effort needed to cover that last stretch …It will take significant effort from you to rekindle the enthusiasm. So better to aim for about 70-80 % initially, and it’ll work.

6) Its ok to have less unit tests for UI, since UI needs to get covered more by the Functionality/Usability testing. Focus on using TDD more for the sub-strata (layers below the UI).

7) In the middle layer(s), there would be integration points, and we should make sure that we are not ignoring these parts, especially if they are part of the critical functionality/logic. Now the question is, we are doing Unit Testing (or in other words, we are not doing Integration testing), so how do we cater to the integration points, since there would be some chatting between modules/classes. The solution is to use stubs. That is, create stubs which will be called (instead of the actual foreign class/module) by the unit, and return various values, and so the behavior of the unit can be tested based on the different values returned by the stub. Now the point is, writing stubs can be cumbersome. So for that, you could use some third-party API. For eg, there’s a very good API for this very purpose, called TypeMock.

What is outlined above is but some of the pitfalls that you need to watch out for, in your journey towards TDD. Happy Test Driving !

Before trying to answer the above question, let us quickly touch base on what is the difference between the terms ‘Unit Testing’ and ‘Test Driven Development (TDD)’, or is there a difference at all?

 Here’s what. Unit Testing simply means that you write unit test cases to exercise minute parts of the codebase. The term ‘Unit Testing’ by itself doesnot state the chronological order, ie whether the code comes first and then the unit test case is written, or was it the other way round, ie whether the test case is written first. The latter is actually a simplistic definition for TDD. That is, write unit test cases first and then write code to satisfy those test cases.

 So TDD is actually the next step in the evolution of Unit Testing, in that the test cases are written upfront, before the code is written, thus providing various advantages. The code that comes out of TDD is rock solid, high quality, better designed, easily testable (especially regression testing), and easily maintainable (one of the reasons being that the test cases act as documentation). So from that perspective, the question whether TDD makes sense or not, ie whether the code should be written first and then the test case or should it be vice-versa, is a no-brainer (IMHO). TDD has come way beyond the hype stage, and writing test cases first definitely makes proven sense, but whether it will be successful or not, depends wholly on the way it is implemented, the acceptance of this within the team, and the management support to make it work. That’s asking for too much, eh? There are several pitfalls that you need to watch out for, in your journey towards TDD. We’ll examine these in a separate post.

In an earlier post, we have examined how we can use agile in a fixed-bid project by considering scope as a variable. in this post, we will take a step back and examine the ways in which we can leverage the power of agile within the business constraints imposed by a fixed-bid contract.

1) Continuous Integration (CI) : Whether you are following a Dedicated or Time & Material or Fixed-Bid type of engagement, CI is a very useful and proven Agile tenet. The Root Cause Analysis of the issues that come up during the last stages of a typical release will point to Integration issues as one of the root causes.
There tools around which can be used for automatically building and deploying your code at very frequent intervals (or on a need basis) so that the integration issues are closed as and when they are found, instead of accumulating till the end.
One good example is CruiseControl, which has versions for Java as well as Dotnet environments. You could visit the thoughtworks site for more info on CruiseControl.

2) Pair programming: Pair programming is an agile tenet which advocates having a pair of programmers work together on all coding aspects, instead of working individually. Compare this with a typical scenario where the programmers work individually for all
their work. 100% pair programming is a controversial topic, and we will not get into that debate in this post. But what is not controversial, and indeed beneficial, is to use pair programming in a contextual manner. That is, whenever you are faced with a difficult problem, have 2 people work on it. That has proven to be much more productive than the aggregate work done by them separately. Also, there is a knowledge backup within the team for all the difficult sections within the codebase.

3) Small releases: Have an overall fixed-bid contract which allows about 20% deviation in the scope. Then have smaller iterations where small chunks of feature requirements will be identified, zoomed-in, designed, implemented, tested, and be ready to be deployed.

In other words, it is very common to find the fixed-bid billing model tied to the waterfall methodology. There are inherent problems with the traditional waterfall software developement life cycle (SDLC) methodology, and it is better not to mix waterfall and fixed-bid. Pictorially it can be represented this way:

Requirements->Design->Coding->Testing->UAT->Golive

Feature set #1—>Feature set #2 —>Feature set #3

The main difference is that in the waterfall model, the compartmentalization is in terms of phases, whereas in Agile, the compartmentalization is in terms of features—ie, in Agile all the phases will be implemented for each set of features in the order of decreasing priority of features. We will talk more about the mechanics of this, in a future post.
In summary, some of the Agile tenets can indeed be used in a Fixed bid model, actually reducing the heartburn for all the stakeholders in the client’s as well as the vendor’s side.

Let us start by looking at the characteristics of fixed-bid projects:
1) Time-bound
2) Predefined scope — normally immutable
3) Fixed set of resources
4) Predefined quality checks

Wow ! Isn’t the set above, a project manager’s nightmare. What we are essentially saying is that, out of the 3 allowed Project management variables of Scope, Resources, and Time (although there is a 4th parameter – Quality, it can obviously never be taken as a variable), none is allowed to be a variable in many fixed-bid projects. That also normally leads to the project not meeting the expectations, because the expectations were unrealistic in the first place. Does it mean that all fixed-bid projects are doomed to fail? Not really…if there is an upfront understanding among the different stakeholders that one of the 3 (Scope, Resources or Time) is allowed to change from what was agreed in the beginning of the project, that itself increases the probability of success of the project by a significant amount.

So, now that we have agreed (?! ) that it is preferable to keep one of them as a variable even in a fixed-bid project, let us look at what Agile requires and recommends.

Although there are many Agile methodologies out there, one of the common threads among them is the allowance for a change in scope mid-stream. That automatically fits into (one of) the criteria for the increased probability of success of a fixed-bid project.

But then, if the scope is allowed to change, what is so ‘fixed’ about the ‘bid’ ? Here goes:
1) Out of the 4 potential variables, 3 (R, T and Q) are supposed to be constants.
2) Now let us zoom-in on the ‘Scope’ part. Let us say that the clients want to change the requirements in the middle of the project (sounds so familiar..doesn’t it?). You could do one of 2 things:
a) Remove lesser priority items for making way for the new high priority items. How? You would most probably have done a size estimation of your project in terms of Scrum-Story-points or XP-User-Stories or XP-Tasks or whatever. Use that for the barter. Pull in the high priority items, and push out the least priority items of equivalent size. Well, can/should it be as accurate as what was expected in/of the ‘Merchant of Venice’? Not really, but at least the gap is significantly reduced to the extent of being manageable…btw, the exchange accuracy expected in the Merch of Venice was also an overkill (no pun intended), wasn’t it ?

b) In your fixed-bid agreement itself, keep a provision of about 15-20% for handling the creepiness of scope. That way, you can still inject feasible scope without replacing any agreed scope. Why do I still use the word ‘feasible’? Because of 2 reasons:
 i)  We cannot obviously inject scope more than the allowed percent
 ii) A more implicit reason is that scope cannot be changed (even within allowable limits) if it is coming in too late in the cycle, and if it has a serious impact on the design roots. Needless to say, there may be cases where the scope does come in too late in the cycle, and is also threatening the design roots. In such cases, it is better to re-work the SOW( Statement of Work) and start afresh rather than trying to squeeze the drastic scope-change into the ambit of the current agreement.

In summary, Fixed-bid projects can be done in an Agile manner provided some of the danger zones are taken care of. Is the above approach the only way to bring the obvious advantages of Agile project management to fixed-bid projects? Not really….pls do come back for more posts on this…