I had several discussions recently in which I had to explain how I see the relationship between Agile, DevOps and Design Thinking. Of course there is no clear differentiation and, for that matter, definition of these terms (even if there is, certainly not everyone is referring to them in the same way). Let me start by defining these terms in my context:
Agile (in the context of Agile software delivery)
A set of adaptive methods to deliver software-based solutions based on the Agile Manifesto. It is an umbrella term for delivery methods like SCRUM and Kanban and for engineering methods like XP. From a cultural perspective, these methods are meant to bring the customer or business stakeholder closer to the IT organization through collaboration and by making delivery less black box and more white box.
I personally like the following definition: “Using governance and automation techniques to optimize collaboration across development and operations to enable faster, more predictable and more frequent deployments to market.”
From a cultural perspective, this is bringing down the barriers between the development and operations parts of the organization to achieve the right balance between stability or reliability and the required changes to deliver to the end-customer.
This is the process of identifying and defining what a solution should look like by emphasizing the subjects in question, by creatively solving the problem at hand and by analytically testing whether or not the solution is feasible from a technical perspective and in the problem context (viable for the customer and the business).
Now that we have the definitions out of the way, let’s look at how all this relates to each other.
For me, this explains the relationship quite nicely, but not comprehensively. It shows how the three ‘pillars’ that I described above work together to hold up the IT operating model and how it is based in the cloud. Clearly there is more to it than this picture shows and what is missing are the overlaps and differences. This all sounds very esoteric, so let’s dig a bit deeper.
Let’s look at the first two pillars: Design Thinking and Agile.
If you pick up the original book by Ken Schwaber, it pretty much starts to describe what happens when the product owner comes to the team with a list of prioritized items to implement. When I first read the book I had the same reaction that probably many of you had – “If Agile tells me ‘How’ to implement something, how do I find out ‘What’ to implement?”
Design Thinking can be an answer to this question. There are some groups that are really good at this like d.School or Fjord. In my travels, it has often been a slightly less elaborate activity like a one- or two-week Discovery phase where IT and business come together to define the solutions, but ideally you use Design Thinking to come up with great solutions. In my MBA I had the pleasure to work with an expert in this field and to go through a Design Thinking workshop and it certainly provided a very different perspective on the problem at hand.
Now, the second set of pillars: Agile and DevOps.
Here it becomes more complicated. The previous comparison we could simplify to Design Thinking = What, Agile = How; but for Agile and DevOps we won’t be able to make such a clear differentiation. Really good Agile adoptions focus on the cultural change required, the methodology changes that come with SCRUM and Kanban among others and focus on the technical practices like the ones that XP describes. DevOps in a similar vein talks about cultural change and technical practices. This is where I take a pragmatic approach. For me, the methodology aspects are sitting within the Agile space and things like Post-It notes, burn-up graphs and stand-ups are indications that someone is adopting Agile. If someone is changing the way software is being coded and deployed and the change is much less visible in the offices (perhaps you can see green and red build lights) then we are talking about DevOps. This differentiation also allows me to break with the conventional wisdom that DevOps and Agile go together. They are definitely better together (like a good meal and a good wine—great individually, even better together); but you can get value from one without the other, just not as much as you could from both of them working together. If I force myself to simplify the difference between the pillars, I would say Agile = Bringing business and IT together supported by methodology, DevOps = Bringing development and operations together supported by technical practices.
I have not spoken about the IT operating model and the Cloud. Let me spend a few words on this as well, starting with the IT operating model. One of the things I notice when I speak to clients is that no matter how well their Agile and/or DevOps adoptions go, there is a lurking problem that requires addressing and that problem is the IT operating model. Again, this is a term that can mean many things to many people. I will highlight a few aspects of what I mean. If you really change the way you deliver software-based solutions by using Agile, DevOps and Design Thinking, you will likely run into challenges with your existing IT operating model in the following ways:
Funding – Your funding and budgeting process might not allow you to progressively learn and adapt but rather requires locking things down early and measuring against that plan.
Workforce management – How can you change from assembling people for projects and disbanding the team at completion to standing teams toward whom work flows? And what should these teams look like – teams representing value flows, a central DevOps team or federated accountability, release trains a la SAFe,…?
Incentives and commercial constructs – How do you make sure that all your employees, contractors and delivery partners/systems integrator share your goals and can support the new way of working?
Roles and responsibilities – How do you need to change role descriptions to make the new way of working stick?
All these are aspects that are not necessarily covered in your Agile methodology or DevOps practices, but that require thinking about and adjusting. And I like to consider this a change to the IT operating model.
And of course, we should talk about the Cloud—there is lots to say here, but let’s leave it with one sentence for now: To achieve the ultimate flexibility and speed to market many aspire to, you will have to make effective use of the Cloud (private, public or mix).