Micro Focus is now part of OpenText. Learn more >

You are here

You are here

Top 4 obstacles to effective agile methods within DevOps

Phil Simon Speaker/Author, PhilSimon.com

Throughout this DevOps basics series, I've provided an overview of DevOps, tips for communicating clearly in a DevOps environment, and examples of why agile methods ultimately matter.

In no way have I implied that agile methods represent some type of panacea. Sure, they confer significant benefits, but foolish is the soul who believes that adopting agile methods will guarantee a successful outcome. In this way, agile is akin to previous management trends such as Total Quality Management (TQM), lean manufacturing, Six Sigma, and matrix organizations.

Here are the leading drawbacks to overcome when employing agile methods in the DevOps world. Bluntly stated, Drucker was right: The soft stuff is the hard stuff.

1. Slim down: Putting your team size on a diet

Why do boards of directors typically consist of seven people? Why are boards with 20 members or more realizing they need to pare down?

The answer isn't rocket science: larger groups face greater difficulties making quick decisions, and DevOps is no exception. The right team size is critical for agile projects to succeed. It's difficult to achieve the benefits of agile methods with 50 or 100-person teams. Companies like Automattic realize this precept and act accordingly, a point that Scott Berkun makes in The Year Without Pants: WordPress.com and the Future of Work. In Leading Teams: Setting the Stage for Great Performances, J. Richard Hackman advocates for team sizes of three to eight people.

2. More face time: Embracing direct, in-person communication

We've all seen colleagues slam their peers and underlings (maybe even us) via email as they sit in adjacent offices or cubicles. Interminable email chains persist when issues could have been resolved with simple ten-minute conversations.

These types of interactions are the banes of successful agile projects. DevOps folks who hide behind their keyboards are only hurting their projects, groups, and organizations. Agile projects benefit from speed and timely communications, not the usual corporate email rigmarole. Even on colocated or distributed teams, getting together to actually talk is incredibly valuable. As I write in Message Not Received: Why Business Communication Is Broken and How to Fix It, text-based communication isn't nearly as effective as we're inclined to believe.

3. Break the rules: Getting past process and bureaucracy

Waterfall projects tend to prioritize the gathering of requirements, bureaucracy, and processes above all else, including the actual work that needs to be done. On agile projects, work rules. That's not to say that things should be done willy-nilly. Ignoring regulatory requirements like Sarbanes-Oxley is ill advised. Still, an over-reliance on process and bureaucracy will kill most agile projects from the get-go. The priority ought to be the work and the customer (what and why), not the process (how).

4. Take it to the next level: Breaking free of the traditional mindset

Many hidebound organizations are stuck in the waterfall mindset with rigid organizational charts. At these companies, executives can't or won't cede their power to anyone "underneath" them, especially DevOps folks.

By way of contrast, progressive organizations such as Amazon, Zappos, Google, and Facebook launch big projects fast. While there's no simple five-point checklist, these organizations understand that being connected often trumps being in charge. Formal job titles only carry so much weight. What employees can do is often more important than their grades, ranks, and levels.

As the management guru Peter Drucker famously said, "Culture eats strategy for breakfast." Truer words have never been spoken. Pay heed to those words—and the recommendations in this post—and your organization's agile projects will be much more likely to succeed.

Keep learning

Read more articles about: App Dev & TestingAgile