To TDD or not to TDD – Yet another chicken-egg situation ?

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.

Anyway, TDD is not the be-all-end-all of Agile. If you’re able to make it work, great, you’ll see the benefits. But if you’re not, don’t fret, there are other tenets in Agile which can be implemented easily and fetches good results. We’ll examine some of them in the forthcoming posts.

Ciao 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Agile Fixedbid — an oxymoron ?

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

Where, 
the first line indicates the typical approach using Waterfall model

the second line indicates the approach using smaller closed iterations (Agile model), with the various phases of an sdlc compressed into each iteration.

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.

Is Agile suitable for fixed-bid projects ?

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…