Welcome!

From the Author of The Agile Architecture Revolution

Jason Bloomberg

Subscribe to Jason Bloomberg: eMailAlertsEmail Alerts
Get Jason Bloomberg via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: Cloud Computing, Agile Software Development, Change Leadership Journal, CIO, SOA Best Practices Digest, Microservices Journal

Agile Development: Article

Spread the DevOps Virus | @DevOpsSummit #Agile #DevOps #Microservices

Simply changing may not be good enough. Instead, CEOs must ask whether they should make change a core competency.

Finally, the conclusion: part two of my Cortex newsletter, Spread the DevOps Virus in Your Organization. In part one, I called for expanding the hard-fought organizational lessons of DevOps to the rest of the enterprise. Allow people to choose their own teams, and to allow teams to choose their own goals, I exhorted - self-organization being the key to driving agility at the organizational level.

That article, however, focused on the participants on such teams. What does it mean for you as an individual to join with colleagues and organize yourselves into teams that can address the challenges of your organization?

So far so good - but to allow people to choose their own teams, someone has to do the allowing. In other words, management.

If the DevOps virus infects our entire enterprise, will we end up with some sort of Lord of the Flies arrangement, with nobody in charge? Sorry to disappoint - we still need management. Clearly, however, their role transforms as well. Here are some pointers for the managers.

Why Self-Organize?
For CEOs, making such a profound decision to move an entire enterprise's hierarchical structure to a flat, self-organizational model should not be taken lightly. Therefore, it's essential to understand why an organization should - or should not - transform in such a way.

Fundamentally, self-organization is the key to building large organizations that are inherently agile.

After all, given enough motivation and resources, any organization can change from one state to another. The question CEOs must ask is not just whether they should change, but whether it's important for their organizations to be better at changing than they are today.

Simply changing may not be good enough. Instead, CEOs must ask whether they should take Google CIO Ben Fried's advice and make change a core competency.

Today most enterprises are undergoing massive shifts under the name digital transformation. Let's say you successfully navigate this transformation. Will you be done? Of course not - change will be ongoing and even accelerating.

So, is it good enough to struggle through one transformation after another? Or is the more strategic decision to become better able to deal with such change - in other words, to be more agile?

For most organizations, perhaps, the answer is obviously yes - but for other companies, the risks inherent in making change a core competency outweigh the rewards. It may seem that the business and technology disruptions all around us apply to every business to be sure, but yours may be an exception.

Furthermore, self-organization is one of the most important enablers of business agility, but it isn't suitable for every organization. Also, not all of a large organization necessarily has to be self-organized to be inherently agile.

Depending upon the nature of your business, other forms of organization may be better suited for particular departments, especially of that part of your business isn't subject to the sorts of disruptive change that are driving digital transformation for so many enterprises.

The CEO - or perhaps the C-suite with the help of the board of directors - must therefore answer two questions: how strategic is business agility for their organization, and if they decide that digital transformation is essential, then what parts of the organization must transform.

Mind this important caveat: for any enterprise to be successful at their digital transformation efforts, ‘slow' IT must transform. If the existing IT organization cannot rise to the challenge of supporting the digital efforts, then those efforts will fail, plain and simple. See my Cortex Fixing Slow the Agile Digital Transformation Way for more details.

Furthermore, if management decides that business agility is a priority and thus change must become a core competency, then the IT organization must move to a self-organizational model in order to deal better with change overall. Good thing, therefore, that DevOps begins in the IT department.

How to Manage Self-Organization
Once the top brass have determined the strategic need for business agility in the organization, it's time to get management up to speed - from the C-suite all the way down to middle management. Here are the basics:

  • Mind the transition to self-organization. This change won't happen overnight, and won't take place everywhere you'd like it to. Start by encouraging DevOps to flourish. Then follow the contagion model, where the people who are self-organizing get up to speed on what works and gradually draw other people in. As self-organization begins to take hold outside the software development organization, continue to empower people who want to solve problems along the same lines.
  • Stop managing - that is, stop doing many of those things that people might think of as a traditional way of managing. Don't assign people to teams or assign tasks to teams or to people. Also, don't establish success criteria for teams, either - self-organizing teams should do that for themselves.
  • Ensure that you properly distill and communicate the strategic goals of the organization. The challenge here is to keep the focus on the goals but not the ‘how.' You want your people to figure out the ‘how' for themselves.
  • Make sure everybody has the resources (money, people, and technology) that they need. Think of yourself as the butler, ready to serve. If you find yourself in a resource constrained situation, then call upon the teams who are battling for a scarce resource to work together to properly allocate that resource - until, of course, the affected teams realize they can figure out this allocation for themselves.
  • Delineate the necessary constraints, for example, regulatory requirements, security priorities, even technology capacity goals. Treat such constraints as boundary conditions - that is, constraints may not be negotiable, but they're only relevant if teams are butting up against them.
  • Join teams. Anyone in your organization - including management - can join a team, or form a new team if they feel a particular task is important but nobody else is taking care of it. Remember, however, that rank hath no privileges on self-organizing teams. The team may elect you leader or not as they see fit.
  • Some managers will find themselves in the difficult position of having to deal with people who aren't participating or who get kicked off too many teams. The key to resolving this particularly knotty challenge: pay people to leave. In fact, you should have a standing offer to anybody who doesn't like the whole self-organization thing, including managers. In addition, you should base the amount you offer on a feedback loop that optimizes morale and productivity. Offer too little and the bad apples won't jump at the deal. Offer too much and you'll lose too many good people.

Remember, you don't have to follow all these pointers everywhere in your organization, and you have to allow a gradual phasing in of these principles. In the meantime, managers will find that they still have to manage in traditional ways to a large extent. Eventually, however, many pre-existing leaders will find themselves stepping away from their existing roles at some point to allow self-organization to evolve.

The Intellyx Take
While I've aimed this Cortex primarily at managers in large organizations, self-organization also applies to startups. In fact, you could say that every startup is necessarily self-organized, because the founders are always on the first team, thus organizing it from within.

As startups grow, however, they soon reach a critical point when the leadership team thinks they must create a new team that they don't belong to. Get this step wrong and you build inflexibility into your startup.

Fortunately, seasoned entrepreneurs know that early hires need to be self-starters who are willing to roll with the changes so common in the startup environment, which means that such teams will be comfortable self-organizing off the bat.

Large organizations struggling to transition from traditional, hierarchical organizational models to self-organizational models, however, face substantially greater challenges than startups do. The larger the organization, the greater the organizational inertia, as people simply do not like to change their behavior.

At some point, however, ‘we've always done it that way' has to give out to ‘we need to try something different.' Given today's dramatically disruptive business and technology environments, ‘trying something different' is table stakes for any digital transformation effort, and is the first step on the long road to making change a core competency in your organization.

Intellyx advises companies on their digital transformation initiatives and helps vendors communicate their agility stories. As of the time of writing, none of the organizations mentioned in this article are Intellyx customers. Image credit: Pascal and actionvance.

More Stories By Jason Bloomberg

Jason Bloomberg is the leading expert on architecting agility for the enterprise. As president of Intellyx, Mr. Bloomberg brings his years of thought leadership in the areas of Cloud Computing, Enterprise Architecture, and Service-Oriented Architecture to a global clientele of business executives, architects, software vendors, and Cloud service providers looking to achieve technology-enabled business agility across their organizations and for their customers. His latest book, The Agile Architecture Revolution (John Wiley & Sons, 2013), sets the stage for Mr. Bloomberg’s groundbreaking Agile Architecture vision.

Mr. Bloomberg is perhaps best known for his twelve years at ZapThink, where he created and delivered the Licensed ZapThink Architect (LZA) SOA course and associated credential, certifying over 1,700 professionals worldwide. He is one of the original Managing Partners of ZapThink LLC, the leading SOA advisory and analysis firm, which was acquired by Dovel Technologies in 2011. He now runs the successor to the LZA program, the Bloomberg Agile Architecture Course, around the world.

Mr. Bloomberg is a frequent conference speaker and prolific writer. He has published over 500 articles, spoken at over 300 conferences, Webinars, and other events, and has been quoted in the press over 1,400 times as the leading expert on agile approaches to architecture in the enterprise.

Mr. Bloomberg’s previous book, Service Orient or Be Doomed! How Service Orientation Will Change Your Business (John Wiley & Sons, 2006, coauthored with Ron Schmelzer), is recognized as the leading business book on Service Orientation. He also co-authored the books XML and Web Services Unleashed (SAMS Publishing, 2002), and Web Page Scripting Techniques (Hayden Books, 1996).

Prior to ZapThink, Mr. Bloomberg built a diverse background in eBusiness technology management and industry analysis, including serving as a senior analyst in IDC’s eBusiness Advisory group, as well as holding eBusiness management positions at USWeb/CKS (later marchFIRST) and WaveBend Solutions (now Hitachi Consulting).