Agile Program Management: The Significance of Hardening Sprints

This is my ninth post in “Agile Program Management” series.  Hardening Sprint is a familiar term for most practitioners. However it is a frequently misunderstood term too. Typically an iteration or Sprint that is at the end of all Sprints in a release cycle is planned in such a way that team members focus on (and only on) hardening activities. When this is true, we call it a hardening Sprint.

In one of my earlier posts I discussed about how procrastination makes Hardening Sprints harder. 

Agile Program Management is a complex function as it involves program managing multiple related projects. Not understanding the significance of hardening Sprints can lead to

1. Incorrect decisions or expectations on accommodating new features in hardening Sprints,
2. Delays in release timelines because of unexpected issues in one or more applications or products in spite of (or due to) hardening activities
3. Procrastination and last minute surprises that indicate risks related to product or application quality

For this, those who are involved in Agile Program Management function need to understand what constitutes a hardening Sprint. Also they must establish a common understanding on what constitutes a hardening Sprint across project teams.  

For example, SAFe suggests HIP Sprints. HIP stands for Hardening, Innovation and Planning.  

Hardening Sprints are to stabilize code or to meet release level ‘Definition of Done’.

Hardening Sprints are not to be seen as an opportunity to ‘relax’ or ‘dilute’ the ‘Definition of Done’ at user story level or Sprint level in all previous Sprints with a misunderstanding that all those can be accumulated as technical debt and paid off during Hardening Sprints. When this happens we miss the essence of Agile.  This approach defies demos or reviews and retrospectives.  This does not lead to delivering 'potentially shippable' increments or user stories at the end of Sprints.

Also, feature implementation or enhancements (new user stories) are not part of hardening Sprints.When Agile Program Management teams understand these, they develop the capabilities to ask powerful questions when they look at release plans or when they govern the progress of Sprints.  Besides, when things go wrong during Hardening Sprints, they do have enough awareness to deal with the situation and demonstrate their value to teams.

Hardening Sprints do not add much to the overall productivity or velocity of the team in terms of their ability to deliver new features. In other words, the quantum of efforts spent in Hardening Sprints do not add new features and corresponding Story Points to an upcoming release. Hardening Sprints improve the stability and maintainability of releases, and ensure that that code base is good to launch a release.

To conclude, let me put forward some questions. When you review a release plan and find that there is no hardening Sprint, what are you going to do about it?  Also, when an hardening Sprint is approaching in your release road map, what kind of questions will you ask to figure out if your teams are moving in the right direction?  When there is business pressure to accommodate all product backlog items very tightly into multiple Sprints and deliver releases, how will you negotiate to budget for a hardening Sprint per release? 

Agile Program Management: Dependency and Risk Management

From Agile Program Management perspective how do you manage dependencies and risks?  Do you identify what is under your control and manage those alone? Do you assume risks – do you assume that risks will be taken care of by those who have full control on the risks? Or do you consider those as part of your action plan? This is what I plan to discuss in this post.

There are ways to identify and handle dependencies in projects. I had discussed this in one of my previous posts. Also, agile methods have inbuilt mechanisms to manage dependencies and risks such as Release Planning, Sprint Planning, Scrum-of-Scrums, Agile Governance etc.,- provided these mechanisms operate in an orchestrated manner.  Does it happen on the ground across all projects and situations? Well, it depends!  In the name of ‘Inspect and Adapt’ some Agile teams succumb to the ill effects of poorly managed dependencies and risks. And of course, they retrospect, learn and improve. Or they fall in to the same traps again and again.

When it comes to Agile Program Management that involves multiple interrelated projects, the dimension of dependency and risk management becomes even more critical. In one of the programs I was part of we had a good grip on internal dependencies and risks. Those were the elements on which we had full influence or control to steer them in the right direction or implement mitigation plans to reduce the overall impact. However, we had external dependencies and risks too. Those were the elements on which we had either partial or no control to steer them in the right direction.  One of them was about a dependency on a third party products. These products were evolving and the corresponding vendors had announced dates for the next releases.  The products got released and as you may guess they were not stable enough because of defects and performance issues. The host of applications that we were building were being built on one or more of these products. Now you can guess the impact!

We had multiple releases to go and more or less all these releases had dependency on the enhancements and upgrades of these third party products – these products had a release road-map with multiple releases too. If we assume that everything will go according to the release road-map, it is a risk. If we become paranoid it is unhealthy and risky again. Collaboration and continuous planning is what helps in such situations.

Classical program managers resort to assuming certain entry and exit criteria. For example, ‘Let us assume that the 3.1.2 release of the product from our third party vendor will be ready on 10/23.’  Is that a good assumption? Or is that assumption itself is a risk? Or should the assumption be collaboratively vetted or validated at regular intervals?  Who is responsible for this?  Agile Program Management is. This is because, individual project teams are busy moving from one iteration to the other. Scrum of Scrums happen in large projects. Project teams sometimes become too busy to pursue these. Either implicitly or explicitly they call it out or call for support. Coach them to make it explicit so that the program management team is aware. That is what I would recommend. And make it explicit at all appropriate levels and own it as part of Agile Program Management.  This is true for all kinds of dependencies and risks – both internal and external.   Program Management team needs to be at the eye of the storm in such situations and have a clear focus on how to manage situations. Else, they become an extended arm of project teams and remain equally clueless. They lose focus and become inadequate to arrive at optimal solutions or pragmatic decisions.

It is about seeing the forest but not losing sight on trees!