Last week I spoke at QCon London about Songkick’s experience of moving to Continuous Delivery. You can download the slides, or watch the longer version of this talk on the LondonCD Meetup’s Vimeo channel.
My talk was part of the DevOps and Continuous Delivery track hosted by Eoin Woods. QCon videos of all the talks should be available soon.
One particularly interesting talk was by Steve Thair on ‘DevOps and the need for speed‘. Previously I thought DevOps was about developers and Ops people collaborating to enable faster software delivery. Steve’s definition went much further and ended up being closer to how I think about Continuous Delivery.
Steve defined DevOps as a model that “encompasses a product-centric view across the entire product life-cycle (from inception to retirement) and recognises the value in close collaboration, experimentation and rapid feedback.” He emphasised that the business and testers should be engaging in the collaboration just as much as developers and ops people.
An interesting distinction between Steve’s DevOps definition and Dave Farley’s Continuous Delivery definition focused on the definition of ‘Done’. Continuous Delivery is defined as being about “making businesses more experimental through the early and continuous release of valuable software”. It appears to be complete once the release is out in production. DevOps adds an important final step of evaluating how much value the release is actually adding once it’s in the hands of users.
I love Steve’s definition of DevOps but unfortunately think this term is sadly restricting. I doubt business people or testers will feel included in something called ‘DevOps’. Even more confusingly I believe there are both devs and ops people who do believe ‘DevOps’ only covers devs and ops.
Even re-defining Continuous Delivery to extend beyond the release doesn’t really help the situation. We’re trying to create a process that keeps the software in a state where by it can be released whenever the business wants it to be. Obviously there are some questions around why the business would suddenly decide to release with little notice and whether we should support that or not. Leaving this aside I think Continuous Delivery is a positive way of working to remove unexpected delays to releases.Any process that encourages collaboration and stress-free releases should be given strong consideration in my book.
A name is always just a name but in the case of improving processes and making sure all roles are covered I think it becomes pretty important. We need to hear everyone’s voice as we attempt to fix software development.The concepts being discussed are important and will affect us all. I personally feel that neither the ‘DevOps’ or ‘Continuous Delivery’ terms are quite right for describing an attempt to engage with all stakeholders and release timely, and functioning software to end-users. Regardless of this I believe everyone involved in software design, development and releases should be involved in deciding the best way to fix the software industry.
What do you think? Are you a Continuous Delivery or DevOps fan?
Testing the Mind 
The importance of involving business is not new. In sequential model it’s about well-defined unambiguous business requirements. In Agile, a close cooperation with the business is one of the principles. It’s not easy though. But what’s the benefit of giving a new name to a process where business participation works well?
Thanks for commenting, Leonid.
I agree that business involvement is not new but it is also not a defining point of either the DevOps or CD terms, both of which focus on the ability to release rapidly. Steve’s definition of DevOps “recognises the value in close collaboration, experimentation and rapid feedback”, the new aspect (for me) was that the inclusion of business and testers in something which is often considered to be a technical problem.
I think many teams would benefit from including some CD aspects in their process (agile or otherwise).
Hi Amy
Check out http://www.jedi.be/blog/2012/05/12/codifying-devops-area-practices/ – Patrick distinguishes between DevOps applied to all aspects of an organisation, and DevOps Lite which is the traditional representation of DevOps = Dev + Ops. Steve was referring to the former I presume, whereas you were thinking of the latter.
I always think of the latter, and really Dave Farley explained what DevOps means to me that I could myself http://blog.xebialabs.com/2014/12/10/cargo-cult-devops/
S
Surely Amy’s right though, that a term derived from two particular titles is not going to feel inclusionary to those outside those roles. Continuous delivery whilst potentially excluding some areas at least has the benefit of focusing on outcome rather than roles in its nomenclature.
^^^^ What he said 🙂
Development (as defined for example in wikipedia: http://en.wikipedia.org/wiki/Software_development) includes all project activities that lead to handing over a product to operations. This obviously includes activities that the business people have and also very much all testing activities – no matter whether you are in a team with the programmers and architects or in a separate team doing black-box testing. It’s still all development. The real problem is (in my opinion) that (some) architects and programmers have hijacked the term “developer” for programming and architecting roles. In my opinion there is no single “developer” role, but a pool of vastly different roles that are needed in software development (including programmers, architect, ui designers, testers, test managers, etc.). On the other hand, the mere wish that testers may want a term “DevTestOps” or may not feel included in “DevOps” somewhat indicates to me that there may still be silo-ed thinking at work here. And I do say that as a professional software test project manager.
That said, there is some truth to the blog post.
Here is an interesting idea. Try this at your company: talk to a non-architect and non-programmer and try to ask a question like this: “You, as a developer, what is your opinion about …”. My guess is that you’ll get a highly confused look. To a different person, try the following: “You, as a member of the development team, what is your opinion about….”. I’d say it depends on whether the testers are embedded in a team with the programmers or in a separate team. The term “development” is already set in our minds with a definition different to the one in Wikipedia. There is somewhat of a gap between the “academic” definitions and how the term is used in the industry.
Is this a problem? I don’t think so. There is a whole lot of education that needs to take place in order to change the culture towards a DevOps culture. In my opinion, framing an understanding that everyone in development activities is a developer will rather help the purpose. On the other hand, if we coined a different term where testers would feel included (i.e. by somewhat along the lines of “DevTestOps”), we would underline the silo principle that we want to get rid of so much and probably exclude other roles that we forgot once again. It is unfortunate that the term “developer” is often associated with programmer, but development is really what describes all the work to reach the ultimate goal: the developed product.
The DevOps wave is rolling and we should be glad about that. Reopening a disccusion about terms will neither work nor would it help the case – even if the argument was highly plausible. Rather we should try to understand ourselves as developers even if we don’t write code. At least I can do that. The question is: can we?
Thanks for your comment, Freeman.
I think the term we use is important because it determines who will engage in the conversation. I’m not promoting the term “DevTestOps” but merely pointing out that I, and I suspect many other testers, don’t join in the “DevOps” conversation because we don’t realise it is encompassing testing.
Your argument that everyone on the development team should be considered a developer is very interesting. I’ve been pondering it for a few days and although I can see the sense it feels too late to re-claim the term developer. Personally as a tester I like to be recognised for my testing skills even though I work in a highly collaborative team.
Actually, all you have to do is to identify yourself as part of the development team even if you don’t consider yourself a developer. DevOps is still a composition of the words “Development” and “Operations”. I don’t believe that this should feel too unnatural.
The question behind it is really (and it might be somewhat hard to swallow): for all those having a problem with the terminology, is it some implicit way to insist on the “old” silos? Being in the software test domain myself, I know that many test people fear the DevOps movement a lot. The DevOps movement implies the necessity for a whole lot more technical skills. We unfortunately lack these on average with the test people. In my experience, most of the movement is driven by programmers and architects. Even operations people have problems with the movement as – frankly – it obsoletes major parts of their current business (i.e. manual configuration and deployments).
It’s not that I fear DevOps, I think that we should be adopting DevOps practices. Testers shouldn’t be siloed and the whole team is responsible for quality.
Bending ‘Development’ to fit the DevOps term does not solve the problem of people mis-understanding its aim.
If testers don’t feel included in the term DevOps then I don’t think the solution is to call them developers no matter what the original definition of the term.