Don’t call it Sprint – A pamphlet

This pamphlet is basically me venting about working with clients who only take the flexibility part of Agile – but refrain to stick to taking responsibility for the decisions they made. It’s venting about not releasing to production. It might be the prelude to a longer set of articles on Agile.

---

In Each&Other, the amazing agency I worked for in Ireland, we over time worked more and more Agile with clients. Clients love working Agile. At least to some extent. It gives them more control of priorities and allows for better change management. It’s still not easy sometimes:

Once we had project that contained 12 features. We designed and developed 10 of those features plus 10 smaller new features and about 20 change requests.

	Planned features	Unplanned features	Bigger changes (I’m not talking about changing a word here or there – that was all CMS manageable)	TOTAL
Requested	12	—	—	12
Done	10	10	20	40
Diff	-2	10	20	28

When we ran out of budget, the client insisted on still getting those 2 (of 12) initial features implemented. Which is infuriating!!! They got 28 MORE features and changes IN BUDGET! And they had been part of the prioritizing all the way throughout the project. Constantly I was saying: If you want this (change or unplanned feature), your unplanned feature No. 11 and 12 will not make it.

Probably it would even have been possible to actually DO those features 11 and 12 in budget and time, if there hadn’t been release efforts of about 1 week. This 1 week was the last week of the project and it was a close call getting all production configurations done in time (0:30am, launch-day).

And that’s the point: In Agile you release early! You do prepare your production environment first thing and then release your project to this production environment.

There are always the same arguments:

There’s nothing to be seen, yet.

It’s not about seeing something at this stage. It’s about making sure, you can release to production and your production environment works as intended.

User must not see this, yet!

There is a difference between releasing and launching. You need to release early, but you can still hide this early state from your users. Use a switch, an IP-restriction, even a simple password protection should suffice.

It doesn’t work, yet.

I see. But wouldn’t you rather make sure your production environment supports your way of implementing it, before you implement it? Yes, you would.

Everybody is talking of risk management. Big corporations create piles of documents about risks to the project, whereas the biggest risk – besides the general feasibility of [whatever you want to do] – generally is releasing to production and getting it work there.

Not releasing early is like planning your holiday, packing your bags, driving your family to the airport without having booked the flights. You first make sure you have permission to take-off, before you bring your stuff to the airport. You might get lucky – but do you want to take the risk?

Now that I’m really enraged: What does all of this has to do with a “Sprint”?

A Sprint is a development-cycle in Agile (and Scrum in particular). The result of a Sprint is a potentially shippable product increment. Does that mean potentially as in

Let’s see whether we can get a last-minute flight?

No! It means potentially as in

We’ve booked the flights and are ready to go. Unless of course one of the children gets sick and we decide to stay at home.

It means you have a well prepared production environment and have proven you can ship your software there. Whether you really do this at the end of a Sprint – that’s your or the clients decision. Having the option to do a release, this flexibility, that’s what contributed to the term “Agile”.

If you’re not releasing your software to a preproduction environment or even production, if you’re not testing it there and presenting it to clients or stakeholders for sign-off or similar, you’re not doing a Sprint. You’re simply doing an “x-week development period”. Don’t call it Sprint!!!