One of my posts yesterday drew a question and a response on the relationship between these two, so I thought I’d give the topic some airtime.

For anyone interested in the subject, a good place to start is Martin Fowler’s seminal article on the subject.

Read it for yourself, for sure it’s worth it. When I read it the first time around, I remember two things really stood out for me:

• One, that the way to break teams up when seeking to do agile-with-offshore is “high cohesion and loose coupling”; you have to move entire cohesive units over, not what you would plan for in a waterfall or cascade approach. This is really important, since everything agile relies on good quality communication and team facetime.
• Two, if you don’t do this, then you get a variation of Conway’s Law in operation. The system you build is a reflection of the team structure. So when you don’t have high cohesion loose coupling in the way you’ve structured the team, don’t expect to see it in your code.

There’s lots of good stuff in Martin’s article, and in the Thoughtworks Bangalore experiences he shares. Agile and Offshore can and do go together.

Incidentally, with all this talk about Agile. I thought it was worth linking to the Agile Manifesto, just in case one or two of you were interested in the subject and hadn’t actually seen it before. Rummaging around Martin’s articles, I came across it again, and felt it was worth sharing.

So here it is: The Manifesto for Agile Software Development.

I can’t resist copying it here, just for those who don’t bother to follow the link:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

[Signed everyone who is anyone in Agile]

Sometime ago, in a post entitled The Destination Not the Route, I shared some of my thoughts about Agile development. Since then, a number of people have come up to me or written to me asking for a similar sideways look at the time dimension, particularly in the context of Agile versus Waterfall development.

Agile development is often about time-boxing or time-placing, the two techniques are sisters under the skin. Since time-boxing involves splitting projects into fairly small chunks of time (keeping the time fixed, the team small and varying aspects of the deliverables), people often consider Agile as synonymous with Short-Term.

If this wasn’t bad enough, the same people often compound the error by then considering Waterfall as synonymous with Long-Term.

This is a fundamental fallacy. Let me try and explain, using an everyday nothing-to-do-with-software analogy.

Let’s assume you’re married, with two kids of schoolgoing age, and that as a family you had a yearning to go away somewhere hot for Christmas, just for once. Let’s say you live in the UK, and that you decided to go to South Africa for Christmas in 2008.

South Africa. Christmas. 2008. Long-term enough for you?

That’s the headline plan. When it comes to preparing for it, you have a choice. You can do it the Agile way, or you can do it the Waterfall way.

The Waterfall Way:

• You check the flights and hotels out straightaway, select some hotel in Cape Town, book flights direct from Heathrow to Cape Town, put down a deposit in sterling, forward-buy the rand you think you may need for the holiday, get the necessary visas (if you’re Indian, like me, you need visas to go to the loo!), sit back and think, great. You’ve done everything ahead of time, you’ve saved money, all you need to do is wait to go on that holiday.
• And throughout 2007, you’re pretty relaxed about things. One day, while travelling elsewhere, you realise that the visas you thought you had were no longer valid, that they’d expired 30 days after you got them. This irks you, but not much. You can always get new ones closer to the time. But you wish you’d known. Then the rand weakens against sterling, and another set of niggles set in. Should you have done the forward trade? But you’re not a foreign exchange specialist, the sums involved aren’t large, so you remain relaxed.
• Then, in January 2008, you get the dates for school closures. Your children are missing more school than you intended them to miss. Oops. You contact the travel agency. They try and help, but the tour operator you chose went bust, and the guys who took them on are offering flights to Jo’burg in compensation. In panic you check out the hotel you thought you booked, only to find it’s been partially demolished and that work will continue on the wing you planned to stay in, for the foreseeable future.
• I won’t go on. Suffice it to say that you have to do things more than once, that you have to change things, throw away things, spend and waste more energy than is sensible. And at the end of it you’re left feeling frustrated, dissatisfied and angry.

The Agile Way:

• You plan out what you need to do, but in sensible time-chunks. You do what you must do right now, and nothing more. And you keep adhering to that principle all the way to December 2008. Doing what you must do at the time, and nothing more. No wastage. No rework. An inherent flexibility in the way you exploit your resources, allowing you to change your mind as better information emerges, with minimal cost.

I’m not going to labour the point, but it is important. So here’s the takeaway:

1. Using Agile, you feel insecure (-ish, especially if you’ve not tried it before) at the start of a project, and satisfied at the end. Using Waterfall you feel good at the start and crap at the end. If there is an end.
2. Agile is about a way of doing things, and it does use time-boxing as part of the technique. Waterfall is also about a way of doing things, and it doesn’t use time-boxing as part of the technique. Most projects use Waterfall. Most projects fail.
3. Agile does not mean short-term, in fact it is the opposite. It creates sustainable incremental value. Waterfall, on the other hand, seems to be long-term, but is actually about the worst form of lock-in. A design lock-in before you have enough information, just to prevent you from having kittens right now. Is there anything more short-term than that?

4. I used to be more tolerant in the past, and used to accept that Agile and Waterfall are different horses for different courses. I now realise that’s a lie, an invidious one. Why? Because I accepted the theory that some projects were large, didn’t change much, could be planned in real detail in advance, had everything known about them, and didn’t need Agile. Now I have a better word for such projects. Failures. Expensive ones.

5. A coda. Projects like EMU and Y2K and Basle II and Sarbanes Oxley were called Death March projects because they were long and expensive and unnecessary and ineffably boring and yet had to be done and required immensely large quantities of resources. [Well if you will believe what consultants tell you, and abdicate responsibility altogether, you deserve everything you get!]

Yet we never heard of any failures for projects like these. Why? Weren’t they Waterfall?

No. These oil tankers were actually Agile. Why?

• (a) Nobody could change the end date, a key criterion of Agile Not Waterfall.
• (b) As a result, people traded on the deliverables and not the time. Another key Agile criterion.
• (c) These were “compliance” projects, but with one major flaw. Nobody, not even the consultants who kicked up the storm, actually knew what to comply with. There was a long period of amorphousness while people worked out what the meaninglessness meant. This was true Discovery, another Agile criterion.

I could go on, but won’t. Enough said.

My last two posts were about great teachers and about life in Calcutta. Rama informed me about the passing away of someone who could be identified with both posts: Fr Beckers. Read Rama’s post, and you can figure out what an impact the man had.

We were really privileged to have been at St Xavier’s. I don’t know what it was about the place, to have attracted so many wonderful teachers, people with genuine gifts and calling, people who gave their lives to the institution. It was the kind of place that made you want to break into school before opening time, even though you had a happy and contented home life. I remember doing just that once, climbing over the metal gates at what used to be the hostel entrance on Short St (it may have been on Wood St, can’t actually remember which one was which). And just as I tried to jump off the top of the gate (it was a solid metal gate with spikes on top) my trouser leg got snared by one of the spikes, along with a teensy bit of leg, and I hung upside down in agony until help arrived. Those gates didn’t open till seven, and I wanted to get in twenty minutes early.

That’s what my schooling was like. It was like that because of the sheer passion and commitment and quality of the teachers I had, from 1963 to 1979. Initially I was at Miss P Hartley’s Private School, in a converted stables in Landsdowne Road, then I moved over to St Xavier’s in what was called Small School in 1966, crossed the road to Big School in 1970, then moved across the quadrangle to College in 1976.

I am sure many of you had similar experiences. One day I will figure out what motivated the Miss P Hartleys of this world, the Fr Goreuxs, the Fr Bouches, the Fr Beckers, the Fr Huarts. One day I will figure out what motivated the Viannas and the Sens and the Bhowmicks and the Samajpatis and the Engineers. They helped make me me.
So here’s to great teachers everywhere. We owe them a lot.