Agile – Circa 1997

The Story of INControl

This is the (short) story of an Agile project delivered by Familiar Limited, circa 1997.

Note: There’s a document on my website that describes the approach we used to deliver our projects at that time, then called “Jerid” and subsequently evolved into “Javelin”. Of course, in 1997 the term “Agile software development” had not yet been invented.

“One of the most successful extranet application development projects in CWC history” – Project Sponsor

INControl was CWC’s major extranet application, which enabled all its corporate clients to manage their telephone call routing through the CWC Intelligent Network via a plain old web browser. This replaced their previous service which had involved long and error-prone telephone conversations, plus exchanges of faxes, between customers and CWC’s specialist call centre staff.

The INControl project had spent a long, long time in the Fuzzy Front End. The client – Cable & Wireless Communications –  agonised over both the idea and the proposed technologies (WebLogic, Java, J2EE, Swing, etc.). Sun Microsystems had sponsored a number of technology demonstrators in order to close the deal and sell the necessary tin and string.

Finally the client gave the go-ahead to commit development engineering resources to the project, so we called in the folks we had already lined up to do the engineering, architecting, designing, testing and sys admin-ing, and launched the first two-week time-box – or “cycle”, as we then called it.

We already had some information on the basic features of the project, and the client’s particular priorities. Internally selling the idea across CWC was important to the project sponsor, so we focussed the first cycle on producing a working model of the GUI, selecting a few key event types to implement first. We also took the opportunity to make a start on prioritising user stories and elaborating the first (highest-priority) ones, and scheduled the first of the monthly Risk Workshops.

Being the first cycle of the project we also knew, even before the Risk Workshop, that deliverables of the cycle would include some of the basic ‘contextual’ information – a name for the project, a Statement of Purpose, a Project Charter, a Case For Action and a Vision.

Each cycle, in what turned out to be a thirteen-cycle (i.e. 26-week) engagement, followed the same iterative Plan-Do-Check-Act pattern: Cycle planning on the morning of the first Monday, working according to the plan for the next ten days, and a cycle review (internal process retrospective) on the second Friday.

Each Monday morning the team would get together and plan out the deliverables, and interim work products, for the upcoming two weeks. The project sponsor provided input in terms of which user stories should take priority, and what he and the other CWC stakeholders wanted to see during the cycle, and at the end of the cycle.

The evolving Risk Parade (the main deliverable from each Risk Workshop) highlighted to us those areas where we should take special care, or schedule mitigating work items, and the results of the previous cycle’s Cycle Review (a.k.a. retrospective) reminded us of where we needed to act to improve the development process itself.

The core of each cycle planning session involved the team members identifying what work items were going to be needed to:

• deliver the chosen stories
• manage the risks
• improve the development process

and the team members also estimated how long they each would allocate to working on each of the consequent work items.

Delivery Rhythm

The  results of the first cycle were very well received by both the project sponsor and the various stakeholder constituencies within CWC, so much so in fact that a number of people within the client’s organisation volunteered to work closely with the development engineering team on elaborating the requirements (iteratively) for the project as we moved forward. We would have promoted this first ‘release’ into production, but were waiting for the delivery and commissioning of the necessary server hardware and infrastructure (a joint Sun-CWC responsibility and outside the remit of the development engineering team).

In cycle 4 we booked the Madjeski Stadium Directors Box to present the first fully-functioning end-to-end release of the application to an audience of all the major stakeholders. The day was a great success, with senior CWC management pushing for a live system as soon as possible. Again, we could have released the system into production there and then, had the necessary infrastructure and client release / acceptance test procedures permitted.

Further cycles added further event types and lesser routing options, along with documentation and some minor performance tweaks.

Improving Along the Way

Some of the process improvements we introduced through the course of the project included:

• a mini feature-schedule to help coordinate the work of the various engineers within a given cycle
• a daily stand-up to help coordination further
• work items being specified by their down-stream consumers (as opposed to how we started out, with the producer of a work item outlining the specification)
• a collection of patterns to encapsulate and share common working practises – such as “FiveLinesOfCode”, “ConstantStateOfShip”, “CommonFrameOfReference”, “QualityGates” and so on.

Into Production – Better Late Than Never

Finally, with the commissioning of the production infrastructure in sight at last, the focus of our final couple of cycles shifted to getting ready to deploy the product into live production.

Some three months after the end of the first thirteen cycles, the client’s customers had received the new service so well that CWC commissioned another couple of cycles to add some more features into the product, and we were able to assess the quality of the system in production. The system had run live and uninterrupted 18×7 for over three months, with only three minor defects reported in that time.

As CWC themselves said of this feat:

“this was one of the most successful extranet application development projects we have ever seen”.

Ironically, one lesson we learned was that it could have been even more successful had we had responsibility for the commissioning of the production infrastructure too.

C’est la vie!

– Bob