A colleague of mine is involved in a project to modify an existing application that our team are responsible for. For those of you that follow this Blog, the scenario is a familiar one: The application isn’t very well understood, yet it is live and in use. Meanwhile the team that built it have long since moved on and the business area in question has restructured with many people leaving and joining. Oh, and there are the inevitable challenges of budget and timescales.

One of the biggest challenges has been – apparently – getting the developers engaged, given that at the beginning there was a fairly sketchy set of requirements and obviously a sketchy level of understanding about the ‘as is’ situation. So the first step was, quite rightly, to assemble a level of understanding of what is currently there. This of course, requires developer involvement.

“How do you expect us to produce engineering estimates for this?” Came the cry.

And therein lies the problem. Development isn’t always about forward-engineering a solution. It isn’t just about building new features. It’s great if it is, but sometimes development is about untangling what we already have, or reverse-engineering what others have left us. Thats the reality. It might not be glamorous work and might not get you up on stage at an Agile conference, but thats’s life. These activities inform and shape what comes later.

In the meantime we could, I suppose, write a story like “as a user I want the system to work so that I can do stuff” but what’s the point? it doesn’t get us anywhere?

I’ve always taken the view that ‘Analysis in progress’ doesn’t just mean Business Analysis. Analysis can take many forms – It can equally mean technical analysis, or more accurately, a developer prowling round the code to find out what it is doing. The idea that you can start with an “engineering estimate” or even that you can start with “stories”, is nonsensical if this bedrock of knowledge, understanding and investigation isnt there.

My ‘Grand Designs‘ analogy is that if you watch the programme you’ll notice that the problematic building projects tend to be those where they are altering or renovating something that already exists because they are never too sure what they will uncover. Uncovering the unexpected and having the project go awry as a result doesn’t represent some massive conspiracy or wrongdoing, just life. Building something brand new on a plot of land is, on the other hand, oftern far easier and sometimes quicker. Furthermore, it is much simpler to describe how you want your brand-new purpose-built-from-scratch home to look, than to describe how your house conversion/renovation will look, since there might be many constraints and oddities around a conversion that can’t be altered. Not all of these will be known at the start so things may change after you’re underway.

IT is no different. Dealing with something that already exists, is often (if not usually) far more difficult to deal with than a brand-new development. It probably shouldn’t be, but there we are. Also, Agile is at it’s strongest when dealing with the ‘new’.

So, at the risk of repeating myself, the fact is that “Stories” and “Engineering estimates” and all the rest are often the product of the analysis. Not the input to it. Not everything is a new, “green field” development. We are often faced with “brown field” developments – which I suppose are good for the environment if nothing else….

« »