How we survived WAgile

There is much to be gained from the literature and assimilation into development of well defined religions of software development; Kanban, Scrum, the much maligned Waterfall etc.

I have often experienced a certain frustration when coming up with an idea for a change in our development process, only to be told. “Oh yes, that was written about by Misters Heretic and Homily in their book on “The finer logistics of the Developer’s brain and how to find it.”

But how much is it acceptable to take these things and make them your own or even more controversially, mix and match the 8-fold paths to enlightenment?

Jason Gorman wrote a brilliant little piece on the perils of the WAgile Software Development Life Cycle:  in which he describes how the Waterfall-Agile process is destined to fail.

“WAgile” includes such gems of practice such as the “arbitrary estimate of velocity selected after actual velocity is rejected because it is not fast enough to meet the release deadline” and encourages a “rapidly growing technical debt that product owner will never schedule”.

But reality bites. Usually it bites chunks out of idealism. And this is no less true for the religion of software development than it is for religious idealism in general.

Our Waterfall Project

So how did we, an Agile team using SCRUM, cope when the business presented us with a Waterfall project?

We were given a long list of items, agreed at contract. A couple of conference calls worth of technical refinement later and there was no getting away from the fact that we had in our hands a requirements document. To add to this, the business had been forced to agree to a hard deadline for the project without any estimation from the technical team. The hairs on the back of our Agile necks didn’t just rise, they turned grey and fell out.

We decided on a mix and match approach which entailed continuing to use SCRUM as our internal development process, but to make allowances in order to manage the situation.

We sat down and split the required work into logical areas according to which component they affected. Although no official “user stories” were written, header cards were written describing units of required functionality.

Each functional change was estimated. Estimates were then analysed in order to check whether the defined deadline was achievable. Where the deadline was deemed under pressure scope was narrowed and redefined in order to keep timescales workable.

Classical two-week Sprints were adhered to, including sign-up sessions and fortnightly retrospectives. Wherever possible a Sprint contained a discreet unit of functional addition or the completion of work on a discrete component. Careful tracking of velocity was used in order to ensure that the deadline was still achievable. The frequent retrospectives fed back into this cycle to ensure that problems were recognised early and actions taken.

Instead of providing the customer with iterative releases as Sprints proceeded we supplied them with each component as work on that functional unit was completed. This allowed for customer feedback and furthered customer satisfaction by allowing them to see that work was being done. It also allowed the customer to test each component as we delivered it, which meant any bugs could be fixed.

Close Customer-Developer interaction was encouraged so that technical problems/requirements queries could be handled quickly and worked on correctly the first time around. This also meant that we could check that all parties were in agreement.

Result!

Something else that became clear as the project progressed was that although team members were at times moderately stressed, the immovable deadline was having by and large a positive effect on velocity. The key to this seemed to be in the approaching of the time frame as a challenge rather than something which was resented. While it is accepted that an overworked team will suffer both in respect to the quality of their work and the velocity, our team, which was experiencing a fair amount of pressure actually worked more accurately and faster than a similar team who faced no external deadline pressures.

The project was delivered on time, to a satisfied customer three months later. We had survived the WAgile experiment, with a managed amount of technical debt and reasonably intact nerve endings. While I wouldn’t rush to advocate this as a normal approach to work and I think that we benefited enormously by the project being reasonably short, this proved to us that it is possible to mix one’s methodology.