‘The Continuous Delivery IT Team’ fallacy

Summarizing

Considering Continuous Delivery something for your IT department is throwing your money out the window when doing an Agile Transformation program. If you want to do so, make sure you throw it into my direction. IT is a business concern, Continuous Delivery is a business concern.

Over the past couple of months I did a series of awareness sessions on Agile, Continuous Delivery and DevOps at a large client of mine. As is rather common, also at this organization the initiative to move towards Agile ways of working, Continuous Delivery and a longing for DevOps is with the software developers. This makes perfect sense when you think of it, because it's the developers that want or rather need to make changes and the pace by which they have to deliver changes is only increasing. But I guess I don't need to tell you this.

But Continuous Delivery (or Deployment for that matter) is only possible when you don't consider it a software development thing. There really is no point in spending any time to move to Continuous Delivery when you are not planning to do it broadly. I'll get to that in a second.

During these awareness sessions, which I do with colleagues from the same team, we discuss with non-developers like risk officers, sys admins, project managers, architects, test consultants, etc. we outline what Continuous Delivery and DevOps mean within the context of my client's organization. It's a common story and I won't bore you with the details, but obviously we touch upon the benefits of small increments, feedback loops and so on. And the fact of the matter is that our story actually does sound like it's the perfect thing. And we consistently get the question: "So, really, it can't be all awesomeness, so what's the catch?". And in the rare occasions we don't get this question, we still answer it.

The biggest problem with Continuous Delivery and everything following from it, is that it is not a software development thing, or even an IT thing. When you think so and still go down that road, spare yourself the frustration and disappointment, drop me an email asking for my IBAN number and transfer the budget for your transformation project into my account. At least one person will be happy with you spending that money.

And yes, even when you think it's an IT thing, you're better of giving me that money. This is what I call:

'The Continuous Delivery IT Team' fallacy

Let me explain. First of all, let's make sure you understand what I consider Continuous Delivery. It's the process that produces a product that results in business value in order to be able to sustain the organization up to the point that it can be delivered to a user and it will be delivered to a user as soon as possible. It's not a perfect definition or even a formal definition, much because there's so much more to it. But what's important is that it defines work on a product as being done, when it is ready to be delivered to a user. The actual delivery is an explicit manual step which is decided by the Product Owner to be taken as where the rest of the process is preferably fully automated. This as opposed to Continuous Deployment, where the delivery to the user is also automated and hence triggered by the developer when committing his code to the source code repository. Again, this is a definition close enough to what it is and fitting the purpose of this post.

With Continuous Delivery and agile working in general you want to receive feedback for what you've been doing as soon as possible. And preferably you want this feedback to be such that for one you know that you've done well and secondly you're actually contributed to the bottom line of the organization you work for. This is why we like to work at the granularity of user stories and epics and delivery on a per user story or at least on a per epic the changes to a user.

As you now understand, for every single user story or at least epic, you need to do everything that needs to be done for a release, because you're delivering to a user. Somebody is going to actually use that little piece of software you've worked on with such a passion. Fact may be that the complexity is limited because increments are small, still you need to release new or changed software. And there's the catch.

With software delivery, or product delivery in general, it's not just the product development team that's involved, or more specifically the software development team. It's other teams and people involved as well. Think about marketing, legal and compliance, worker's associations, security and risk management. These are all teams that are not part of the IT department. And no, security officers are not part of an IT department, and in case they are, they most definitely shouldn't be. And the biggest catch of all, the 'business' needs to be involved from day -1. Unless all of these different roles, teams, people, stakeholders, however you want to call them are on board and work in those same small increments, not becoming a bottleneck and automate as much as possible, your Continuous Delivery efforts are a waste of everybody's time and your organization's money.

Back to your 'business', it's them that request for features and not the user. It's them that pay for the development of the product not using it per se. When that 'business' is not capable or willing to define the product's features such that they can be delivered in tiny chunks, than you're out of luck and not much will come from Continuous Delivery in your organization.

The Product Owner is key in all of this. Being the hinge between the Product Team and the rest of the world, the PO is the single one person that can and must ensure that the product is delivered incrementally, with business value visibly added with each increment. PO can't do this, you've got yourself some trouble. The PO, at all times, must be able to relate every single feature, one way or another, to an improved life for the user of your product and therefore a positive effect on the organization's bottom line.

So, Continuous Delivery is not an IT thing, it's a business thing. And don't let anybody convince you otherwise. Being as it is, moving towards an Agile way of working and Continuous Delivery or Deployment, in fact would mean that you no longer consider your IT as being delivered by a separate IT department, but as an integral part of your business.

This does make perfect sense, considering your IT as part of your business I mean. It makes perfect sense because more and more business are all about information and are run based on information. IT is no longer a tool, like a glorified typewriter, it is in fact what is producing business value. No IT no business.

Thanks once again for reading my blog. Please don't be reluctant to Tweet about it, put a link on Facebook or recommend this blog to your network on LinkedIn. Heck, send the link of my blog to all your Whatsapp friends and everybody in your contactlist. But if you really want to show your appreciation, drop a comment with your opinion on the topic, your experiences or anything else that is relevant.

Arc-E-Tect