0

Some little while back I was trying to facilitate a change in approach in one of the projects that I was supervising.  This project was quite simple: to configure two existing PDF forms into an existing forms processing/workflow tool.  But it had gotten caught up in the machinery of large enterprises: funding crises, changes in personnel, and ponderous project governance.

The project governance/lifecycle model at this organisation was a very old-fashioned multi-stage waterfall model which dictated certain documents to be produced in each stage.

Due to the “stop/start” nature of the project, an early stage in this process was being done stand-alone and stood out starkly as an exercise in pointless make-work; much more so than it might if it had been done within a continuous execution.  This stage produced the two documents (a Business Requirements Document and a Draft Solution Architecture Document) but their purpose was mostly to go back for approval for more money to develop yet more documents before we started actually doing a build.

So the Project Manager (PM) and I decided to try to deliver something more valuable to the customer (an internal department).  We wanted to reach into the agile bucket of techniques and put together a team approach that got some real software developed and used agile constructs to tie the activities together.  Instead of 2 documents we planned to produce at least one of the forms, together with cut-down, “fit for purpose” documentation of the key requirements and solution design.

We had been given a rough estimate by the development team of about 8 days’ work, but the developer only was available for 1 day per week.

Rather than wait, we wanted to get a move on so we decided to try a part-time agile approach.  The PM went to the business and outlined the approach, but made it dependent on the availability of a suitable person to act as a “Product Owner” (PO) to represent the interests of the business.  The PO would co-locate with the developer 1 day a week.

I half thought that the idea would die at that point, and that the business would not want to appoint someone as dedicated and co-located.  I was pleasantly proven wrong when they responded with great enthusiasm and agreed immediately to providing the “PO”.

We defined a series of 8 or so weekly “cycles” during which the work would be done.  I hesitated to call them “sprints”, but they had all the characteristics of sprints without the names.  The developer’s one day a week availability would be consumed in one single day block, which we called “dev day”.  The rest of the week would be for user testing and demonstration / feedback with a broader business teams.

The week was planned like this:

  • On a Monday:
    • review the results of user interaction with the existing product (we had done a POC some months back which would be what we reviewed in week 1);
    • plan out the work for the coming week: since this was a forms development project it is mainly which fields to implement, and what feedback to use to tweak the form;
  • On the “dev day” the “PO” and the dev would make whatever changes had been planned;
  • the rest of the week was other members of the team looking at the Work In Progress (WIP) and providing feedback;
  • we considered doing a Friday demo, but this seemed like overhead given our Monday review – with the number of people involved and an intervening weekend, we thought it would be wasted effort.

We called this the “agile approach” (lower case deliberate) in our discussions with stakeholders, but despite our intentions, the weekly iterations became know as “sprints”.

Apart from the “dev day” everything was part time and done in and around other tasks.  Most participants in these project activities were business folks and in particular the representatives of the people who would be using the forms “for real” in the field.  But, the main objective was to deliver “working software” i.e. a form or two at the end of this phase, instead of 2 documents.

Everyone was happy, especially our customer.  Everyone was ready to start until my Project Manager met with the overall manager of the software development department, as a courtesy to explain what we were doing.

i was surprised to hear my PM tell me that this manager had flat-out rejected the “agile approach”: “that’s not agile” s/he said and refused to support the arrangement.

To be fair when I met with this person to clear up the issue, s/he said that they would provide the developer, but said “You can call it ‘incremental development’ or whatever.  Just don’t call it ‘agile'”.

I later discovered that this department and its senior manager had decided that it was their role to introduce an “agile” rapid delivery approach to the organisation.  So they had appropriated the use of the term “agile” to their own program and apparently did not want other teams using the word.

I was frustrated with the process but confident in our work. The “agile approach” was definitely custom-created to our specific requirements but it was also demonstrably and clearly an “agile” approach.

We implemented all the relevant principles in the Agile Manifesto, and serviced the Manifesto values.  We didn’t contravene or ignore anything defined in the manifesto. Even more, it was proving itself in the early stages: the team bound together quickly just through the discussion and planning on how we were going to do it.

What’s the takeaway? Sometimes it doesn’t matter how sensible or appropriate an initiative might be.  if it crosses over the perceived boundaries or plans of more powerful stakeholder groups than it’s unlikely to survive.  Sometimes all it has to impact is a name, and that’s enough.

It also reframes the question “what is agile”?  if what we were doing wasn’t agile, then what is?  More on this to come.