5 Tips for a Top-Notch Agile Release

5 Tips for a Top-Notch Agile Release

Software releases are seeped with dramatic tension. After slogging away over several development sprints, the agile team passes the beta test or completed software on for presentation. How will it be received? Will the team’s hard work end in tragedy, with glitches and malfunctions galore, or in rousing success, with an evening of hearty pats on the back and bubbly champagne?

It’s tempting to over-manage such a highly-anticipated event and to keep tabs on the agile team, monitoring its every step.

However, agile teams aren’t meant to be kept on a short leash. They’re at their best when working autonomously. And sticking to a rigid schedule isn’t the agile way. Rather, it’s to “adapt to change over following a plan.”

So how does a manager assure the client of a release date and a quality product when the development team itself needs to call most of the shots?

It is possible for management to oversee a successful release without encroaching on the agile methodology. Here are a few tips and tricks to pinning down a solid release date and checking all the boxes for an optimal presentation of completed software.

1. Write a Release Plan

The first principle in the Agile Manifesto states: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”

A release, then, is central to the agile methodology, and ideally something that occurs frequently. A release isn’t the increment produced at the end of each iteration, but rather the culmination of several sprints, and it’s passed from the development team into another environment for review.

Whether it’s a final product, a piece of final product, or a beta of the final product, achieving a release is a real milestone.

Making a plan ensures the release is executed smoothly. A thorough release plan includes the overall goal, which ideally has been discussed amongst all stakeholders using the MoSCoW method to clarify high and low priority requirements.

These priorities allow the team to review the backlog and identify those stories that must be completed during the release, those that might be completed if time permits and those it can put to the side. A date is determined for the release as well.

A release generally lasts at least three sprints. Agile is about adapting to change, and so this date isn’t hard or fixed. But the plan keeps the team on track and focused on a shorter-term business objective.

2. Discuss, Then Commit to a Release Date

Have you ever set aside an hour to mow your lawn, and four hours later you were still at it? Maybe the mower needed gas or a new blade, plants needed pruning and weeds needed whacking.

Estimating a project before taking a hard look at everything it entails is almost always a long shot.

When managing an agile release, then, it’s prudent to pin down a release date only after everyone on the team has sat down to evaluate the work at hand. Grooming the backlog and playing planning poker helps to gauge just how much work the team is taking on.

Another strategy is to simplify the stories as much as possible. Breaking work down into small, singular tasks is like shining a black light over the project, making it easier to spot any problems areas and potential snafus.

Whenever possible, it’s good to have these conversations face-to-face. The Agile Manifesto states: “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” So much communication is non-verbal, and in-person conversation allows for voice-inflection and tone to come across.

After it’s all been laid out and discussed, it’s time to find consensus using the fist of five. The plan only gets a “go” when the anticipated release date is met with jazz hands from everyone on the team.

3. Let the Team Find Solutions

Any manager with his or her eye on the bottom line wants to oversee a software project like a hawk. It’s tempting to determine all sorts of things, such as how many sprints it should take until release and how many tasks should fit into each sprint.

It’s hard, and probably feels a little nonsensical, to hand the reins over to the team to figure these things out on its own.

However, this actually makes a lot of business sense. From writing code to testing, the software team knows the ins and outs of the project better than anyone else. And so allowing it to plan and structure the project is the surest path for success.

But how can you trust you’re really putting the project into good hands? Another principle of Agile Manifesto states: “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”

If you’ve hired a team of go-getters with plenty of domain knowledge, they’re fully capable of working on their own and getting the job done.

4. Manage Workflow, Not Work Hours

Keeping a release on course hinges in part on efficient processes. Ideally, a team works at a consistent velocity, completing a similar number of story points each iteration.

How does a manager or scrum master keep the team on an even keel?

One thing he or she shouldn’t do is hand everyone a lengthy to-do list and put them on treadmills running at a grueling speed. This isn’t a recipe for quality work, but simply a fast track to burnout.

The Agile Manifesto states that “Simplicity—the art of maximizing the amount of work not done—is essential.”

Creating a high-functioning agile team is really about smart practices. One such practice is limiting the number of stories a team works on at once. Having too many irons on the fire creates cognitive burden and scatters everyone’s focus. Work is sloppy and time is wasted.

Instead, working on only one or two stories at a time lightens the load and unleashes the team’s energy. The team swarms to bring each story over the finish line, then moves onto the next item in the product backlog.

A second efficient method is planning sprints and daily tasks at the latest possible moment. The agile method is to work in the present, reflect, then adjust the path going forward. And so rather than looking one or two weeks ahead, it’s most efficient to plan for today based on what you learned yesterday.

5. Schedule a Release Sprint

Even after the release is written and tested, most projects still have a lot of loose ends. For example, all of the documentation is written in technical jargon, which to an ordinary person makes no sense at all.

A release sprint is a bit like a dress rehearsal. It firms things up and makes software presentable and usable for external release. An effective release sprint brings in stakeholders from outside the development team to review the product, evaluate it and provide feedback.

Much of this preparatory release work has nothing to do with development at all. The backlog for a release sprint might include writing a FAQs page for new users to an application, or providing instructions for managers of the application on how to update features.

These documents use everyday language, unlike the technical language from the development sprints. It’s a good idea to create these documents just before the release, so that they include any last minute changes.

Taking the time for a release sprint ensures the final product is sparkling clean, presentable, and ready to be handed off. A release sprint functions a little differently from a development sprint. It may be a different length, and may also use a separate “definition of done” from the one used for writing code and testing.