Silver Stripe Blog

I recently gave a presentation on an Introduction to Agile Methodologies. Unfortunately, I only have the presentation, and not the audio narration that goes with the presentation. Therefore a few of the slides might not make sense taken out of context from the narration. Here is the presentation:

| View | Upload your own

Gareth Reeves has an intriguing post where he compares Cost vs Risk in Agile projects. The summary of it is that in a Fixed Price contract, the vendor bears the risk should the project be delayed. On the other hand, agile projects are often Time and Materials contracts. In such projects the buyer takes on the risk of delay, because the buyer will end up paying more. Thus, the buyer takes on more risk in agile projects.

While I do agree with the above, it does not tell the whole picture. That’s because cost is not the only source or risk. There are other sources of risk in software projects. For instance, what if the project is never completed? Or what if the project delivered does not meet the requirements? These are huge risks, and the history of software development tells us that a large proportion of projects fall into these two categories.

By following an incremental delivery with frequent feedback and allowing the buyer to make changes to the scope on a frequent basis, agile projects vastly reduce the risk that the final deliverable will not meet the requirements.

By making releases with the most important functionality prioritised up front,  agile projects vastly reduce the impact should the project be terminated midway.

These are two huge sources of risk that an agile process can mitigate, and are good reasons why the buyer should actively ask for an agile process. Cost is not the whole picture, especially if we are talking about the risk the project may never be completed or may not meet requirements.

(On a side note, it is possible to follow an agile process with a fixed price contract as well. More on that later.)

I’ll be in Hyderabad this Saturday (12th Jan) for the Hyderabad Scrum Unconference. I’m looking forward to meeting other Scrum practitioners from around the country. Most of the Scrum and Agile conferences and user groups in India are targeted at people who do not have experience with Agile and the goal is to increase the awareness of Agile.

I’m really itching to meet up with people who have a couple of years of Agile experience under their belt, and I’m hoping that the crowd at this unconference will have some more experience so that we can go beyond the “Intro to agile” type of talks into some more advanced stuff.

I’m thinking of doing a session at the unconference on “Agile in Dysfunctional Environments.” If you’ve been practicing agile for any length of time, you’ll eventually encounter less than ideal situations. For example, what do you do if management won’t let the dev team have direct contact with the customer? Or due to internal politics, you cant have the testing team co-located with the dev team? Maybe the team is distributed?

For each of these situations there is one “prescribed” answer, which is that Scrum exposes the dysfunction in the organisation and you are supposed to eliminate the block. While this is a satisfying explanation on a theoretical level, I’m not convinced that this is always the right answer. There is often something good to be had from eliminating organisational dysfunction, but often it is not immediately possible to do so.

Inter-department politics, for example, may be deeply entrenched and it is no good running the project to the ground while the dysfunction is being sorted out (if it ever will be sorted out). There are many such situations where it might make more sense to work around the problem is a suitable manner than to attempt to recreate the organization from top to bottom.

Distributed Agile is a perfect example of this. Technically, distributed agile is a bit of an oxymoron because Agile teams are supposed to be co-located. Although I am all for co-locating as much as possible, there are situations where you cannot co-locate and rather you have to make the best of the distributed team that you have with you.  Dealing with fixed bid projects is another such situation.

Incidentally, Thoughtworks, which is probably one of the best known Agile companies, has both distributed teams as well as a large share of fixed bid projects (at least in the India offices), which just goes to prove that we should not be highly dogmatic about what is prescribed.

Anyway, that is the rough outline of the session I had in mind. If you are in Hyderabad on Saturday, do drop in and say Hello.