days
0
-47
-1
hours
0
-1
minutes
-1
-4
seconds
-1
0
search
The Outcomes & Iterations of Agile

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

Jitin Agarwal, Ken Gordon
agile
© Shutterstock / My Life Graphic

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-baed 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.

SEE ALSO: The Call for Bigger and Better Digital Experiences

Curb Your Technical Debt

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.

    DYF

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.

SEE ALSO: Technology Trends Impacting the Future of Business

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. If you have any questions, Agile aspirant, sprint over to my LinkedIn page and ask away. I promise my response will be swift. End of story.

Author
Jitin Agarwal
Jitin (Jit) Agarwal serves as EPAM’s VP of Enterprise Products where he is focused on productizing and monetizing EPAM’s intellectual property and core services. Mr. Agarwal is a serial entrepreneur who has successfully led multiple startups to scale and launched numerous products in his career. Most recently, he created and ran the assetSERV™ Business Unit at Cognizant, where he grew revenues from $100K to $100M+ in TCV over his tenure. Mr. Agarwal has expertise in all aspects of product and venture lifecycles, including ideation, funding, development, sales and marketing as well as post-sales customer success. In addition to working with startups, he has worked at a number of leading technology firms, including Microsoft, Cognizant and Gartner. Mr. Agarwal is an alumnus of the University of Michigan and Northwestern University.

Ken Gordon
Ken makes EPAM Continuum’s work visible to the necessary people. He creates superlative content, works with colleagues to do the same, and employs social networks to share it widely. A card-carrying humanist, Ken co-founded QuickMuse, the improvisational writing website, and JEDLAB, the Jewish education community. He has written for TheAtlantic.com, the New York Times, and many other pubs. Ken has an English degree from the University of Massachusetts at Amherst and an MA in English from the State University of New York at Albany. He framed both diplomas long ago, but can’t seem to find them now—a fact he considers all-too-human.

guest
0 Comments
Inline Feedbacks
View all comments