You are here

Potentially releasable does NOT mean released!

Any Scrum teams primary objective is to deliver potentially releasable software at regular intervals. The key here is potentially releasable, NOT released. A release costs time and costs money. If we don’t need to do it, then we shouldn’t. Not needn’t, shouldn’t! Conversely, when we need to release, we should be able to.

The view that we don’t need a release plan because we are building releasable software is the root of this and must be quashed as soon as it rears it’s ugly head. The expectation that we will release all potentially releasable software after each and every iteration, doesn’t help either, and is something that needs to be very carefully managed. On top of this is the general misconception that because the software is complete and should not have to be touched again, it is/has been released. This expectation is more prevalent outside of the Scrum team especially with those on the peripherals of the project, but is also the case with new Scrum teams. All too often I have seen ‘...... feature released to live’ as acceptance criteria. This normally sets you up for failure. Avoid this type of thing at all costs.

On top of this is the fact that teams new to Scrum/Agile have a lot to get under their belt and there is normally a large engineering overhead in the initial iterations of their first project. The is almost guaranteed to be some significant technical debt, no matter how good and great the department is, project level is where the cracks are. Making sure that the software that has been built is clean and complete and stands on it’s own while not breaking existing software, both on the current project as well as the balance of the organisation is a large task. An earlier blog goes into this in a little more detail.

Whether a release is handled by the team building the software, or by an external team or department, there is always an overhead on the scrum team. A few of the larger items are detailed below. Some of these are more crucial in high quality environments, others for internal systems, but they all have some impact across the board.

A few of the things often forgotten/ignored are:

Final Review: This is important in quality critical environments, but also apply in the majority of environments. After have you ever written software where quality is not important? Here you would normally review things like Technical Design as well as any Verification or Validation that may need finalising, as well as all the normal governance gumph that is required for a release. If this is a stage/phase end for those Prince2’ers out there, think long and hard about what it is you are producing. Is it valuable, relevant and useful? If you can’t honestly answer yes to all 3 questions, then you need to do your utmost to pare it down to become valuable, relevant and useful, or cut it out completely.

Installation/Release to Release testing environment: The overhead of this s something that should be planned into the iteration. For experienced teams it is one of those things that ‘simply happens’ . The amount of valuable work the team commits to in an iteration also containing a release is reduced. For new teams, it is worthwhile adding a story to the sprint backlog, it after all belongs to the team, to make sure that it is visible, accounted for, and in the forefront of everybody’s mind. This way it can get treated like any other piece of work the team commits to. It can be planned, accepted tasked out , completed and expectations can be managed.

Release testing: Yes even though each story has been tested in isolation and passed all the system and regression tests, you are still likely to need some form of user release testing. We all know that the testing the user is going to perform should be covered by automated test, but in the early stages of team maturity this is unlikely to be true. Another hurdle that needs to be overcome is being able to prove to the user community that the automated testing is more efficient and effective and provided better cover than any testing they do. All in all though, it is rare that users will be happy with a release unless they have ‘touched’ it.

Final Defect review: The simple act of making sure that the impact of any known issues/defects are known takes time. The organisation is also likely to be behind the team in their understanding of scrum and will have expectations that need to be managed. The most common one being, the expectation that any requested feature-set is complete. Somehow the fact that there is a backlog of prioritised work escapes them. Agreed this is something that they should be aware of and should have been covered in training but still comes up time and again.

Release to live: Surely this is simply a repeat of the release to the testing environment? In some cases it could be, but in the majority of the time, it is not be the case . This is particularly a problem where one team looks after installation on the testing environment and another looks after the live systems. Having an exact replica of a ‘live’ environment dedicated to release testing is expensive and rarely practical or possible. Some architectures make it easier than others, but the point is, it still takes time out of you teams day.

It is key to remember to do as much as is necessary and no more. “Simplicity--the art of maximising the amount of work not done-- is essential”. It is very easy to fall back into old bad habits and create reams of unnecessary and unneeded paperwork. Remember that it is far easier to scrap a process entirely and rebuild it from scratch than try and pare things back . When trying to streamline an existing process, it is difficult not to be influenced by what is already there. The result is that it is very rarely stripped back as far as it could be. It is far better to look at what is absolutely needed and start from there. I see another blog coming here!