How to use less agile to be more agile

This post originally appears in the dPrism dBrief. Check it out and sign up for weekly articles on digital transformation. 

There are many reasons to like the agile development process. Its focus on adding value to a “minimum viable product” in iterative sprints is a great way to avoid waiting until the end of a project to see if you’re on the right track. Also, its practices of working in small, empowered teams, with rapid standup meetings and retrospectives, are becoming hallmarks of modern software development. So why are some agile projects still clunky or over engineered? This article will suggest three ways your agile intensity is misaligned and three ways to lean lighten structure and lean into a flow.

First thing to note is I’m an absolute believer in the agile approach and continue to marvel at its positive impact on team empowerment and tangible productivity. Here’s a good primer on agile for readers unfamiliar with the approach. My observations are focused on my own experiences and the very human tendency to over-engineer things.

1. Agile is a method, not a blunt instrument.

A few months ago, my team launched a new platform development project, integrating external consultants using an agile framework with client team members with little agile experience.  We spent quite a bit of time going through the agile approach, carrying out card-sorting exercises, building a glossary of terms and scheduling weekly standups and monthly sprint retrospectives. The client was interested but a bit overwhelmed. Since our project was the only application of agile in their workday, it became more of a curiosity than a practice.

Opportunity: No matter how much you might believe in agile, keep in mind the goal is project outcomes, not teaching agile practices. As long as you maintain the required discipline inside the project team, it’s not necessary to confuse the larger organization with agile terminology and artifacts. I like to think of concentric circles of agility, with the inner team fully entrenched in how the work is done while the outer groups are only interested in the outcomes. This helpful since its easier and faster for the team to translate agile than to teach it.  

2. When agile gets clunky: standups and retrospectives

As streamlined and efficient as agile meeting structures are, they can still become clumsy when participation doesn’t match activity. This became obvious during the three-month discovery period of a nine-month project.  Without a lot of work product elements to keep them engaged, many under-utilized project members were bored in the standups and retrospectives we dutifully scheduled. Standups and retrospectives became more of an update better handled through dashboards and email summaries. 

Opportunity: Consider standup and retrospective meetings as guard rails to keep your project aligned.  The more challenging the course, the more you need these guardrails. For your own projects, consider how each of the following contributes to the need for alignment and adjust frequency to what works:

• The clarity of purpose
• The need for team interaction
• Sprint length (shorter sprints have fewer chances for blockers and misalignment)
• Amount of backlog items

This idea is well-articulated to the extreme by a product manager at Spotify. In his view, a well-organized team gets into a state of flow where standups and retro’s are no longer needed.

3. When the input isn’t agile

In a prior role, I had the chance to participate in a highly effective agile team developing marketing capabilities across marketing, sales and service.  It was one of my most exhilarating professional experiences to contribute on a team that fluidly handled the intense workload in a high-quality manner. The team had built processes to vet new opportunities while also doing required development and break/fix maintenance. If left to thrive in our little bubble, we had created a productive and resilient ecosystem.

No capabilities team lives in a bubble. We would often get mandatory last-minute requests for unscheduled and un-vetted projects. Depending on the size, the “gate crasher” project could wreck the entire cycle, forcing the team to compromise on maintenance and other important components.

Opportunity: Try to think of agile in a suppler way, reframing the things you can control within the confines of the reality of the work. In my prior example, we created a stand-alone team (train) for out-of-process requests to buffer the disruption to existing teams. Over time this “gate-crasher” team morphed into an innovation team, with different internal groups vying for development time on their best new projects. Last-minute projects still had a place, but only if they passed a higher standard based on the other potential projects in queue. 

It’s not my intention to encourage anyone to abandon the many exceptional components of the agile development approach. Indeed, only by fully immersing yourself into its full structure can you understand how powerful its components are individually and in concert.  What is encouraged is to keep in mind that agile’s very nature is to find the best work product for the minimum effort.  At the point you understand the rules, you have the opportunity to relax them for desired effect.