Monday, 28 June 2010

No Agile Gospel please, just give me Enlightenment

For lack of a logo, here's the Snowbird resort where the Agile Manifesto was developed back in 2001

Agile Software Development presently is suffering from evangelisation, it seems. Which is awkward, as it's been around for almost 10 years, and evangelists usually are needed in an earlier phase in life. By now I'd expect Agile temples and churches to self-attract masses of believers. In stead, it's a bit like fundamentalist Christians repeating the 2,000 year old words from the Bible - and I thought that good wine needs no bush?

As there seems to be a Manifesto for everything these days, here's the Agile Manifesto:
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.

Glancing over that, I get a rebellious, anarchistic feeling - but that's maybe me. After a lot of reading and discussions with friends and foes, I'm fairly convinced that Agile is a good way to deliver working software in small, close-knit teams. The problem is that it's also being adopted for larger software development projects, even in combination with offshoring - a situation that is clearly not advantageous to Agile

Some of the principles behind the Agile Manifesto are:
  • Customer satisfaction by rapid, continuous delivery of useful software
  • Working software is delivered frequently (weeks rather than months)
  • Working software is the principal measure of progress
  • Even late changes in requirements are welcomed
  • Close, daily cooperation between business people and developers
  • Face-to-face conversation is the best form of communication (co-location)
  • Projects are built around motivated individuals, who should be trusted
  • Continuous attention to technical excellence and good design
  • Simplicity
  • Self-organizing teams
  • Regular adaptation to changing circumstances

Again, I see an old-fashioned situation where we're all stuck in traffic on our way to the customer on a daily basis, don't outsource or offshore (part of) the work, and where large vendors or system integrators fit in because they provide the most experience and stability. And yet Agile's only deemed fit for small projects (10-20 people). And there are more who say so

But, my main question is: what if you're driving an Agile car and it breaks down?

It's all fair and square that Agile works because it focuses on software development and delivery, not the entire Application Lifecycle of which typically 20-30% is spent in development, and the remainder in maintenance. There's always a trade-off, and only God can create matter out of thin air
  • I understand that it's costly enough as it is to start coding almost right away and change that on an ad-hoc basis if the customer requires so
  • I understand that it's too costly to having to change documentation at the same pace of having to change code
  • I understand that a great dependency on humans is created if an application's functionality and structure is not described well enough. This is not unique for Agile, but Agile does seem to pay even less (if any) attention to it
  • I understand that this dependence on humans will put great strain on regular or irregular test and maintenance in terms of finance and time
  • I don't understand why at go-live there isn't an effort made to mature the software delivery by making it "stick" to paper. Not that I deem documentation sacred, and I've been inside more than enough companies to see that it is usually at least incomplete or not full up to date, but:
what if your Agile car breaks down in the middle of nowhere?
Do you ship it back to the factory?

It is so very 20th century to must depend on certain people for anything; I call that the worst form of lock-in, viz. knowledge lock-in. To have to rely on a specific party or company is slightly less worse, and called third-party lock-in. The least of all evils is vendor lock-in.
And yet, you can take your broken-down car and move that to the nearest garage, and chances are they can fix it quickly and against a competitive price. That's because, and only because, they ship each car with ample documentation legible to anyone. Not because they had so much fun and anarchy creating a product that only they themselves could fix or maintain. Heck you could even do it yourself if you had some tools and patience. That's not lock-in, that's Freedom. And it is Freedom that we should give our customers, because they pay well for it

Stop evangelising Agile. Give me Agile TCO. What are the trade-off costs for the increased time and money you have to put into Agile test, and what are the trade-off costs for the increased time and money you have to put into Agile maintenance?
And stop measuring success by projects if you're really all about Software Development. Projects take up 20-30% or even less of an application's lifecycle, so that's only a small portion of the cost. Moreover, it's not until after the release of a product that it is actually going to function for the customer

5 reacties:

Lee Provoost said...

Hi Martijn. Good observations and in general I agree with them. Why? Because I've seen too many times that people / companies see agile as the holy grail that will solve all their problems and "agile-ify" everything. Wrong.

Agile can be extremely useful in certain domains and scenarios. It's definitely not something you will apply to everything.

Based on the talk I gave on the SAP conference and that Dennis Howlett recorded, I argue that agile fits quite nicely in the interaction part when you are making the distinction between interaction and transaction. I do believe that agile isn't necessarily the best fit when you are planning and implementing a strategy around an ESB that links several legacy systems together.

I do believe that it fits very nicely in developing people facing and interaction focused web applications. Also in combination with a platform that fits naturally (like Ruby on Rails) and a mindset that follows with it (bit more the startup-like team approach with product owners and quick iterations).

This does also fit nicely in a wider larger program. Currently executing this for a post-merger IT integration where we have several agile development teams working on several client portals with their product owners, whilst it fits in a more tradtional program management and works together with a more waterfal type backend systems workstream.

It does require a certain design authority that guards the design and architecture principles and can coordinate work and dependencies between the different teams.

The reason why it fails so often is the lack of culture and understanding. Being a product owner requires delegated authority (which is often not there) and dedicated time for the product owner role (often they do it next to their full time day job). Clients usually like the advantages of agile, but don't want to accept the insecurity that comes with agile because you are not committing to a set of features, only to a set of sprints.

I've had several interesting discussions with people that basically ask us to specify up to sprint 25 the deliverables, well that just doesnt work obviously.

Also we need to be honest here. In the situation where clients come with vague requirements to us and don't know themselves what they exactly want. These type of clients often tend to ask for a fixed price / fixed time project. It just doesn't make sense to engage in such way. Agile fits the bill better.

Martijn Linssen said...

Great Lee! and thank you very much for your lengthy and interesting comment.

I absolutely agree with you on the situational approach for Agile. Here's what is called the Agile home ground:

* Low criticality
* Senior developers
* Requirements change often
* Small number of developers
* Culture that thrives on chaos

and I would certainly agree with that. Heck that's how I start my own pet projects

I love the way you guys fusion the post-merger project(s). That's natural, almost like languages converge along state and country borders

I agree with the reasons for failure and the false expectations, but from other points of view there is what I call the monocultural aspect. Let me elaborate: I studied Languages and Cultures of Latin-America ( and learned among others The Law of Monoculture. Cuba with its sugar, Central America and Brazil with coffee, dating back long ago. Today, Costa Rica is the top global producer of pineapples, Brazil is the main producer for ethanol

Of course everybody in those countries tried to run along as much as they could, even when the monoculture proved to be failing due to bad crops, harvest or sinking prices

Evangelisation does that. This is not as much a post "against" Agile as it is against evangelisation in general, beit IT or non-IT. The world is diverse, the world changes. We get wiser, because we fail. We gain insights, that lead to change. That change leads to new ideas

Or it doesn't, and you'll keep paroting 2,000 year old ideas ;-)

Stuart.Lynn said...

Hi Martijn,

I'm not sure from reading this that you actually get agile.. Whilst I agree its not for everything it can be a highly effective way to deliver software (and even commercial business) projects.

What it isn't is throw all control in the bin and fly by the seat of your pants... What it is is a model whereby accountability lies with the dev team and not some project manager miles away from reality of day to day decision making.

The controls are very adequate and persoanally I've used it on dev teams of 80 or so people.. Based around scrum of scrum hierarchy ... However, that said I also like a high level governance in place for really complex implementations.

This overview is really good, and just about says all you need to say.

Martijn Linssen said...

Thank you very much Stuart

I think I do get it. My beef with Agile is that it delivers projects, not products. Narrowing that down, I think Agile only delivers software builds - it is a very narrow-minded approach to the entire Application Life Cycle

we don't need to deliver projects in IT, we need to deliver perfect products: well described software that are traceable back to the business needs, ergo having a fully described functional requirement, same as technical design. From those documents, the testers can distill their test cases, and of course the product is fully prepared for transition into the operation and maintenance phase

You name project, dev, but not test, nor maintenance. Let me tell you something: I have been asking all Agile lovers whether they have experience with testing and / or maintaining products delivered through Agile projects, and the silence has been deafening

With regards to that, can you help me out? I don't care for projects, I care for products

Stuart Lynn said...

Aha... So I get where you are coming from... This is how I set up my teams

I have testers as part of a 6 person scrum team, normally to a ratio of 3 devs, 2 testers and a scrum master... However I also then have a separate system/integration test team that don't work as an agile team... I've found this to produce great results for larger complex products

As for maintenance I don't use agile for that either.. I have a separate sustained engineering team that are dedicated to respond to any field issues quickly and efficiently.

So as you can see I do see agile as being a good thing, but it's not for everything... and on that point I think we agree.

Post a Comment

Thank you for sharing your thoughts! Copy your comment before signing in...