Reduce the friction of digital transformation

TLDR

Over the past few years in consulting I have found myself being brought into opportunities around innovation/disruption/new product development, and agile transformation. In most occasions this is tied to a digital transformation initiative. Without discussing the nuances of these terms, I usually end up in a situation where the core competency the organization is missing is business agility. I have largely come to the point of view that if you want to achieve business agility, instilling an business and technical architecture that makes it as easy as possible to build and deliver new products is an enabling capability. In this article, I'm going to focus on people, structure, and technology of product development teams, and how this creates a foundation for organizations to build on in their journey towards business agility.

Preface

I came across an article on medium.com that had a very catchy title "No one should write Terraform". Being a fan/developer of Terraform, a DevOps evangelist, and an adherent to "Infrastructure as Code (IaC)", I wanted to understand the author's point of view. The author hits on a bunch of topics (agile, DevOps, software development, culture) , but essentially he was saying that the (relatively) new AWS Cloud Development Kit (aka CDK) for Terraform is a positive step forward in the DevOps tooling and maturity landscape, and teams should use that, instead of Terraform directly. I responded to the writer and opined on agile and the role DevOps has to play in that. Interestingly enough, that one response got what I consider to be a phenomenal number of "fans". So I thought that I should probably expand on my thoughts and since it applies directly to what I tend to do in my everyday job, I thought I would do that here.

Then I came across this article, by Camille Fournier , that touches on nearly everything I feel about this domain of digital/agile transformation, and/or innovation/disruption, and the very important role software development and IT organizations have to play in that transformation. So instead of writing the same article again, I thought I would simply highlight the aspects which I feel are critical, based on my experience working in, leading, and now consulting to IT organizations over the past 20+ years. Basically, I'm being the biggest advocate of Camille's writing that I can be.

[One caveat so all my infrastructure friends don't immediately unfriend me: I know there are reasons for certain Security & Infrastructure individuals to be independent, and where ticketing systems might be of value. Those are unique use cases that need to be addressed, but not relevant to the challenge(s) we are discussing herein.]

The highlights

1. "Your engineering (the Sec, Infra, Ops teams) culture needs to change". Camille just comes out blasting here. I couldn't have said it better. More on this below when I talk about the importance of User Experience (UX).
2. Product Managers are the first part in your value chain. Camille is getting to the point that everyone has to see themselves on the same team.
3. Certain IT teams and processes being fronted by ticketing systems is an anti-pattern, especially if they are critical to delivering products. I'm not saying that ticketing systems are not useful - there are many good use cases for them. But in my experience, working on the problems we are talking about here, my advice at this point is to remove any ticketing systems from product development processes.
4. An excess of Project Managers and/or Agile Coaches usually is a "smell" to me. Let me expound on this for a moment. I've been asked to do agile transformations, and usually clients either have had "agile coaches" or wanted one (or many) from my company. It makes my spidey-senses tingle when I hear this. If the role is an integral part of the Product Development team, then it might be a value-added role. For example, they are managing the backlog, facilitating story/feature/epic elucidation, understanding architecturally-significant epics, facilitating retrospectives, helping with estimates, and/or creating the necessary metrics (ONLY for the dev team), then it can be value added. If they are just doing reporting and compliance (for some matrixed, or external group), I have usually found this person to hinder development velocity and not be effective, at all.
5. Building on item 4, this speaks to the type of people your hire and how you develop talent. There is always room for experts and specialists, but they have to be able to communicate with people, and express their point of view, and engage in a customer/user centric way. There is less and less need for people you treat like mushrooms.

Camille hits on many good points. I would like to add the following:

1. Product Teams create products - this is a big part of your value chain. In my experience, companies have largely integrated Product Teams with Development teams. I see generally good progress here. The people, process, and organizational structure in which they operate is your business architecture. Your business architecture can either be enabling or hindering. This is my point of view - your business architecture either creates a culture of creation, or it doesn't.
2. Digital transformation has to include IT asking itself "how can we be the easy button for technology?" Don't let Security, Infrastructure, Operations, (aka SecInfraOps) hinder your value chain. In my experience, agile/digital transformations can be challenged here. The hard part is being the easy button while being secure, compliant, and reliable. It can be done.
3. DevOps is all about making Development and Operations teams work together. It's time to move to ProdUXDevSecInfraOps. Since that is way too laborious to type, I'm now coining this the #alltogether phase of DevOps. The appropriate people from SecInfraOps teams need to be a part of the product development teams, be a part of the backlog, attend agile ceremonies, estimate, and commit to their stories, just like the Dev team does. I can't see any good reason for them NOT to be. I say that fully realizing you are probably thinking "they need to do other stuff too". I get it, and I realize this is probably a big step for many people. There are baby steps that can be taken.
4. Notice that I added UX near the front? Hopefully the Product Manager knows this, but I routinely see this being forgotten or left out. For details, see the late Clayton Christensen's book "Competing Against Luck". He presents a great case for understanding the Job to be Done (JTBD) first. Everytime I have applied this technique it has resulted in huge success for team, the product, and my client. In some instances, hundreds of millions of $ of success (zero hyperbole intended).
5. At one point in the DevOps movement, there was this concept of #noOps. The obstacles are both organizational and technical, but they can be overcome, and it is so worth it. When I led a team doing this, the dev people came back to me and said "every dev should be a part of building out the #noOps capability - it will make them better devs". This is a much longer story - contact me if you want details. And we did this for one of the largest companies in the world, so this is NOT confined to small, private companies. The major cloud platforms enable this. And a HUGE callout to Datadog (they are the easy button for #noOps).

The role of Cloud

To be clear, these business architecture problems have existed way before the cloud. This point of view started when I was a team member developing software for a large company. But the cloud presents a very big opportunity if you realize the transformation required. For your technology architecture, I believe the cloud can be the easy button for your company - full stop.

The dominant cloud platforms (AWS, Azure, GCP) bring together many capabilities that can make agility easier. The cloud can be your easy button for technology IF you enable your teams to use it to its fullest capabilities. If you break it up into the typical silos present in your current on-premise architecture, you will probably devolve into cost-focused arguments about which is cheaper (cloud vs on-premise), or why nothing seems easier or faster in the cloud. And all the executives in the company will wonder "why we spend all this money on cloud" and other really hard questions. These questions are another "smell". Instead, focus on the transformational value that can be attained.

To be successful with the cloud your ProdUXDevSecInfraOps teams need to be empowered to easily provision, prototype, build, test, deploy, revise, and monitor their products in the cloud. They shouldn't be filing tickets to get stuff done by someone else who is not part of their product backlog. You need "Digital Architects" who are thinking about this, and creating an environment in the cloud that enables this. And it has to be secure and reliable - I am not advocating for the so-called "wild west" infrastructure nightmares.

My point is this: Don't let people exist in silos, especially if they are critical to having products come to life - they should be part of your value chain. Next, engineer your business and technical architectures with this guiding principle: Minimize the friction in your value chain for the ProdUXDevSecInfraOps teams.

Let me know your thoughts. Questions about how to do this? Drop me a note on LinkedIn. I write on medium as well, but typically not about work stuff. Besides myself, my organization has many brilliant people who also have great perspectives on this subject (e.g Wilson Tarleton )

Parting thoughts

This article was not meant to holistically address what it takes to achieve business agility. Two topics come to mind:

• The role and definition of enterprise architects. That's another article.
• How you setup an innovation funnel, idea evaluation process, and create a safe place for ideas to be tested, and how you tolerate failure. Again, another topic for another day.