Simple Continuous Delivery

Continuous Delivery is a very simple process. This is how it could be:

1. Always deploy on the customer environment.
2. Make use of small feature branches.
3. Make sure you have always very small features. Try to spend no more than two hours on it.
4. Do Test Driven Development!
5. Create some integration tests, let it run while you are about to deploy.
6. Create end-to-end tests when needed and run all just once a day.
7. Have very, very short feedback's from the customer! Make use of on site customers or key users.
8. Spread functionality as much as you can over the different teams, so that merging isn't going to be a problem.
9. Don't be afraid of making mistakes!
10. Don't make deals that result in a deadline!

That's it! No problem.

Daily stand-up

Oh oh.

I fell into a trap. You know that kind of traps you know of, but don't realize you're right in the middle of it? Well, I think it happened to me right now. 

I'm always aware, or at least I thought I always was, that a scrum master is a coach and not a lead. Well here's my confession (Hmm it sounds like  a catholic confessional), I always take the lead in the stand-up. Oh oh.

What is a stand-up?

Let's take a look at what the stand-up really is. In real basics it's this:

1. Awareness about the sprint and especially what's not been done yet,
2. A small planning, only for one whole day, about how to be as effective as possible on the user stories left.
3. (not a goal, but an outcome: be transparent to the product owner and stakeholders on the status)

So basically, as a developer (remember that a developer is a member of the scrum team, so testers included) you need to tell what the progress is on the user story you've been working on and need to know the progress others have been working on. You need to know, as a team, how to be as smart as possible on finishing the user stories left on top of the remaining sprint backlog.

In short you have to do these things, according to the user story you are working on:

1. Talk with your fellow developers what the status is of 'your' user story.
2. Find out what needs to be done to finish 'your' user story. (short comment: this can only be done when you have small user stories. If you got large ones, it makes no sense discussing the whole thing)
3. Set a clear goal on 'your' user story and create an efficient plan how to work together to get things done.

Take the lead!

As a developer working on 'your' user story, take the lead in discussing it! Because you're kind of an expert on it, since you're the one working on it. The ones working on the user story are kind of first responsible. Discuss how you feel about the user story, what you need from outside the team, who can help you most, or what do you think will happen. Be aware of your job!

Be ready for the future!

So, here we are, on a normal day, staring once again at legacy code and wondering how to wrap a new feature around it. I know you've been there, because I have. And I'm surely not unique. And if you haven't, you'll turn out to stare the same way to the code as I did.
That's when the questions come and they come naturally, because it is not the first time you encountered such a mess. How on earth could a developer implement this software into our application? Look at the dependencies, look at the design!
And the memories of former similar projects unintended pop up into your head, giving you the scrupulous feeling of a dejá vu. And that's not all. It makes the hair stand up on the back of your neck. You know what is going to happen and you live with it, because there is nothing you can do about it. You just have to go with the flow, like you always did and everybody does.

Johnny Raw

Now that's the problem you have, right there. When someone comes up to you and says 'Hi, let's do continues delivery!' Al those memories and feelings about the code, gluing, aftermath, struggling, wrapping, trying to make the best out of it, the bugs which eventually will come because you unavoidably broke something, all those feelings are coming back. Especially when someone who's been at the company for a very short period says it!

Biases

And then the discussion comes on how 'we' should become a company with fully integrated continues delivery. And what are you doing then? You are trying to disapprove or refute every suggestion he or she is making. It's not your intention, I know. But it will happen. Why? Because, the common feelings of trying implementing something beautiful which always end up in a disaster, are embedded into you head. And they are easy to trigger. In fact, there are the watermark of your thinking, you cannot think without it. They become one with you. Inseparably. They are called 'preconceived biases'.

Stuck?

Well, that's splendid! Stuck with legacy code and your own legacy thoughts. What do we do now? Can you free yourself from your subconsciousness?
If you are ever willing to free yourself from this you must avoid these things during a conversation,

• rationalizing, 
• being constructive,
• thinking relative,
• justify your feelings about possible solutions that come into you head or come from others,
• bring upcoming thoughts or comments into perspective.

The moment you get negative feelings about something, you have to ignore it. This way you can free your mind. Especially if you are in a group, with everyone speaking their thoughts up loud and with someone who interrupts a conversation when things are getting negative and guides the group towards solutions again. If you allow rationalizing, justification and perspective, you will never get to good ideas. Don't let those negative thoughts control your group. They will come eventually by themselves after the meeting, or when you're trying to define actions. All comes later! And, if you try to do those sessions more often, you get used to it and it becomes more natural. 

Good luck doing so!

Ultra High Definition

(Here's is a metaphor for you. Especially when you company want to just continue making great new things and not wants to spend time on refactoring and continuous delivery)
See your company as you as a father. And imagine the software as your child. I intentionally chosen the father by the way, because of his characteristics, you will see during the story.

Shopping

You and your child are going shopping. You're walking along fine, but your boy needs to go to the bathroom and you're in trouble. So, as a good parent, we take it by its hand, go search for the nearest toilet and make sure it's clean though, otherwise you got other problems. And finally you can continue shopping.

But, we all know, we are not good parents when it comes to shopping, are we? Because we need to go to the store and buy us a new television. With Ultra High definition, because we need to be ready for the future. Think of all the possibilities that may come with that. Just high definition is not good enough.

So, we take the boy by the hand and go to the next store to compare some. You buy your child an ice-scream, because otherwise it wouldn't go to the next store. Go sit for a cup of coffee and a hot chocolate and then... there you have it. You end up with... Right! A pee or a big Winnie the Poo(h) between his legs. And now you are in real trouble. Cause, even when you've got a spare of trousers, it is from when he was one and a half years old.

Recap

So you start thinking about what you could have done... You could have taken him to that nice hospitable cafe just around the corner, where you, when you where young, had a good laugh with your friends and where you even met your wife.

Now, what you're plans may be and what great things you want to buy, you first got to do something else! You know that in the near future the shit will hit the fan when you continue doing what you are doing. And again, we are not a good parent, and maybe it's because this child is only a piece of software, but we can start now being a good parent!