What is the problem?
The key question is, can this only be done once a complete, operational solution is available? If it can, then a Hardening Iteration is necessary. If not, then not, and you should really be thinking about how you will move what you are doing now back into the development iterations.
Here is an interpretation, grounded in real Agile basics. A Hardening Iteration is needed only for tasks that cannot be performed as a standard part of implementing and accepting a story. If a task can be associated with a story, then it should be performed in the Iteration that implements that story. If it can’t, then there’s a case for a Hardening Iteration.
What is the solution?
Let’s begin by assuming that even the largest programme should have an epic-like structure. That is, the programme has an identifiable overarching purpose that can be stated in a story-like manner. For example:
As a business process owner, I want to enter this new market so that the company can fulfil its strategy.
As CEO, I want to merge corporation ABC with corporation XYZ, so that our shareholders are satisfied.
As a car owner, I want to have a car with one-tenth of current emissions, so that I will not have to choose between my lifestyle and the environment.
As a general, I want a cyberwar capability so that my country is not exposed to emerging electronic threats.
And so on.
In order to be managed by Agile methods, epics like these need to be divided into more manageable stories. These can be delivered as discrete units of value, usually in small batches at the end of each iteration but possibly independently, as and when each story is completed.
Stories usually consist not only of code (which often is pretty useless on its own) but also the materials, resources and other elements needed to realise the story’s full value. After all, most modern software development is part of a larger process of change management, which typically includes user training, organisational design, changes to static data, processes and technology, and so on.
Now, looking back at the list of candidates for a Hardening Iteration, how many of them would not have to be completed for each story as it was implemented? If the capability each story represents is truly to go live, then almost all of the activities that a brief trawl of perfectly respectable Agile websites suggests for a Hardening Iteration need to be finished during their original Iteration. In fact, most will be finished before their respective stories get to ‘done’.
After all, how many of these would any stakeholder – or responsible developer – want to leave undone when a story goes live?
- Preparing user documentation.
- Systems, acceptance and field testing.
- Regulatory, compliance and executive approvals.
- Transition planning.
- Planning and rehearsing deployment.
- Data creation, setup and population.
- Reviewing and finalising documentation.
- Setting up operational controls and support.
- User and management training.
- Stakeholder briefings.
What about completing the epic itself?
This still leaves the possibility that the release (or programme, etc.) has to be finished off in some sense that goes beyond the implementation of individual stories. That is certainly what many of the items that find their way onto lists of candidates for a Hardening Iteration imply.
For example, as the many stories that fill up the release backlog are implemented, isn’t there a final phase in which they are all knitted together, verified, approved by the various necessary authorities and finally deployed?
There are two possibilities here:
- If this final task of Epic-level integration can be expressed in the form of a story in its own right then, even if it is a final end-to-end story, it should, like any other story, be implemented in the course of a standard implementation Iteration.
- The fact that the story is final does not change this fact.
- Nor is even a final story likely to be especially large or complex. Often it will simply pull together the other stories the release has already implemented.
- So it is not a candidate for a Hardening Iteration.
- Alternatively, it could be that there is no Epic-level story. In that case, there is no final ‘pulling together’ to be done.
So the case for a Hardening Iteration can’t be based on the sheer magnitude and complexity of the epic from which work began or the need for a hypothetical final integration. One way or another, everything an epic demands belongs somewhere else.
What, if anything, does that leave?
If there are any candidates for a Hardening Iteration, plainly they must be looked for somewhere else. Given that the focus of stories is the value they give to customers, users and stakeholders, the obvious candidates are the tasks that these groups are seldom, if ever aware of, but which need to be done anyway. In other words, the Hardening Iteration represents the tidying up after the curtain comes down and the audience goes home.
But as any critic of Hardening Iterations will certainly point out, all flavours of Agile are clear that these are all tasks that should be factored into the normal development cycle – which is to say, into ordinary implementation iterations.
If there is a case for using a special Hardening Iteration for these sorts of task, it may well be solely for one of a few rather weak and regrettable reasons:
- Because of cultural and political realities that haunt Agile every bit as much as waterfall: the pressure to deliver will be allowed to overcome the importance of producing a high-quality, high-value deliverable.
- Because, despite the ambitions (and remarkable achievements) of Agile, its practitioners are human, and even the very finest of achievements will be accompanied by a trail of small errors and omissions – all of which need to be cleared up before they begin again.
- Because Agile is driven by thousands of last minute, ‘just-in-time’, ‘barely-enough’ choices and decisions, some of which will come back to haunt the team and the organisation as a whole. They need to be addressed somewhere, and the Hardening Iteration seems like a place for them too.
This isn’t the most persuasive of cases. After all:
- Aren’t many of these things candidates not for a Hardening Iteration but for new stories in the backlog? Why do they need an iteration of their own?
- Much of the effort will be hard to attribute to any particular story, so this arrangement makes a nonsense of your Burn Charts, your apparent velocity and your estimating techniques, all of which turn out to be at least partially fictional.
- By allowing an Iteration to be added to deal with this type of problem, the Agile practitioner is simply giving into precisely the kind of culture to which Agile is fundamentally opposed and for which it was meant to be the cure.
The preceding argument is not either for or against Hardening Iterations – it is not, despite how it is presented, ‘the solution’. It only suggests that Agile planners should look very carefully at what they expect their Hardening Iterations to do – and whether they are not in fact doing precisely as the opponents of Hardening Iterations say, namely using them to do things that should have been done during ordinary Iterations.
As the above analysis suggests, there is a case for the Hardening Iteration, but it probably isn’t the one many of its defenders seem to recognise.