[Bernardo Heynemann] Dream Team – Part V – Delivery

Introduction

In our last installment, we learned that the INews team decided to never let problems grow and instead solve them as soon as they appear. They also decided on having a formal way of solving problems, so that they (and the rest of the company) may benefit in the future.

This time we accompany them as they discuss a topic that is very near to my heart: Delivery.

Release or not Release, that’s the question

John – Morning all! We had a very productive day yesterday, now didn’t we?

All – Yep.

Susan – I’m sooooo sleepy, John! (*chuckles*) Yesterday I went home thinking about some values that I hold dear. I’m not sure this is the time to discuss it, but I really enjoy delivering business value. I’m filled with joy when I realize that my work is helping our coworkers in being more productive RIGHT NOW. How do you guys stand on this?

John – Well, when you study Lean Manufacturing, you learn all about delivering, since they consider anything that is not being used by a customer or adding value to a product to be waste. So, if you are a factory worker, your sole purpose is to drive the product as fast as possible to a client. Please note that as fast as possible takes into account every single quality factor that the customer expects.

Christian – I have a lot of experience in delivering, but we call that releases in my projects. I release as often as I can so I can gather feedback from the community. It is also a very good idea to release as much as you can to minimize the amount of work that goes into a release.

Jake – I don’t have much experience in this area, but something tells me that releasing often makes a lot of sense. I was just wondering how the big guys do it: JQuery, Django, Apache and other projects like that. How do they release?

Christian – I’m not sure how they do their releases, but I love apache’s concept of a release: “Releases are, by definition, anything that is published beyond the group that owns it. In our case, that means any publication outside the group of people on the product dev list. If the general public is being instructed to download a package, then that package has been released.” [1]

John - Yeah, couldn’t agree more. You should release as much as makes sense. Unreleased code sitting in our laptops does no good to our clients.

Jane - Well, when I design a user experience for a product, I have to think a little ahead about how our users are going to interact with it. Imagining their experience is in no way a substitute for learning how they are actually using it, so I too consider it to be crucial to have customers using our product as fast as we can, even if we have to cut a little bit on the feature side.

Joseph - Funny thing, I just purchased Continuous Delivery, a book that was just released (no pun intended). This is one of my favorite subjects. I do believe in continuous delivery. As soon as we mark features as complete, we have them in production. Lean Manufacturing introduces a measure called cycle time, which means the total time between a customer requesting something and the customer getting to use it. What I understand we just agreed, is that we will work diligently to reduce our cycle time as much as we can.

John - That sounds about right!

Me – Once more with time to spare! Let’s play some foosball.

Conclusion

Sometimes we are working in something really cool in our projects. Sometimes we are just fixing stuff. The point here is not what we are doing. It’s who’s benefiting from it.

If you are building software I assume that someone is going to use what you are building. If that’s the case, until that customer starts benefiting, your code is waste.

Cycle time is a very interesting measure, in that it measures your turn-around time to new features, as much as your responsiveness to issues that you or your customers find in the software.

From Wikipedia:

Cycle time variation is a proven metric and philosophy for continuous improvement with the aim of driving down the deviations in the time it takes to produce successive units on a production line.[1] It supports organizations’ application of lean manufacturing or lean production by eliminating wasteful expenditure of resources. It is distinguished from some of the more common applications by its different focus of creating a structure for progressively reducing the sources of internal variation that leads to workarounds and disruption causing these wastes to accumulate in the first place. Although it is often used as an indicator of lean progress, its use promotes a structured approach to reducing disruption that impacts efficiency, quality, and value.[2]

In my humble opinion, the best thing about cycle time is that it is a TEAM metric and not an individual one. That means that if the team collaborate to improve work and reduce waste everyone benefits from it.