Introducing the “Nimble” Software Methodology

Software, Technology October 30th, 2011

I had a comment from someone on a previous rant about the term agile, and it has spurred me on to tell you all about my first encounter with nimble software processes.

In my first job out of Uni I was working on a client site in another country on a project where the delivery date was set based on the owner’s birthday. So I probably should have run a mile based on that alone. But it was new and exciting and I didn’t know what to expect from the real world so I worked my 6 day weeks with 3 hour commute each day. We had a team with an experienced lead and 5 grads straight out of Uni, and the work environment was very unsettled (figuratively and literally, they were building the building around us). We were keen to employ some of the things we’d learned at Uni so we approached our team lead and said:

“The client is changing their mind all the time, instead of just hacking on code each time they do this we should employ some sort of agile process to manage it”.

To which he replied:

“Process is for stupid people, it’s for people who can’t manage themselves. We’re better than Agile, we’re … Nimble.”

And from that day forward any time someone has said they use a process when they are clearly using no process at all, or only the bits that mean they have to do less work, I have labelled them as using a Nimble methodology.

One Response to “Introducing the “Nimble” Software Methodology”

  1. Andy Says:

    I remember a particularly ‘nimble’ project I was part of once, but in my case it was the upper management who didn’t care much for process. The development team however, were eagerly trying to do it right. I remember being with the QA manager and project manager for a week working out the development schedule, using our use cases through function point analysis. It worked quite well and we calculated that the project was to take some 4 – 5 years (it was dependent on people’s experience level and numbers). The project manager said that 4 years was too long a time and would never be accepted by the board, so I said we could reduce the functionality for the first delivery to the most important features and then add more functionality after the first delivery. This was agreed and using a reduced feature set we recalculated the schedule to 1.5 – 2 years for the live delivery. A couple of days later after the project manager had presented the schedule to the IT Director she told us that the IT Director had rejected the schedule – I went to see him asking why, and he said “because we have already agreed with the client to deliver the full system in 6 months”. Of course I let him know what he should now expect that he was driving an unrealistic schedule. I left the company a couple of (horrendous) years after that discussion – needless to say the project did not make the first delivery date, nor the second, or third. I met up with one of my ex-colleagues who was still working on the project, it was now well over 5 years from project start, where he informed me that the system had only just gone live and was riddled with problems. We both just laughed when I said that’s just what I told the IT Director would happen.

    The project nevertheless was nimble, not because of changing requirements, but because no one had time to think things through – just code like hell. So it frolicked happily from one deadline to the next without a care in the world, like a new born lamb in spring.

Leave a Reply