While introducing agile development ideas, one of the things which went down really well with the project team was the process I used at the end of iterations. This was based around two simple, regular emails that followed the same pattern. I thought it might be useful to talk about them.

Background

To start with, most of the management dealing with software development were unaware of, or unconvinced by, the concepts of iterative or agile development. So a few of us techies began to sneak in some of the concepts quietly without talking about what we were doing.

We started to introduce concepts of timeboxing, regular deliveries, iterative planning and frequent feedback without mentioning any of the jargon. Hence, what I'm about to describe isn't ideal and isn't based on a specific agile approach, it's more like guerilla tactics to get wary people used to seeing agile type behaviour.

Luckily, the business people took to the new patterns quickly and it didn't take long before they started to get involved and we could start to be more open about what we were doing and how we could introduce more good practices (without mentioning anything worryingly like "Agile").

The process

For one of our projects we started saying we'd deliver a new version of the app to a development server every two weeks, come what may, on a Friday, early afternoon. After deploying it, I'd send an email Demo email. The rest of the afternoon we'd be having discussions about it, answering questions and doing project housekeeping (Scrum might call that "slack", it doesn't feel like it!) The following Monday we'd start on the next round of development.

We got agreement that, after a few rounds, the business team could decide any new version looked good enough to make live. Or point out some things we'd missed and after another round or two, we'd be ready.

At that point, the app would go through formal testing and QA and then go live on an arranged date. After deploying it live, usually after lunch on a not-Friday, I'd send a second type of email Release email. The rest of that day would be monitoring live, answering questions and housekeeping ready for whatever was coming next (different project, follow-up patch release, next phase, etc).

Demo email

This is roughly the email, with variants based on the actual iteration, I'd send every other Friday afternoon (or early Monday morning, on occasion):

To: dev team, business owner, project manager, business analyst, my boss, testers
Subject: New version of app (x.y.z) available now, on development servers
Hi All,

This is the usual email to let you know there's a new version of app available on devServer now. Feel free to give it a try here: url, signing in with your usual login details. If you don't have access, let me know and I'll update the necessary auth settings.

The main differences from the previous version are quick description of the iteration goal which you can see by simplest UI task that demonstrates the changes

The main Jiras addressed in this release are:

• JIRA ID and link - title

For the next round of work, our TO-DO list currently looks like this (in this order):

• JIRA ID and link - title
• Any features not yet in JIRA that we plan to do

If you'd like us to alter anything on this list, please let me know.

The main items still outstanding to meet the requirements for the next release are:

• list main bits of the remaining backlog

Currently we are waiting on any obstacles or blocking people before we can move forward with whatever is blocked.

If you have any comments about the new version on devServer or notice any problems with it, again please let me know.

Thanks to anyone who worked on this version for whatever they did.

Cheers,
Me

Notes

There are quite a lot of agile-ish things I'm sneaking into this email:

• Everyone even vaguely related to the project sees a regular release heartbeat
• Every new version gets a new version number, even if it'll never get seen outside the team.
• The means to see for yourself is right there, with links. There is no excuse for not looking.
• It forms a kind of minimal sprint review/demo plus sprint planning, especially when it gets people talking.
• The main release goal is given up top as an easily reportable fragment. After clicking the first link and reading the first two paragraphs, managers can do their high-level reporting.
• Everyone can see the list of stuff we did. They can click the JIRA links to find out more.
• The testers and owners can see the issues they care about, in relation to all the other work going on.
• The backlog for the next iteration is right there. Ok, we made it ourselves, but the invite for change is there.
• The overall backlog for the release is also there, in broad outline, for everyone to see where we're heading.
• As the emails progress, the backlog gets shorter, or we mention any new stuff as it's added.
• The shrinking backlog allows managers to plan for formal test and release as the backlog gets small enough that they can see when it will empty.
• Any blockers are laid out for everyone, which prompts people to respond fairly quickly.
• There are requests for feedback and contributions from everyone, flattening the hierarchy as much as we can.
• Regular congratulations to anyone and everyone who had worked on it.

Release email

This is roughly the email, with variants based on the actual iteration, I'd send following a successful live deployment (and subsequent sanity tests):

To: dev team, business owner, sponsor, project manager, business analyst, my boss, testers, IT support team, our director
CC: anyone else I wanted to thank, anyone else who wanted to know
Subject: New release of app (x.y.z) is now live
Hi All,

This is the release email to let you know a new release of app went live at time. Feel free to give it a try here: url, signing in with your usual login details. If you don't have access, let me know and I'll update the necessary auth settings.

whoever and I have done some initial testing to confirm this new release is working as expected. The deployment followed the deployment plan at JIRA/Wiki link. user groups can start using the new features now.

The main differences from the previous release are:

• list of the main features/goals of the release in business terms

The Jiras addressed in this release are listed on the Jira page for the release: JIRA link

There are a number of items still outstanding which will be addressed in a follow-up release:

• JIRA ID and link - title
• Any major features that were requested but didn't get included

If you'd like discuss anything on this list, please let me know.

If you have any comments about the new release or notice any problems with it, again please let me know.

Thanks to anyone who worked on this version for whatever they did.

Cheers,
Me

Notes

This is a less "agile" style email, but it deliberately resembles the Demo email to get people used to seeing this style of regular email about regular new releases with incremental features and improvements.

The key points for me about the email are:

• It gets sent to more people, including senior people who are interested in the project and anyone who might end up getting asked about it.
• The email is sent after the release is definitely live and definitely working. From the moment they get the email, they can start telling users about it, showing it off to customers/clients/competitors or whoever they want.
• We confirm exactly who has seen it working in live. This includes the project owner, someone on IT support and me.
• Managers and other business people have their traceability reporting details by the end of the 2nd paragraph.
• The owner and sponsor and IT support have a simple list of what is in the release - hopefully it matches what they expected.
• The JIRA list for the release can be quite long as it can sometimes span a few months of work. So I link to the overall Jira page for the release.
• There are often either minor issues that get punted due to time constraints, or things that crop up as people finally realise the release is about to happen, or even niggles during final deployment. If that happens, these get listed to address in a follow-up release. Managers can look at the list and agree whether it's worth another quick round to fix them, or whether to add them to the backlog for the next release.
• Again an invite to take a look at it and get in touch, just to remind everyone it's a feedback process.
• As with the Demo email it ends with a thanks to everyone who helped.

Thanks FTW!

People are always keen to be included in the thanks section because following the email there are always reply-all responses from a number of senior people repeating the thanks and saying "yay - good job!" in various ways. For some of the teams it was rare to get any kind of thanks from senior staff, so the flurry of response emails always caused happy faces for a day or two afterwards.

Due to the way performance reviews worked at the company, these "thanks" response emails were actually kept safe to use during annual reviews as proof of what people had done and how well it was received during the year. So I tended to get thanks from them for making their reviews go better, win all round!

Any problems?

Did we have any problems or negative comments about these emails or the development approach they implicitly supported? Only a few, and they were mainly cultural, which meant they were being gradually addressed by the people who had already been convinced this was an improvement over what they had seen before.

Not reading the To and CC lists - we had a few serial offenders who would always forward the release emails on to other people they thought might be interested, despite those people being recipients of the original emails. There were a few forward/reply-all cascade chains triggered from these, but they died down fairly fast and inboxes are easy to clean up.

Why did you tell X? - occasionally we got slightly odd questions about why someone had been included in a Demo/Release email. The answer was always they same: either X had asked to be told, or X had worked on it (X was always an employee). Email is cheap, none of the details was confidential within the company, there was no reason to avoid telling someone something they wanted to know.

Why isn't Jira X included? - these questions usually came from people who had seen a Jira mentioned in passing that had snagged their attention, but who hadn't actually been involved in the discussions about it. The first answer is usually that the details are in the Jira comments themselves, so a little hand-holding to show how to find the Jira from the Demo/Release email and read down the comments did the trick.

I also tried to use this as an opportunity to sneak in the idea of iterative planning. When they saw the TO-DO list in the Demo emails, that was when they could ask for X to be included in the next development round. I'd also mention that ideally they should speak to the product owner and they'll prioritise it and add it to the TO-DO list.

When will the $BigProjectDocument be updated? - some still expected the formal development procedure to be followed to the letter, including all those big write-only Word docs rotting away in Sharepoint. I must admit to buck-passing on this - I suggest they talk to the business analyst, project manager, development manager, etc owns those docs and ask if they've been updating the docs from my "progress reports".

Luckily it didn't take long before most people stopped even mentioning those docs for most of the projects I was involved in. A few did still complain that every Demo/Release email meant they had to go back through all their project docs and update them all again. My usual response was sympathy, and to ask things like: Why? Who is using them?

Previous Post Next Post