Sunday 22 February 2009

Thoughts about Agile Development

Not too many years ago RUP was the way to do things and now being agile is the latest "right way" to do things.

It all started with the The Agile Manifesto, which I think bears repeating:

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 items on the right,
we value items on the left more.



As principles go, this is a good one. In my experience it reflects how things are done in real working life - or at least how they should be done.

The important thing is not to ignore the last sentence: "while there is value in items on the right, we value items on the left more". In other words, the manifesto does not instruct to ignore practical processes, good enough documentation, proper contracts nor having a plan.

I used to work in a company that had taken the agile way and scrum in particular in to the heart. When I joined the company it was actually inspiring to see how not just the techies but the management and even the main customer made a real effort to learn and adapt to the scrum way of working. They were not just talking about it but also working on it. I do respect that.

Unfortunately it wasn't all good. Very few seemed to care about project documentation, because documenting things wasn't perceived as agile. Not true. What people might have been thinking was the old style waterfall process where everything was designed and documented up front any implementation work, but the alternative to that is not have documentation at all. Personally, I think it was just a convenient excuse for people being lazy and cut corners.

Neither was it very common to plan ahead since being agile was to do what was needed right then and there - in my mind to think this way is to be short-sighted. Unless the program in question is the ever-so-popular Hello World, rarely is an application complited in just a few iterations. Incremental iterations are step building towards hindmost goal so one must always be mindful about next couple of steps or the risk of major redesign and refactoring is likely to become an unfortunate fact. Now, surely that is not what agile way of working is supposed to be about?

When Product Owners and managers agreed on the priorities and geared up to get things done, it often became as a nasty surprise when Somebody Else managed to convince directors that their project was more important and should become a priority instead. This wasn't about "responding to change over following a plan", it was more about being without a direction. At one point a project might be a company top priority and then, without warning, be pushed aside and be replaced by another top priority project. I'm sure there were always seemingly good reasons for this, but how is it a good thing when projects go unfinished, professional employees get frustrated and nobody can rely on what was agreed?

Being agile should not be the same as being sloppy and erratic. It is a principle that promotes common sense over dogmatic thinking. About cutting the red tape, doing what needs to be done and getting it done in a professional manner.


No comments:

Post a Comment