The Agile Architect
Can Agile Truly Scale To the Enterprise?
What makes Enterprise Agile different from plain ol' ordinary agile? Our Agile Architect returns with a series of columns exploring what we can gain from enterprise agility.
You may have noticed that I've been absent for a while. In truth, I've been off on a grand adventure. Long time readers of this column know about my philosophies around agile development and how part of my job at WWT Application Services (formerly Asynchrony) has always been to help our customers in their adoption of agile. Many columns have been dedicated to my experiences and those of my colleagues.
In the latter half of last year, we began discussions around how we can expand our software-related offerings. Out of these discussions came the idea to turn our agile adoption efforts into an independent practice, building on the strengths of our existing organization, but with dedicated staff, service offerings, and all of the organization infrastructure that goes with it. And I get to lead this initiative!
So as you can imagine, I've been rather busy. But now, my head is finally above water and I'm able to dedicate time again to this column with a renewed vigor and, at least for the short term, focus on agility at the enterprise level.
Why this new focus, you ask? Because more and more, we are seeing that most companies have already adopted agile in some form and at some stage of maturity at the team level. They are now asking how they can move their entire enterprise to agile. And of course there are the companies out there that are happy to market their latest and greatest branded methodology for enterprise-scale agile.
Over the next series of columns, we'll be looking at these methodologies to learn about their strengths and weaknesses as well as share some pragmatic lessons-learned gained through first-hand experiences by myself and my colleagues.
But before we get into the "how," let's talk about the "why."
Why Do We Need Enterprise Agile When We've Already Got Plain-Ol' Agile?
Plain ol' agile isn't so plain anymore. It has increased in scope significantly since its inception. The fundamentals of the Agile Manifesto are still in place, focusing on delivering working software, embracing change, nurturing technical excellence and enabling self-organizing teams as the principle engine of delivery. The manifesto itself was worded and organized around the concept of a team with a project. So naturally, the methodologies that inspired the manifesto or were born from it were team focused.
With the team level fairly mature, the agile community began tackling the questions around enabling these teams by transforming the rest of the organization. Instead of a focus on delivering value through working software, the focus shifted to how the organization could deliver business value, with software or otherwise.
And this brings us to enterprise agile. With large organizations, once you get beyond the team level, there may be hundreds, thousands, even tens of thousands of people involved in delivering value. In addition, the complexity of the world has increased with the multiplicity of technologies, software, firmware, hardware, virtualization, cloud, mobile, and of course the Internet of Things (IoT).
Given all of this, what needs to be added to plain ol' agile to make it enterprise scale? We'll be talking about all of these in more detail in future columns, but here's my personal list in order of importance.
- Align Around Value Streams. This means that you have to know what your value streams are and their priority with respect to one another. For your entire business to be an engine of value, every part of it must know how it aligns to the current set of value streams.
- Break Dependencies Where possible. Otherwise, manage them. Breaking and managing dependencies is a subset of simplifying complexity (#3 below). But it is important enough to be called out on its own. Dependencies occur with everything we do. They might be organizational, between value streams, between technologies, schedules or people.
- Ruthlessly simplify complexity everywhere. Complexity begets more complexity. Spend effort simplifying rather than dealing with increasingly complex situations and solutions. Finding complex solutions to complex problems is easy. Finding simple solutions to complex problems is extremely hard and takes extra effort. This will require you to challenge yourself on how you think about all aspects of your business.
- Enhance communication. As with everything important in an organization, communication is key. The agile manifesto professes "Individuals and interactions over processes and tools." As organizations become larger and more complex, this becomes a real challenge. Don't give in to the perceived inevitability. Take on the challenge.
- Fight, fight, fight against rigidity.It would be easy to fool ourselves that we are getting more enterprise-agiley by putting in place disciplined structures and rules around how everyone in the organization acts and interacts. After all, if everyone understands exactly how the game is played, there can be no miscommunication or misalignment, right? The problem is that this can easily lead to rigidity, impeding the very purpose of agile which is the ability to respond quickly to change while continuing to deliver value.
- Minimize unpredictability. Predictability is important but not at the expense of agility. To focus on minimizing unpredictability is to recognize that it will never be eliminated. Instead, we need to work in a way that accepts unpredictability as part of the fundamental nature of the work we do.
What's not on the list?
- Culture: It's already in plain 'ol agile. But it does get harder as the organization gets larger.
- Cadence: While a fundamental part of some enterprise agile methodologies, cadence isn't required although it might be useful for minimizing unpredictability.
- An adoption roadmap: If adopting agile for software delivery is like climbing the Empire State Building, adopting agile across the interconnected enterprise is like climbing Mt. Everest. You have to find your own path.
This column has a fundamental flaw. Have you noticed it? We discuss above how enterprise agile is different from plain ol' agile but we never discuss what size the organization needs to be to require enterprise agile. That's because enterprise agile has nothing to do with the size of the organization.
We'll talk about that next time...
Dr. Mark Balbes serves as Vice President, Architecture at WWT Application Services, and leads multiple Agile projects for Government and Fortune 500 companies. He received his Ph.D. in Nuclear Physics from Duke University in 1992, then continued his research in nuclear astrophysics at Ohio State University. Dr. Balbes has worked in the industrial sector since 1995 applying his scientific expertise to the disciplines of software development. He has led teams as small as a few software developers to as large as a multi-national Engineering department with development centers in the U.S., Canada, and India. Whether serving as product manager, chief scientist, or chief architect, he provides both technical and thought leadership around Agile development, Agile architecture, and Agile project management principles.