Why Companies Fail At Agile

If you aren’t deploying to production every day (or multiple times a day) not only is your company’s DevOps model a failure but so is your agile practice, and I would bet you still think “release trains” are a good idea.

So that was certainly a bold statement wasn’t it? How can deployment velocity be a KPI of an organization’s agile practices? We all know it’s the “Cloud Team’s” fault our release frequency is in the trash, they don’t even use scrum like the rest of the development teams.

I hear this time and time again and as I have worked with companies over the years I have identified the primary behavior(s) of failed Agile Implementations and the behavior(s) of successful Agile Cultures (I’ll explain why I didn’t say Implementations here in a moment).

ScrumFall
I am not going to dig into what Agile is and what Agile isn’t as part of this blog I simply plan to identify behaviors that if your organization is practicing chances are “you are doing it wrong”. ScrumFall in a nutshell is a company that has decided to put lipstick on the same old pig. Dev teams might use Jira or Rally, they might even practice daily standups, have bi-weekly retros, and hold sprint planing. Sounds good right? Wrong? Organizations that fall into the ScrumFall category generally have leaders who don’t understand the “Iron Triangle Of Planing” and try to fix “scope”, “resources”, and “time” due to customer requirements. Not only are these companies not able to meet deadlines, but scope often turns out to be incorrect feature delivery comes to a screeching halt and ultimately customer commitments are missed

The Administrative Assistant
Another anti-pattern I see in the Agile world is engineering teams treating the scrum master like the team secretary. His or her job is to schedule meetings, update Jira, order lunch, and handle any and all administrative tasks the team doesn’t feel like bothering themselves with. The reasons for this happening are vast but generally it’s because the Agile organization has been disempowered and the Agile team members themselves lack the experience to do anything more. Scrum Masters are first and foremost Servant Leaders and Coaches for an Agile team. They aren’t there just to do the dirty work (they also aren’t there to enforce policies and dictate practices to teams, more on that later), this is a skilled position for people who understand Agile principles and how to empower teams through Servant Leadership.

Command and Control
Now that we have talked about how in some organizations the role of the Scrum Master has turned into a glorified administrative assistant we should also acknowledge that in many organizations the Agile team is at the very center of a power and control struggle that is causing toxic ripples throughout the company. At one organization in particular the Agile team refused to let the engineering teams self-organize because they dictated the engineering teams structure and feature ownership. What I can tell you is that the HR department at that company was extremely busy trying to help manage relationships between the two silos. At another organization the engineers simply reported to the Agile leadership, which also caused problems with team autonomy or voicing opinions about team structure and/or agile rituals due to fear from speaking out against Agile overlords. All of these are anti-patterns in the Agile world, many of which are toxic to organizational health.

What Does Success Look Like
So now that I’ve given some of the anti-patterns that don’t work in the Agile world I wanted to discuss what does work. Or better yet what I have seen work across a large subset of clients is Agile organizations that strive to do the following:

• Promote Team Autonomy
• Servant Leadership
• Enforcing The Agile Triangle Across The Organization
• Create An Agile Culture Not Just Process

Organizational Agile Framework
The final point of discussion I wanted to address is this idea of being Agile about your Agile. A co-worker of mine at Rally Software would always say this as we moved from company to company especially when we found ourselves working with rigid power hungry Agile teams which attempted to use Agile as a weapon in the corporate practice of empire building. What does it truly mean to be Agile about your Agile. Agile teams should strive to empower teams through servant leadership as discussed above and teams should feel free to employ tools from the Agile tool box in a way that works best for them; however, organizations still need to have predictability when it comes to customer deliverables, a mechanism for cross team dependency management still needs to be employed, and finally KPIs to measure things such as team velocity should still be required from individual engineering teams. But, teams should be responsible for figuring out “how” to achieve these goals for themselves. For instance, an infrastructure focused team with high levels of interrupts might chose to leverage a ScrumBan approach for visualizing WIP and managing rapidly changing requirements. A nimble microservices development team might find Extreme Programming (XP) fits the needs of the team over traditional scrum models. Does this mean teams don’t have quarterly backlogs? Roadmaps? Or KPIs? No, obviously not but what it does mean is that organizations must truly understand the cultural transformation which must take place for Agile to win, not just focus on dictating practices. Shooting for a one size fits all approach to Agile practices disempowers teams and subtracts from a team’s sense of overall autonomy.

Changing culture is hard this is why many Agile teams and Agile organizational practices fail and, in many cases, become toxic to the organization itself. Agile teams have to rise above the corporate empire building and strive to lead through influence and servant leadership vs being dictators or on the flip side glorified secretaries.