We All Care About The Loop!

Continualoop provides a name for all of the things that I care about and have been focusing on in my 20 year IT career: Continually improving software delivery teams.

To start with I care about context. I'll start by declaring that we all care about software delivery loops.

But what is a software delivery loop you might ask?

I'm sure you will be familiar with what is being communicated with this picture.

Figure 1 - Software Delivery Loop
What this is showing in simple terms is the activities commonly involved in software delivery. We plan the features that will be supported by our software, then we code and build the software, before testing it, releasing and then deploying it. Once it is available to the consumers of our software we will operate it and hopefully measuring how well the software is meeting the needs of our consumers. We close the loop by taking this feedback into account in planning future releases of the software.

Sounds a lot like an SDLC?

I want to focus on the journey around this loop to deliver software. And I talk about the loop itself as the infrastructure that supports this journey - the tools and SDLCs. And most importantly I want to be able to talk about what makes for a good software delivery loop.

A good software delivery loop needs to be judged based on the needs of the consumers of the software delivered by the loop, as well as the needs of the producers of that software.

The consumers care primarily about the outputs, speed and costs of the loop:

  • Does the loop deliver solutions that bring business value?
  • Are we able to get around the loop quickly to deliver the next set of business value?
  • Does the loop deliver this value cost effectively?
The producers also care about these things. But additionally they care about the experience of living in the loop:
  • Does the loop allow me to be productive?
  • Does the loop operate without unnecessary complexity?
Although the software delivery loop is supported by tools and automation, it is fundamentally people that power the loop and we need to make sure that we take their needs into account.

Simple software delivery loops that allow teams to be productive make for happy delivery teams. And happy software delivery teams are better at producing good software that meets the needs of the consumers.

Continualoop is about thinking about how to improve software delivery loops. About being part of the conversation on what needs improving and how to do it. About teaching and learning. About making a difference. About sharing what is learnt.

In future posts we'll be exploring many aspects of the theme of continuous improvement of software delivery.
  • What do good software delivery loops look like? And equally what do bad software delivery loops look like?
  • How can we make software delivery teams happier by ensuring they live in a good delivery loop?
  • How do practices like Agile and DevOps help improve our software delivery loops? And what other practices add value?
Please follow @continualoop to hear more about my thoughts on improving software development and delivery. Let's improve IT!

Copyright © Continualoop Blog 2017. All rights reserved.

Comments

Post a Comment

Popular posts from this blog

DevOps Analytics: Five Steps To Visualise Your Jenkins/UrbanCode Deploy Delivery Pipeline In Action!

Image
So you've got your delivery pipeline all set and delivering releases. Developers are delivering code into source control, lets say Git as an example, and from there you're doing automated builds in Jenkins, and using IBM's UrbanCode Deploy to automate deployments. Everyone is happy because releases are getting out the door quicker than before and with less effort! And the automated tests you've added to the pipeline are helping weed out issues earlier, so quality is improving as well. Figure 1 - A common representation of a software delivery pipeline. Image downloaded from http://www.logigear.com/magazine/continuous-delivery-and-devOps/mega-trends-in-testing-continuous-delivery-production-line-and-the-deployment-pipeline/ in November 2017. But one thing that isn't as easy to do is get a sense for what is happening in your pipeline. Both from the point of view of seeing where a particular set of changes are in the pipeline, as well as getting a sense for
Read more

A Solution For Tracking and Monitoring Multi-Stream Processes Using Rational Team Concert

Image
I'm going to assume you're already managing your plans and work items in Rational Team Concert (if not, read more here: https://jazz.net/products/rational-team-concert/ ). Have you wanted to track the flow of work through a set of steps in a defined multi-stream process using RTC? I've recently implemented an extension to RTC for a customer that does just this and I thought I'd write about that here. I'm not able to share the code for this (sorry), but hopefully these notes will be useful for anyone looking to implement their own solution. Figure 1. - Simple example of a "defined multi-stream process" In figure 1 we see a simple example "defined process" which exhibits the following characteristics: With the exception of the first step, all other steps are dependent on their "upstream" steps completing before they can start. Each step is owned by a team i.e. team members of that team are able to claim the step to work on
Read more

Simplify Software Delivery Using Containers and the Cloud

Image
Wouldn’t it be great if your teams could just focus on the coding? After all, we want to be innovative and write great software! Unfortunately, most really interesting software requires you to think about other things. How do you package up and deliver all the components of the solution How do you take care of all of the dependencies? How do you make sure the end-to-end solution is scalable? How do you make sure that the solution is easy to manage? Answering these questions requires you to consider a lot more than just “coding the logic”. In times past, the only software that had these sorts of demands was large scale business IT systems. And to meet these demands they made use of a great platform: the mainframe. Unfortunately, the mainframe did a lot of this at the expense of choice. The software had limitations – all UIs tended to be of the “green-screen” variety. All your code was written in Cobol. Integration was with CICS, as was data storage and retrieval. But you
Read more