Agile pit-falls

I was having a conversation with a colleague the other day who is currently learning the ways of “Agile” after being a Delivery Manager for many years. While we were talking, I had remembered some of the issues I’d seen over the years trying to do “Agile”, and I’d brought them up as potential pit-falls when adopting the new methodology. I figured it was time to put the thoughts together on “paper” and so here I am…

Let me start

Let me say up front, I am an advocate of Agile in that I went out, learnt, practiced and got certified in Scrum. I’ve also worked alongside and in teams practicing XP. I have also introduced and worked on introducing it to teams. I have a few years experience delivering projects under Scrum.

A major point of Scrum is the fact that it is driven by the idea that it is only of use to you if it adds value to your process, whatever that value is. In fact it is worth looking at why you want to go Agile in the first place, it might be it does no good for you. Assuming that you have decided to go “Agile”, with a possible reason being the lure of better transparency in product design and decision making and more rapid reaction to a dynamic environment, you could adopt Scrum/XP/other. Another point is that you can then “institutionalise” your approach to fit with your company. After all no company is the same as another, despite some popular conceptions about “big business”. Let me be clear, there is change to be made within your company whenever you take up a new process, but that process has to add value by adding to your company, and your staff.

So having done something in this vein, in running and adopting and feeding into Agile processes, there are a number of areas that I had trouble with and found not to be adequately covered by the “Agile” practices:

1. Agile seems to be an extension of the RAD era.

2. Starting projects is Difficult.

3. It’s a bit beyond you if you are a newbie

4. A project is not the world.

So let me go through this:

1. Agile seems to be an extension of the RAD era

Ah, remember that ? The time when RAD tools ruled the roost and applications were built with a few clicks of the mouse and VBA was the new grail ?

No ?

Ok, that’s me being a little facetious; however there is a serious point. RAD tools allowed us to build UIs and noddy applications really quickly by gluing together a load of pre-built components. This meant that the idea of having a working application up and running in a day became realistic without having the developer creating all the mind-numbing framework code, OS hooks, re-compilation steps and so on.

People working in the current Java EE world will recognise the benefit of using some form of IDE based Model Driven Development that creates all the interfaces, builds the deployment descriptors, handles the configuration and builds all the resources for you. You’d never want to build it all by hand, it’s merely tedious work that various little between JEE projects and is a bit of a waste of an expensive developer.

So why is this a problem ? Well, if you step outside the JEE/.Net/Ruby on Rails type domains, IDE and MDD style support is not so readily available. This means that creating applications in these domains is not quite as straightforward in some of these areas and that having a working application in a day is out of the question. Not always the case, but if you are in embedded systems, you may recognise the problems. What about legacy integration ?

In summary, not everything has the same benefits, and you need to realise that the mantra of “releasable working application at the end of the iteration” is not as easy to attain in every environment.

2. Starting Projects is Difficult

Well that’s fairly obvious. Prince 2 defines a set of things you should fulfil to start-up a project, but that’s not always clear-cut. As an exercise it varies in every organisation at every level and with every regulatory scheme.

So why mention it here. Well, starting an Agile project is a bit of a strange exercise. You assemble your team, presumably you have all the stakeholders and they are to be available/co-located etc. Then you start coding.

Well no. You don’t, you need some form of requirements which you need before you start. Then you need a goal. This might be temporary. Then some estimation… possibly some analysis (“sorry, the telepathy add-on may take some time…”). Someone might need to get some new equipment.

There is a lot of setup that is needed it appears, yet, people like to “dive-in” and get on with it. Which is great so long as it is not…

3. Beyond you if you are a newbie

If you have been in the industry for 20 years, you know how this works, or more importantly you understand how it should work to achieve particular goals. Now try picturing James coming into your workplace.

James has come out of a good/bad/indifferent University/Vocational Training/other. He has knowledge but little experience, and his knowledge does not take into account real world working or having to deliver a project within a corporate environment. All those assumptions and nuances that people with long term experience have do not apply, he’s still working towards it.

So here’s the thing, all those things people take for granted, take them out of your heads and write them down. Wikis are great for this.

4. A Project is Not the World

So you have your project, you’ve written down what you expect, and you do the various things to start it up and get people together.

You managed to finish and deliver your product. It’s really nice and shiny. People like it. Some people like it so much, they’d like a new version. Some are awkward and would prefer that annoying focus stealing behaviour didn’t happen. Others would like it to work with their latest widget.

Guess the project didn’t finish did it ? But it did. The staff went away, did exciting new things, new people joined, the old ones left, got promoted, sold their options, whatever.

Support didn’t stop. People bought your product and expected help when the CD-ROM kept ejecting because you pressed the “Import” button. So people were found who man the phones.

Now you need someone to go and start it up again, fix things, find out how it worked, and generally get back into that old frame of mind.

Despite most peoples hopes about projects, I’m more then willing to bet the latter is generally the case for most projects.

It would be nice to say all projects are neatly defined short lifetime exercises, but often then not, they aren’t. They linger, they merge, they bump up against other things.

Basically a project is more like a part of a continuous stream of consciousness that is your company. Your process needs to reflect this.

Um, and this means…

Agility only makes sense if you know what you want to improve in your current system, it doesn’t come with career development or support or fancy tools. That is the hard bit that you’ll have to put in yourself.

Advertisements

One response to “Agile pit-falls

  1. Pingback: Code Complete « Content Negotiable

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s