Archive

Archive for September, 2013

How we did non-Agile Agile

September 13, 2013 Leave a comment

From time to time there is a debate about Waterfall versus Agile development, and why one is superior to the other. In practice the situation where one or other clearly works best does not always occur in the real world, as I found recently while delivering a major project for a large infrastructure company. A regulatory change meant a new database was needed to accept a feed from a new data source, which resulted in significant changes to their existing billing system to allow it to read the new data.

The situation we started in, ordinarily, would have lent itself perfectly to Agile:

  • At the outset, there was a large set of unknown requirements, but the uncertainty was around the detail – the big picture was clear;
  • the priority of requirements was not known at the outset, and varied over time;
  • the deadline (set by the regulator) was immoveable;
  • we needed something in place early to test with externally sourced data;
  • our team size was about right (8-10 for most of the project duration, although it peaked at 15);
  • the core team had been working together for some time so an established team dynamic already existed.

But certain other factors ruled Agile out:

  • lack of business user availability to work alongside the development team;
  • a mandatory client waterfall methodology had to be followed, heavy in documentation;
  • the client was genuinely scared of Agile, and it was officially out of the question. (The client had previously had its fingers burnt by an Agile project that had spent millions and delivered nothing).

As the programme manager put it, we couldn’t do waterfall because we would deliver a year late, and we couldn’t do Agile because it was forbidden.

So what do you do when you can’t use either approach?

We adopted a hybrid approach to gain some of the benefits of agile while remaining within the Waterfall constraints set by the client. Basically, we made it as agile as we could get away with while seeming (to the outside) to be following the approved methodology.

The client process defined certain deliverable documents at key points, before we could proceed to the next stage. The most critical ones were a requirements specification and a design document.

We were able to produce an adequate requirements specification as the high-level requirements were known, even though many of the key business rules were flagged as still being subject to agreement. It helped that many of the requirements were already met by the existing system, making the requirements appear more complete than they really were.

It then became a straightforward task to produce a high-level design document showing how all the requirements were going to be met, defining interfaces etc. Much of this design work would have been needed up front, even on a pure Agile project. It was clearly understood that the requirements (and therefore the design) would change during the course of development, so we would not have any difficulty presenting a substantially different final design document at project close if that turned out to be necessary.

Once the design was signed off, we adopted a different approach to the development phase. A series of short iterative waterfall cycles covered all stages from development to system test. A relentless focus on priorities ensured all essential functionality required from day 1 was completed first. We developed something as quickly as possible that worked, crudely at first, then adding more functionality with each iteration but allowing scope to vary as priorities changed. I will cover how we planned our development iterations in a further post. Finally as we approached the initial planned production release date, we reverted to a more recognisable waterfall cycle for final FAT and UAT.

We then planned further cycles after the deadline to deliver less critical functionality followed in subsequent deliveries every few months, following the same approach taking the next most urgent set of requirements in priority order. Not quite Waterfall, certainly not Agile – how about Nimble?

Advertisements
Categories: Work

The intervention of real life

September 11, 2013 Comments off

A year has passed since my last post.

This was not intentional, but was a reflection of an extremely busy period at work combined with family problems which together used up all my spare time. Both have now come to an end and I have some material in preparation.

Categories: Personal