Focus more on being agile than doing agile

August 1, 2019

A blog post Mike Kavis, managing director, chief cloud architect, Deloitte Consulting LLP

Focus more on being agile than doing agile

A framework is only as good as the people, processes, and organizational structures that use it.

Someone posted an article on LinkedIn the other day claiming “Agile is Dead”. The comments that followed were more interesting than the actual article. Many people were bashing agile frameworks. It is no secret that organizations have spend a lot of money on doing agile and many times never really achieved being agile. Right now, SAFe (Scaled Agile Framework) is trending and many of my clients are implementing it. But methodologies and frameworks are nothing more than a set of guiding principles for delivering software. At the end of the day, doing agile comes down to the three things:

1. Culture
2. Architecture
3. Operations

Culture

A framework is only as good as the people, processes, and organizational structures that use it. Silos with competing goals always trump frameworks. Each silo creates an unnecessary handoff and increases wait time. Too often, additional processes get added to deal with the interaction between silos.

Then there is the people part. I am old enough to remember when all projects managers had to be PMBOK certified which trained project managers how to follow a set of processes and procedures (framework) to navigate the waterfall methodology. When we moved to agile, all these people were retrained and became certified scrum masters. Unfortunately, they still had the old command and control, sequential mindset and most agile efforts became “Wagile” — waterfall with daily standups.

The point here is it takes much more than a few training classes or certifications to change the mindset. This is a transformation and requires an investment in organizational change management to get the value out of the new frameworks.

Architecture

All the process in the world can’t fix a bad architecture. To do agile, one must have an architecture that supports being agile. Characteristics of an agile architecture include:

•  Built to change, not built to last
• Software decoupled from hardware (loosely coupled)
• Independence — individual component failures do not cause the entire system to fail
• Service-oriented — opposite of Monoliths, the system is made up of small parts that can be deployed separately
• Scalable — system is built to scale automatically
• Recoverable — system is built to recover from its last point of failure without human intervention
• Testable — system supports testing hypothesis with methods such as A/B testing, feature flags, chaos engineering, etc.

The more a system supports the characteristics above, the more agility can be achieved. Not all systems need to implement all of those characteristics, but each characteristic can reduce manual intervention, allow for more frequent deployments and quicker MTTR, reduce widespread system outages, and provide for better availability. It can also reduce the amount of unexpected work which is probably the biggest single issue all agile frameworks struggle to deal with.

Operations

Even if you have an agile architecture and your agile framework is being executed flawlessly, if your operations people and processes are not in alignment, the whole house of cards will come tumbling down.

There is a lot disruption in operations these days. DevOps has played a huge roll in getting developers and operators collaborating better. Operations is now being thought of earlier in the lifecycle and teams are designing for ops. Companies are reevaluating their operating models and investigating newer practices such as Site Reliability Engineering (SRE), accepting that testing in production is a good thing (if done right), moving from reactive to proactive operations, embracing observability, and much more. As we move to more agile architectures, it’s common sense that we need to embrace more agile methods of operations.

Characteristics of agile operations:

• High levels of automation for both infrastructure and deployments
• Operators knowledgeable about the systems they are responsible for
• Transparency
• Robust logging and monitoring frameworks
• Blameless post mortems
• Continuous improvement and learning
• High levels of collaboration with development - sometimes the builders are also the operators
• Operations’ goals aligned with the goals of the products/services
• Immutable infrastructure — kill it and spin up new

The list goes on and on. I have yet to see a framework that even mentions most of these characteristics. The frameworks focus mostly on how to manage backlogs which is important, but if the software and the operations of that software does not promote agility, the framework is not going save you.

Summary

Organizations should focus more on being agile rather than doing agile. Being agile requires more than a framework. It is a mindset and it should be applied everywhere, not just in Dev and Ops. The Security and Governance teams need to be agile. Procurement can’t take six months to procure a software product. Decisionmakers need to come to conclusions in a timely manner. Processes that take forever should be redesigned. Approvals should not take forever. You get the point.

Being agile is a cultural issue and should be treated as one. If you want to make your organization agile, adopting a framework is only one piece of the puzzle. In fact, many teams that I have seen that are truly agile use no framework at all. They do a good job of managing a backlog and they do a great job of collaborating, writing good software, automating everything they can, and recovering from issues quickly. At the end of the day, agility can be measured by customer satisfaction. If the customer is getting their demands met, the system is reliable, and issues are resolved quickly, it really doesn’t matter what framework you use.