Agile in the Age of Pandemic: Best Practices, Part 3 of 3

The biggest IT spending drivers from TechTarget's 2020 IT Priorities Survey remain relevant amid the COVID-19 pandemic, although cuts in planned spending are likely.

The Outcomes & Iterations of Agile

Whether it’s a faster turn for development, more robust products or a delighted customer base—the benefits of Agile are there for organizations to realize. Learn how to curb your technical debt, close out your initial Agile-based projects and know when your teams are “done”.

First, we showed you how to launch an Agile program. Then, we helped you get it running . The third and final chapter of our Agile saga involves closing out your initial Agile-based projects and positioning your organization for the next iteration.

We begin the conclusion with a note about the importance of Agile in today’s Remote By Design™ world. An Agile software development mindset is essential for a digital, customer-centric organization. By taking advantage of the best practices detailed below, your company can maximize your Agile ROI. Whether it’s a faster turn for development, more robust products or a delighted customer base—the benefits of Agile are there for organizations to realize. Today.

As your Agile teams wind down one iteration and launch into the next, consider the amount of technical debt you’ve accrued. In the race to build the next new and exciting feature in the sprint, how much additional work has been created as you successfully launch this feature? How much code has to be rewritten or deprecated to support this new functionality? All of this comprises your technical debt.

Teams must be tempered in their approach to sprints to ensure they don’t create an insurmountable level of technical debt. If your team raced through a sprint, or set of sprints, to deliver the output, only to learn the technical debt burden is so high the feature doesn’t work as intended or something else breaks, you’ve got an issue.

Technical debt must eventually be worked off. Problem is, such repayment may be substantially harder the longer it’s delayed or the more it accumulates. The rate of interest on technical debt, or the pace at which it accumulates, compounds—just like financial interest!—over time. If you wait too long to resolve your technical debt, and you can completely erode the entire value proposition of the Agile methodology. Don’t let this happen. Keep technical debt in check.

Manage Resources Frugally

Agile teams are likely to be driven from the ground up by the tech visionaries scattered throughout your organization. These are exactly the kind of people you want to keep deeply and thoroughly engaged. They amplify the output of all other teams, by their very presence. However, Agile can be a strict and punishing methodology. Given its rigorous approach and short timelines, it can be a hard task to master indeed.

Managed unsuccessfully, Agile can lead to burnout for your team members. Ensure that your Agile teams are self-managing correctly, and getting enough time, clarity, resources and support to execute successfully against their goals. Consider rotating key members into and out of critical, labor-intensive roles so that everyone has some down time and you’re able to develop a fully cross-functional team. Role rotation ensures that everyone can bring their “A” game to each sprint. You don’t want people dropping out of the race from exhaustion.

Know When Agile Teams Are “Done”

What does “done” mean, in the context of a sprint? Your team must figure it out. Collectively. They should decide together when particular a piece of code is finished and ready for its next iteration. Failure to do so can result in a number of challenges from scope creep, as noted in a previous blog post or burn-out, as noted earlier in this one. Once the definition is in place, it must be rigorously applied to all of the code in the Agile sprint. Done must always mean done.

Use Agile as it Was Intended

If you’re going Agile, you must do so in proper fashion. You need to use the bottom-up approach, with iterative Agile sprints enhancing the developing code base, through built-in mechanisms for continuous improvement. If organizations try to manage Agile from the top down, and fail to respect the process, it will be a self-defeating exercise. Don’t try and over-engineer the Agile approach; let it flow naturally in its iterative, evolutionary manner.

Balance the Three-Legged Stool

Time, resources, and scope are three legs of the agile stool. Every project and product must balance these factors: (1) the team you have, (2) the amount of time available, and (3) what you’re expected to deliver. You need all three for the agile stool to stand up and support the weight of your enterprise.

With Agile, you’ve largely locked down timeframe with a dedicated and defined two-week sprint model. Your team, especially in such a short period of time, is also normally clearly and succinctly defined. The team you have when you start the sprint will be the team you end the sprint with, barring a few outstanding exceptions.

You can manage these two pieces by adjusting and aligning on scope. This goes back to the principle of balancing the three legs of your stool. If you have defined lengths for two of the legs, your third leg, scope, also needs to align. The scope can’t be too large (long) or too small (short) or else the stool will be unbalanced. If it’s not balanced, your Agile team and their work will flop to the floor.

Thus we close the book on Agile (for now). I hope these best practices help with your organizational agility. 

The original article can be found here.