Learning to be an Agile manager — Part 1: Continue — Weekly Release Trains

Background

A little over 3 Years ago I accidentally became Head of Software Development for a medium size financial services company.

I was approach by a recruiter that was looking for an experienced software process person to help a client improve their software processes. The company has outgrown the startup phase and required a little more structure. I discovered an opportunity to lead an Agile implementation and was able to convince them to trust me with it. The CIO discuss the title for the role with me, I indicated that I did not have any preferences, so I became Head of Software Development.

This is some of the lessons that I have learnt as a line manager for agile teams. It is in the form of a retro using the continue-stop-start approach. I know it is usually a start-stop-continue approach, a retro is normally held in a safe space as well, continue-stop-start helps me feel safe.

Release Trains

The company had a weekly production deployment frequency. I was impressed by this, I reasoned if teams were able to deploy weekly not too much can be wrong with their process, value is getting to production quickly? After a couple of weeks I realised that I had a lot of work to do.

The frequent production deployment cycle was not a sign of successful value delivery, but a sign of the demand for it by business. The focus of the development work was not on the highest value, but on the most urgent work. On some of the sub-systems 1 in 3 deployments was successful and not rolled back.

The result of this was that the urgent work often had a impact on the existing value that the system delivered as a result of business disruption during deployments.

Why continue? After improving value prioritisation, code quality and deployment processes the weekly production deployment frequency became a weekly release train that pulled value into production. Sprints follow a 2 week cycle, the weekly release train give teams and product owners more opportunities to go to production.

In a lot of financial services organization release cycles are fortnightly, monthly or quarterly. Driving the frequency of production releases up by removing impediments that constrain them, act as encouragement to Agile teams to get their work ready for production. It pulls value and limits the amount of value that is queued for release. This in turn makes deployment more incremental and as a result reduces the risk of each deployment.

Frequent release trains pull value and reduce risk.

This is part 1 of 6 in a series, See Part 2: Agile sub-culture