Hardening Iteration

Hardening Iteration2018-07-11T00:00:17+00:00

The term ‘Hardening Iteration’ (or ‘Hardening Sprint’ or ‘Stabilisation Iteration’) refers to the practice of adding one (or more) Iterations to the end of a Release Plan, to deal with tasks and issues that ‘cannot’ (its supporters say) be dealt with during ordinary development Iterations.

The controversy

In the Agile community, the concept of a Hardening Iteration is controversial.

  • To some it is an inevitable effect of working on large, complex programmes of the kind Agile seldom had to face when it was coming into existence. For these, Agile purists simply haven’t come to terms with the facts of programme life.
  • To others, Hardening Iterations are evidence that you aren’t really Agile at all: there’s nothing that’s supposed to be done during a so-called ‘hardening’ Iteration that could – or  should – not have already been done in an ordinary development Iteration. From this point of view, a Hardening Iteration is simply an excuse for hanging on to the final remnants of waterfall development.

In many ways it’s like the conflicting views on Iteration 0: is this a reflection of complexities the original flavours of Agile failed to take into account, or is it evidence of failure to implement Agile effectively?

And as with Iteration 0, it’s easy to sympathise with both side. Broadly speaking:

  • There are aspects of large-scale development that really do not seem to fit into the standard Agile framework.
  • All too often ‘hardening’ Iterations conceal things that really should have been done during development.

Candidates for a Hardening Iteration

It is probably not a major problem to allow both Iteration 0 and Hardening Iterations for a while after Agile adoption begins. Beyond that, however, supporters of Hardening Iterations have no difficulty in identifying tasks that really do seem to call out for a distinct Hardening Iteration.

For example:

  • Completing change management tasks such as training users and management.
  • Integrating with third-party, customer and other external components.
  • End-to-end testing:
    • Systems.
    • User acceptance.
    • Operational acceptance.
  • Field testing.
  • Preparing deployment and installation materials.
  • Final validation against:
    • Regulatory and compliance requirements.
    • Quality standards.
    • Sales and marketing requirements.
  • Create and implement deployment plan, package and communications.
  • Final business and executive approval and authorisation.

In practice, Hardening Iterations are also used for a lot of other, much more doubtful tasks:

  • Fixing remaining P1 defects.
  • Systems integration.
  • Exploratory testing.
  • Regression testing.
  • Localisation (language, regulatory differences, etc.).
  • Preparing user and support documentation.
  • Automating manual tests.
  • Dealing with technical debt.

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.
  • Localisation.
  • Systems, acceptance and field testing.
  • Regulatory, compliance and executive approvals.
  • Transition planning.
  • Planning and rehearsing deployment.
  • Data creation, setup and population.
  • Pilots.
  • 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?

Probably not.

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.

For example:

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.

Conclusion

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.

Leave A Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Toggle Sliding Bar Area
Want to do more than just build systems?