What do penguins, ostriches and agile product teams have in common? They evolve to survive, making changes to help them move faster and more efficiently in their unique environment.
In the arctic and desert ecosystems, the wings of penguins and ostriches have become smaller over time as they are put to a different use than flying — swimming and running, respectively.
In the tech business ecosystem, many teams rely on the agile methodology to adapt quickly and increase their chances of thriving in the long term, like penguins and ostriches have done. Agile frameworks help the team boost productivity, quality and overall reliability in their development processes, empowering them to adapt to feedback or change direction quickly. This iterative approach is increasingly standard, with up to 86 percent of software development teams adopting the agile methodology, according to a report from digital.ai.
But teams working with an agile framework often interact with a large number of stakeholders and cross-functional collaborators, which can cause an increase in meetings. This increase, coupled with rigid working guidelines, can lead to burnout.
One of the top ways to address agile fatigue, according to product leaders from Forward Financing, Scaled Agile, Inc. and Sure, is to fit the agile process to the unique needs of the organization. Not all methods work for every group, and like some familiar flightless birds, it’s up to each individual group to discover the specific evolution necessary to flourish.
Built In caught up with three product leaders to learn the unique ways they combat agile fatigue and keep their teams nimble and progressive.
Forward Financing is a financial technology company that offers fast and flexible funding for small businesses, including revenue-based financing options.
What practices do you follow to avoid agile fatigue on your team? How or where did you learn these practices?
In my experience, agile fatigue often arises from rigidly following a framework. Forward’s organization is agile, adhering to Scrum, but each team operates differently. The beauty of agile is empowering teams to find their own success. So, how do you determine what makes your team successful? I focus on three methods: observe, ask and experiment.
Each team measures sprint success differently, so identify your key metric, be it completed tickets, story points or shipped features. Monitor this metric and observe changes over time. When trends emerge, seek feedback.
My preferred feedback method is the sprint retrospective. Every other week, the team discusses successes, challenges and future concerns. To combat agile fatigue, it’s crucial to get insights directly from the team. We set ground rules for sprint reviews, ensuring openness and honesty. After identifying potential issues, we brainstorm solutions as a team and experiment with them. We “timebox” each solution and assess its effectiveness together.
While we completed formal Scrum training and adhere to core principles, we’ve adapted our approach over time to find what works best for us.
How have these practices helped boost team morale and work performance?
A few months ago, our team noticed that our daily stand-ups were losing effectiveness. We would review the sprint board, and each member provided a standard update: What did you do yesterday, what will you do today and what are your blockers?
This approach led to several issues. Team members often worked on different projects, so their updates weren’t always valuable for the entire team. Some tasks required multiple days of effort, meaning daily updates didn’t change, and the meeting disrupted the developers’ workflow. These issues resulted in overall disengagement during a meeting meant to encourage collaboration and problem-solving.
After gathering feedback in a sprint retrospective, we decided on a few changes. Updates should focus on what impacts other team members. Team members should not be required to provide an update if there hasn’t been a material change in progress. Asynchronous stand-ups should occur every other day to reduce context switching and maintain efficiency. On synchronous stand-up days, we include a non-work-related agenda item.
Since implementing these changes, our team has been more engaged, and the benefits extend beyond standups, making us more productive overall.
What advice would you give to other product leaders eager to avoid agile fatigue on their teams?
The best advice I can share is not to try and mirror another team’s or organization’s process just because they found success. The most successful teams forge their own path based on their personnel, experience and goals. Successful product leaders constantly solicit feedback from the team and adjust accordingly.
“The most successful teams forge their own path based on their personnel, experience and goals.”
Scaled Agile, Inc. is an information technology and productivity software company that offers integrated software solutions to improve business agility.
What practices do you follow to avoid agile fatigue on your team? How or where did you learn these practices?
In my experience, two intertwining practices keep agile teams from experiencing fatigue: listening to people and incorporating their ideas and needs into outcomes.
For example, my current team members felt we couldn’t adapt quickly enough because of a strict iteration ceremony cadence. So we found a new way forward. The team still participates in quarterly planning, organizationwide iteration demos and dependency coordination with other teams. However, we refine and plan our own work in quick bursts, and each person pulls work from the top of the refined list after they finish something else.
Another example arose when the team felt they weren’t getting enough time to refactor and maintain systems and remove technical impediments to the flow of value. Each quarter, when we share with leadership the value we’ll contribute to strategic initiatives, we also share the value we’ll achieve by addressing technical debt and maintenance.
Throughout my career, I learned by experimenting and through the experiments of others, including on teams that wouldn’t call what they do “agility” and from individuals who cooperate without forming traditional teams. Inspiration is everywhere!
“Throughout my career, I learned by experimenting and through the experiments of others. Inspiration is everywhere!”
How have these practices helped boost team morale and work performance?
Because the team has built its process based on listening to one another and choosing our own path forward, work flows more smoothly. We’ve reduced cycle time by half, released value to customers more frequently and shortened the time spent in meetings. Overall, people seem happier and more engaged when we do meet, and our synchronous conversations generally result in solving more problems.
The other thing that has helped with morale and work performance is the team having a say not just in how we work but in what we do. I know we’ve struck the right balance of team-driven work to strategy-driven work when I see: both kinds of work moving to “done” over time, our systems performing reliably while continuing to adapt to customer needs and the team taking time to dive deep on sticky problems, which they’ll only do if they feel they have the capacity and encouragement.
What advice would you give to other product leaders eager to avoid agile fatigue on their own teams?
I can only say what’s worked for me. It’s not “going agile” that makes work better. It’s taking collaborative action to experiment with and solve the problems a team — or many teams — identifies together.
The most challenging part of changing things can often be handling obstacles that originate outside the team. To help remove those obstacles, the best product leaders that I know build relationships across the organization and actively establish a good internal reputation for themselves and their teams, so when they need to influence change, the people they’re influencing know and trust them.
Sure is an insurance technology company that offers enterprise SaaS infrastructure and a system of APIs to streamline the insurance cycle for providers.
What practices do you follow to avoid agile fatigue on your team? How or where did you learn these practices?
In a remote-first company, it’s important to experiment with daily stand-up formats and sprint planning to avoid agile fatigue. I view agile practices as guidelines rather than the rule of law. Our daily stand-ups include a range of formats: pulling up the Kanban board, an open forum for discussion or an asynchronous stand-up in Slack.
I also strive for every sprint to have learning opportunities. Our sprints include prototyping with new technology, research into future projects, paying down tech debt and documentation for system design. These allow members to select the skill sets they want to expand while keeping everyone interested in their work.
I learned these practices by drawing upon the research in other fields, particularly evidence-based practices in education. As a result, I observe, listen and ask questions. Then, most importantly, I take their feedback and put it into action. We reflect as a team through retrospectives and adjust our practices through new experiments as necessary. Staying in tune with my team and adjusting our agile practices regularly has kept my team engaged and reduced agile fatigue.
“Staying in tune with my team and adjusting our agile practices regularly has kept my team engaged and reduced agile fatigue.”
How have these practices helped boost team morale and work performance?
Our experimental mindset fosters our team to be open-minded and connected. Team members are more engaged during stand-ups where we routinely joke and connect through personal interests. We have more productive collaborations because team members feel comfortable speaking up regularly and offering insight into things that might be glossed over in a more rote stand-up. When everyone feels valued to raise concerns and work through issues, we can proactively identify issues early and deliver our work commitments on time.
