News

When I first worked with an agile team, we released our work into production whenever we wanted to. We were able to do our own testing, our own release control and our own communication with users. We also supported our own work.

We released some things during the day and others outside normal hours, while a couple of the team stayed late and ate pizza while making sure everything worked.

This was very different to the old “waterfall” world I had also worked in, where a release took an entire weekend and involved up to 100 people. It was a huge drama and planning it was a project in its own right. So I thought of agile as being where the team could release whenever it suited them.

Then I encountered a scrum team who released on a regular basis every 2 weeks if the product owner (PO) said it was okay. They said that they were the real agile team and that my old team was really an “old school enhancement team”.

So even before I heard about MMF, MVP, release train, astrological release profiles and other tools, there were a couple of different approaches in play. But which was better?

Continuous versus continual and ad-hoc releases

Some teams practise continuous integration, which means that their code is released continuously, without interruption. This should mean that code is continuously flowing into production without a break, like water in a stream.

What my original team was doing was actually “continual, ad-hoc” releases. This differs from continuous (flowing like water) because continual (happening repeatedly, with breaks or intervals in between) requires a decision that a release will happen.

In both cases, the team will have a definition of done or a standard that must be met in order to deliver finished work. But if the team is practising continuous delivery then each person just finishes something and moves to the next thing.

IT teams doing continuous integration are doing this, as are call centres who answer a call, handle a ticket and hope to close it at the end of the call. This is also how social media and web-based news sites work – articles appear all the time and if you refresh your screen you would expect to see some change.

In an ad-hoc release, the team must make a conscious decision that work is ready to transition from “not in production” to “in production”. This is how my blog works and also how my original agile team worked. It might also be how an online news site or magazine might work if the editor signs off a story or it must wait for approval.

In order to release something to our user base, we would peer review it, test it and prepare some communications. We would also assess the risk and then assign it to a release based on that risk.

• Low-risk releases went when the customer was ready and the developer pushed a button. In fact, sometimes we even released things and then let the customer know.
• Things that had a bigger potential impact on what the user would see, or on the potential stability of the system, were delayed until we could assign a couple of people to manage the testing, configuration, migration and communication.

So the first question an agile team should ask is "does a release require communication and planning, or can a team member just finish work and let the customer know?"

But there is still the difference between my “enhancement wanna-be agile” team and the “proper scrum-based agile batch team”

If you are doing continual releases then you can either release on an ad-hoc basis (whenever something is ready) or you can set up a regular rhythm, where a batch of things are released together. For example, an online (or paper-based) magazine might publish an edition every Thursday, including multiple articles, opinion pieces, advertisements etc). In this case, the release probably involves a little more drama, but the cadence or rhythm is designed to give a regular flow to the work.

Many agile IT teams and process change teams adopt a regular rhythm, for example releasing every second Tuesday. This might help the team package their work or it might be done in order for users and supporters of the product to get used to regular, predictable change.

Academically, I have a bias that the more frequently you release value, the more agile you are. But the subtlety is in defining what you mean by value.

The choice should really about what approach is quicker and easier for the team and, of course, what is more useful for the customers. For example an online newspaper might publish some news continuously, while a reporter watches events unfold, or they might take stories to editors, who then release them ad-hoc, as they are ready, or they might release a series of articles every Saturday, that continue to explore a topic that requires more analysis, such as science news or something.

So the real agile approach would be to ask:

• How can we best package value for our customers (in batches, or as things are ready)?
• In batches suggests that we would set up a regular rhythm, such as sprints or iterations, or episodes or editions.
• In other cases you would not wait – for example, patients in an emergency room would be somewhat concerned to be told that their injuries will be repaired after the showcase next Wednesday. They are more used to triage and immediate value. So we might release on the basis of tickets, cases, completed craft etc.
• Do we need to make a decision about how/when to release what we produce?
• If you don’t need to make a decision (such as a call centre or a first aid team) then you can go for continuous integration and delivery.
• If you need to make a decision, such as booking an operation, administering a medicine based on tests done etc, then you would go for ad-hoc.
• How do we ensure that we maintain the right standards of care (er .. “definition of done” for agile teams)?
• What communication is involved when we release something? How do people find out about the value being created and the impact it might have on them?
• How do we learn from what we release?
• It is not really agile if there is no learning loop, so there must be some way of finding improvements based on what has been released.

Is that the complete set of patterns?

This is not the end of the story though, many teams add some extra ingredients to their releases. Some flavour their releases with a release train to stabilise the releases, some add meetings like planning, showcase, handover session and so forth in order to create an opportunity for catering.

I also discovered that for many teams, there is a slower (continual) feedback loop, such as a quarterly release, an MVP of a project milestone.

I believe that these things are still, potentially, agile, so I will explore them next time. around.

Posted by James King
Copyright © James King