9 Practices to Launch Continuous Delivery in Your Organization

Must read link dump: 9 Practices to Launch Continuous Delivery in Your Organization

Anti-Pattern

Create a separate "DevOps" team.
No! We need another silo like we need a hole in the head.

Read about DevOps at Atlassian: https://www.atlassian.com/devops/

Understanding DevOps

"the people responsible for the infrastructure, the system administrators and corporate IT groups, evolve so that they can write the code that maintains the infrastructure. Rather than being isolated, they need to cooperate and collaborate with the developers who create the applications. This is the movement informally known as “DevOps."

https://sdarchitect.wordpress.com/2012/07/24/understanding-devops-part-1-defining-devops/

Software engineering: An Idea Whose Time Has Come and Gone?

Tom DeMarco reviews his past 40 years; seems it is never too late for a review.

"I’m wondering, was its advice correct at the time, is it still relevant, and do I still  believe  that  metrics  are  a  must  for  any  successful software development effort? My answers are no, no, and no."
[...]
"Consistency and predictability are still desirable,  but  they  haven’t  ever  been  the most  important  things.  For  the  past  40 years,  for  example,  we’ve  tortured  ourselves  over  our  inability  to  finish  a  software project on time and on budget. But as I hinted earlier, this never should have been the supreme goal. The more important goal is transformation, creating software that changes the world or that transforms a company or how it does business."

Source: http://www2.computer.org/cms/Computer.org/ComputingNow/homepage/2009/0709/rW_SO_Viewpoints.pdf

Responsibility, all or none

"This is a little story about four people named Everybody, Somebody, Anybody, and Nobody. There was an important job to be done and Everybody was sure that Somebody would do it. Anybody could have done it, but Nobody did it. Somebody got angry about that because it was Everybody’s job. Everybody thought that Anybody could do it, but Nobody realized that Everybody wouldn’t do it. It ended up that Everybody blamed Somebody when Nobody did what Anybody could have done." - From: KashFlow

The 7th principle of Continuous Delivery states: "Everybody has responsibility for the release process." 

I wonder though, isn't everybody the same as nobody in this case? In the good flow of the release process everybody can be responsible and work to the end to deliver a fine product. But I always wonder what happens when the shit hits the fan. In the case where everybody is responsible, no one wants to take the blame. And either no one or all are responsible for errors.

So what does the 7th principle really means? It actually means that everybody is responsible within his own area of expertise to release a good product. As a result all processes within delivery must be known; and all processes must have owners with a responsibility to the end product. Any process without an owner is doomed to fail the end product and finger pointing is inevitable.

In this case there is even more. "Has" implies more than "is". Everyone is responsible for their own area of expertise, but all feel responsible for the end product. This is best shown by Honda when they practise the agile method of Kaizen. Everybody can intervene in the process of development and release; even if it is not the area someone is responsible for.

So the 7th principle means we all need to work to the end product, focus on our own area and be aware of the process to deliver the best possible product.

Agile engineering at Spotify

Scrum is a methodology that is limited sometimes. I just watched part one of the Spotify Engineering Culture on Vemeo and became very enthousiastic about how they work. Squads, tribes, guilds, self steering matrix organisation, all very nice solutions to common scrum problems.

Check: https://vimeo.com/85490944

Relay

 

Software development with Scrum makes all team members responsible for the result. Some tasks need coordination, to make sure the tasks will be completed at the end of the sprint the team assigns a person responsible and hands him a token. When starting with this way of handling certain tasks, make it visible.

I just crafted some relay sticks measuring 28 cm in length and 28 mm across (official measurement 38cm, 38mm). I just put some tape around for colour distinction. The team is free to combine a colour with a certain task.

Sticks will be handed over every week. On a day off the stick needs to be handed over as well.   

We will use one of these relay sticks to make sure the translation of changes are coordinated and completed in time. Another one will be used for the task of checking the completeness of new issues.