Agile has lost its way: How to create a more sustainable development process

We’ve led hundreds of software projects for clients across the globe. They vary in size and industry, but all have something in common. 

An unhealthy obsession with Agile.

In the product-building world, organizations tend to problem-solve with strict processes and tools and more meetings. These efforts can quickly lead to the point where the original principles of Agile are lost in a muddled mess of roles, acronyms, and Jira tickets. At its most extreme, you have Scaled Agile Framework for Enterprise (SAFe), which is the ultimate in Agile process and rarely works. 

Agile has lost its way. Let’s throw it away and find our way back to a sensible place.

We don’t believe there is a best practice when it comes to building software. Instead, we believe there are unique organizations, with unique humans, building unique products who need their own approach to building software.

A while back, we worked with an engineering team who engaged us to do some software development for them, as well as provide project management help. 

When we started working with this team, it consisted of about 25 software developers, two product managers, one product analyst, a director of product, and a vice president of engineering.

Before we arrived, the team had grown organically from a nimble, close-knit team to a large team that was drowning in meetings and not turning around work quickly.

Their processes weren’t working.

Since product development teams’ ultimate goal is to reliably deliver product updates, developer productivity is key. At the time we entered this relationship, developers were in hours of meetings per week and struggling to get work done. Most of the meetings were about organizing work or shaping functional stories. We wanted a way to take from Agile principles and create just enough processes to avoid chaos and keep the engineers happy.

Because the team was in an initial build phase, it made sense to borrow many principles from Scrum but adjust them based on how the team worked.

The goal wasn’t to dictate how things were done, but rather act as an impartial instigator for asking hard questions and creating momentum for change.

First off, any 25-person team is too large to manage. We worked with leaders of the organization to split up the team into multiple squads that made sense. 

This foundational change makes it easier to manage further change by letting individual team leads be proponents of changes within their small groups.  It also gives small groups of people autonomy to have mini processes-within-the-process that work for them. They can implement processes for their squad and not have to incur the overhead of syncing with 20+ people to enact change.

Many teams have meetings that include all team members. The standard backlog grooming, planning, and other sessions include upwards of 20 people. But typically, only a few are active in discussions. The remainder sits passively wondering if they are needed, likely getting frustrated that they can’t focus on their work.

By splitting the team up into separate squads and having separate ceremonies, meetings become shorter, more focused, and more engaging. Yes, it means more work for product owners, because they need to attend more meetings. However, the cost of the product owners splitting up work amongst teams and attending more meetings ends up being worth the benefit of getting teams to streamline work and be in short, focused meetings.

When you implement focused meetings, you will see that all team members engage in conversation because they can contribute to a focused discussion. We find that this approach of as-needed, well-targeted meetings offers the flexibility to be agile and adjust to the needs of each sprint. 

Though a single workboard is great for small teams, it can become untenable and lead to planning overhead when teams grow large. 

The transition to multiple squads and the nature of your work make it necessary to have different, focused boards. This makes it easier to get a sense of what was happening across individual teams while ensuring everyone can access other team boards for cross-team user stories. 
In our experience, product managers love individual boards. It makes it easier for them to see and plan their work.

These meetings should be led by your team’s Product Manager, a ScrumMaster, and a developer lead. In the meeting, review the team’s velocity for the most recent sprint and the average from previous sprints. Use this alongside knowledge of the team’s priorities, to put together what needed for the upcoming Sprint. 

The magic here is not the process, but getting the team to stick to the process. 

Team retrospectives often don’t provide as much value as they should. A huge reason is that nobody feels comfortable talking in a large group. 

Sharpen the focus of each team’s individual retrospective by focusing on the typical questions of what went well, what didn’t, and what could be improved. Be careful to coach and not cast blame in these meetings. 

A common roadblock is that some team members are more likely to share what’s bothering them than others. This leads to consistent conversations and the false impression that things are going well or that everyone is satisfied. Reinforce that feedback can be provided directly and anonymously.

This can result in some strong individual discussions, but quite frankly, it is not enough.