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.

Empathy Driven Development: Rescuing Value From the Bermuda Triangle

"Our industry still suffers from the curse of the Bermuda Triangle – the place where all stakeholder value goes to die"


http://blog.scrum.org/empathy-driven-development/

Followers and quibblers

As a manager I notice two kinds off employees, the followers who do the things you say and the quibblers who ask questions. I love the latter, those are the ones I want in my teams. On first thought they might add lag, they might slow things down. However, if your team is big enough, they prevent you from doing stupid things. The first group will never prevent, they will coalesce with you into the abyss of faults. The quibblers will only follow when they are convinced.

As a manager I find it difficult to be and stay a quibbler. I think I'm obliged to be because I carry out a function to advice my superiors, which means I need to make them the best offer my department can deliver in all circumstances. If I would be a follower I wouldn't be able to do this. And if I'm a quibbler I might annoy my superior and lose my job. As long as my superiors are not susceptible for quibblers I might be facing heaps of problems.

This fine balance is a problem for me, sometimes I'm just too blunt. To my superiors the edge feels thin and I can tip over any minute, but on the other side I expect a thick edge from the ones I lead; my goal is to provide them with a solid base to deliver me criticism.
Is balancing things out the trick for a manager? Finding the edge and not tip over? I don't know. I rather do what I think is best and get screwed if that's not what my superior wants. And there's another fact, if a superior asks me to do something, should I interpreted it as a direct order (follower) or as a suggestion (quibbler)? I opt for the latter one, risking my position. Being a quibbler makes it possible to find new ways to do ones work better, when someone is a follower there will be no new ideas or any creativity. Followers do the same work until they retire or die.

But hey, if I need to follow, and I don't want to, and I get fired not to follow, is it really a problem? I can't live following, so perhaps that's for the best as well... What I'm trying to say is: don't follow, think! Criticism makes you better, learn to take it, love it. Be a quibbler to your superiors, minors, team members and above all to yourself!

Nothing beats the team

Building a scrum team is hard. It's hard because the good nerds need to be found. Multi disciplinary people, programmers at first with preferable some add-ons. Each programmer should fit in the team, add value to the team. Not one person in the team should be able to do everything, the team as a whole should be able to take on the world.

Skills

What are the skills needed in a team I wonder. First of all we need someone with programming or testing skills. We need someone to be able to perform the scrum master role to guard the scrum process. We need people that communicate. We need people that feel responsible. We need people that are honest, bloody honest. People in scrum teams should be more honest to their colleges than most people are to their partner. So some skills are important to all, some skills to some. Together they form a team that delivers excellent software in time.

One of the hardest aspects for most programmers is to manage expectations of the product owner and stakeholders. The product owner needs to be informed, and also needs to inform himself, about progression of the development of the product. Any impediments should be mentioned to the product owner as soon as they are known. Of course the product owner will suffer misfortune, but less than when he is surprised at the end of a sprint by finding out the team failed to achieve their commitment. He also has a choice when the team hits a set back. Priorities can shift, work can be altered; he can have the ability to help the team reset commitment. The team can deliver a tested part of the product rather than nothing at all.

So commitment on the backlog, responsibility about the work done and communication are main skills that programmers need to have to be able to work in a scrum team.

Forming teams

Forming scrum teams can be hard. Who is doing the interviews? When will the new programmer meet the team? When you have multiple teams, who should go where? There's a simple answer: Include the members of the teams. Some managers respond to this like I'm insane, but if I talk about trust and honesty, who better to decide to open up to than the people who should work with the new programmer? They have the last word whether or not a person joins their team.

When it all goes wrong

What? Isn't scrum the holy grail all the world is talking about? Nope, it isn't. Many people oppose scrum nowadays and ask development teams to drop scrum and go back to programming. Personally I disagree to those people. We picked up scrum to avoid being interrupted all the time and to be called into meetings whole day long. We picked up scrum to get insights in our own performance, to deliver software in time. Of course we are failing sometimes, on the other hand, we are failing way less than before we adopted scrum.