Category Archives: Agile and DevOps

Agile, DevOps and Design Thinking – How do they relate?

This week I had several discussions 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 (or if there is then certainly not everyone is referring to it 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 organisation through closer collaboration and by making delivery less black box and more white box.

DevOps
I personally like the following definition:
“Using governance and automation techniques to optimise 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 organisation to achieve the right balance between stability or reliability and the required changes to deliver to the end-customer.

Design Thinking
This is the process of identifying and defining what a solution should look like by emphasizing with 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 – which I will also use to start my definition page here on the blog – lets look at how all this relates to each other. I will start with a picture that I started to use a while ago:
House of AgileFor 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 lets dig a bit deeper.

So let’s look at the first two pillars: Design Thinking & 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 1-2 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 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. In a later post I will describe another aspect of this phase which can be called Design Slicing – the ability to define logical slices that provide value by itself.

Let’s move to the second set of pillars: Agile and DevOps.
Here is becomes more complicated. The previous comparison we could simplify to Design Thinking = What, Agile = How, for Agile and DevOps we wont 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. Here is now where I take a pragmatic approach, for me the methodology aspects are sitting within the Agile space and seeing Post-It notes, burn-up graphs and stand-ups are indications that someone is adopting Agile – whether successful or not requires more than Post-Its by the way. 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, by 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 that there is a lurking problem that requires addressing as well and that 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 measure against that plan.
Workforce management – How can you change from assembling people for projects and disbanding the team at completion to standing teams that work flows towards. And how 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 of the IT operating model.

And of course we should talk about the cloud – there is lots to say here, but lets 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).

Longest post so far, so I will say goodbye for now. Post your comments – I am looking forward to a controversial discussion of the above.

Are we Agilists in danger of making the perfect the enemy of the good?

perfectOver the last year or so I have had lots of good robust discussions with other Agile coaches and one thing started to worry me. I heard “But that is not Agile” or “But that is not REAL DevOps” more and more frequently. While I agree that we should always strive for better and better performance, the absolutes seem to me counterproductive. Two topics close to my heart seem to cause this kind of reaction more often than others.

 

SAFe – The Scaled Agile Framework
There is lots of discussion on the internet about SAFe and why it is or why it is not really that Agile. Most organisations that I talk to are nowhere close to the maturity that you assume when you see the SAFe framework. I am sure that there are companies who are further down their Agile path and think that SAFe is very restrictive and old-school. I have to say that most people I talk to would be extremely happy if they could achieve the Agility that SAFe can provide. And it is a framework after all, a bit like a scaffold that you can use to move forward from the old waterfall ways into a more Agile enterprise without throwing everything out. And yes once you think that SAFe is not challenging your organisations and you see opportunities to become even more effective go ahead – push yourself further. For now I quite happy to use the SAFe framework within large organisations to help me speak a language my clients understand and to push them a bit further on their journey. I will have to admit that probably have not spent enough time with the other scaled agile ideas to judge them all – and perhaps writing this blog can be a motivation to do that. For now SAFe is my go-to framework of choice and even those who argue it’s not really Agile, I think even those would agree that many organisations would be more Agile if they had implemented SAFe than they are now – and that’s good enough: For now!

DevOps
So many organisations and projects I encounter do not have the right technical practices in place that allows them to deliver solutions effectively. Practices like Configuration Management, Automation of Build, Deployment and Test, and Environment Management I think belong under the big headline of DevOps. So when I then talk about DevOps practices with peers at conferences and describe that in large organisations I often recommend a DevOps team to start with, I hear “But that is not what DevOps is about”. The so often quoted cultural barriers between Operations and Development in large organisations makes it simply impossible in my view to embedd an operations guys in each development team. And to be honest there are often many more development teams than operations folks who could be embedded. So why wouldn’t I then create a team with representation from both sides to begin with and to get the best guys into that team to solve the difficult technical problems. After all that what Google has done with their Engineering Tools team. I think that is a valid step and yes perhaps afterwards we push this further, but for now most organisations that I have been working with can gain a lot from good practices being implemented through a DevOps team. Having a DevOps team does not mean we don’t want to change the culture, it just means we want to do this one step at a time.

Picture: Perfect by Bruce Berrien
taken from https://www.flickr.com/photos/bruceberrien/with/384207390/
under Creative Commons license

Welcome to Not A Factory Anymore

Hi everyone,

this is my first blog post. Yes I have finally made the leap into the blogosphere. Over time I will blog here about software delivery, agile, DevOps, Continuous Delivery and anything else that grabs my attention.

But first things first: Why ‘Not a factory anymore’?

I think many of us have heard over time the analogy of Software Delivery with a factory. In my mind that analogy is not accurate anymore and sends the wrong image. Software is not being produced, it is being created, it’s a creative process.

On my blog I will share with you my thoughts on everything that I think shows why the factory model is not appropriate and giving this blog that name leaves no doubt in the reader’s mind, where my allegiance lies in regards to how software based solutions should be delivered.

Looking forward to engage with the community via this blog and to see you around at conferences and meetups