AUTHOR: FEDERICO KEREKI, TECH MASTER
A few articles ago (in note #4 of this series) we spoke about “Doing less”, and we mentioned Count Basie, known for his sparse piano playing… but let’s now go a bit further, and fully consider dropping something altogether! George Carlin, the humorist (and the only not-jazz-player person we will be quoting) once gave a key concept regarding the blues, and the need to know why you have to do something.
Thinking about the process of agile development, many frameworks (think Scrum, for example) include the provision of delivering a new version of the system (or, at least, provide some new functionality) at the end of each development period (“sprint”, in Scrum’s parlance)… well, if we are thinking about the possibility of dropping something, what about doing away with such deliveries, and opt, instead, for a continuous flow of deliveries? (Following Carlin’s comment… you know you have to deliver, but why should you do so only at specific times?) So, why not consider Continuous Delivery?
If you have been following all suggestions up to now, you may already have set up a Continuous Integration configuration. The next step is “Continuous Delivery”, in which you should fulfill several conditions:
- The current version of the system should be releaseable at any time
- Deployment itself should be an automated process, that can be invoked on demand
- Keeping the system deployable has a higher priority than adding new features
If you apply these concepts, you will get a “deployment pipeline”, which automatically takes your code as input, and eventually produces either a fully deployable version of your system, or a list of warnings and errors that need to be solved quickly, because something’s wrong with your current status. All aspects of the delivery system (building, testing, deploying, releasing, monitoring, etc.) should be visible, and produce timely feedback so the team can deal with problems.
When you are satisfied that your process is well streamlined, you may even want to consider Continuous Deployment (also known as “Continuous Release”), an extension of the Delivery concept: every change that passes the series of automated tests (about which we spoke in note #6 of this series of articles) is to be deployed to production automatically. (To better manage risks, you would probably do it in phases, starting with a subset of users, and monitoring the results before going ahead in case there’s some problem, but the concept is still the same.) Yes, of course some industries may not allow this procedures, because of regulatory requirements or other similar concerns, but for most companies, this isn’t a problem. This idea fits very well with DevOps practices, and only when you are able to continuously deliver code and new functions, you will be confident that you are providing new value to users as soon as needed.
Even if the new code isn’t actually pushed to real users, but only be held “at the ready”, if you can put it in use at any time, you will be achieving higher levels of productivity… so, are you ready to drop periodic deploys and deliveries?
A final consideration: don’t be too quick to start dropping things, don’t hasten to abandon stuff, just because you don’t understand its need, or because it doesn’t seem to work for you. All elements and ceremonies have a precise reason, and when you are changing your methodology, it’s quite likely that you will not see at a first glance how the new ways fit, or why they are any good at all. The idea of dropping things should only be considered after you really understand their whys-and-wherefores — and it shouldn’t be an excuse to try to go back to your old methods!
PS. George Carlin made more than a dozen TV specials for HBO, and the quotation given above is from “You are all diseased”, from 1999; watch an excerpt of that program and listen to what else George had to say. And, if you want to get a look at Count Basie’s style, check out this version “All of me” from 1965, and notice how few notes he plays!by