Archive for the ‘continuousIntegration’ Category

Just as there was a risk with “yes we can”, long term vision might block people block from starting. I call this the perfectionist syndrome. People rather do nothing than doing something wrong.
Well, in reality never taking any decision is worse than taking a wrong decision sometime.
The cure for this syndrome is “Just Do IT” A lot of books about starting your own business (see the biography), tell you the same thing: better start.

Just start doing something,as whatever you do now, it will be wrong anyway!
Ok that might feel bad. Stick with me for a second. If you take for granted that you will be wrong whatever happens, you will feel better if actually, what you do is wrong. (In the sense that, you did expect it to go wrong anyway. )

And if, by fortune, you are right, it will be a bonus and you have all every reason to have started !

The benefit of starting before you think you know what to do, is that your customer will discover what he wants by you showing him what you’ve got. (And you will discover it at the same time.)
yes, just like you, I want my customer to know what she wants before I start. Unfortunatly customers never do. When I show her what I have done. She looks at it, sees something she does not like and then tells me what she needs. Then I make a new version and we start over. After a few versions, we together create something my customer really likes. (This is true even if I am the customer.)

A lot of agilists, react to BDUF, which is the best know part of perfectionism. That is the old model perfectionism, the “Active perfectionism”.
In agile teams I see the same idea popping up: “ I can’t start with a scrum-board as I don’t have the right material/software etc…
The right answer is “Yes you can. Just DO IT.”

Just look at your todo list, GTD cards, backlog, what is blocking you from starting? Really? Are you sure it’s not resistance?
In Do the Work, Steven Pressfield goes over the different reasons of resistance.  Are your blockers really blockers or only resistance?

Look at your list again. Forget what block you and just DO IT.


Agile Techniques that support Just Do it

  • Continuous Integration
  • Refactoring
  • Unit testing
  • Daily Standup’s


Games that teach “Just Do IT”:

Thanks to Jurgen & Oana for reviewing this post.

Do you remember the first time you drove a car?
I still remember my first time.
I was very intensely holding the steering wheel. I was only looking through the front windshield.
I was sure I did not move the steering wheel and yet the car moved from left to right.
When I made a correction move, I overshot and moved to the other side.
Last year I drove from Belgium to Bordeaux. I think that at some places I drove 100 kilometers without making correcting moves. At least that is what it felt like. In reality I think I made an incredible amount of micro changes. What has happened in the 20 years between my first ride and my ride to Bordeaux is that I enhanced my system of receiving  feedback and responding to it. Yes, baby steps again.
And every time I ride an unknown car, I have to adapt my system, actually sometimes when my car comes back from a service, it behaves different. Not much, but I feel it has changed and I adjust my driving style.

Now imagine that your front windshield is closed. And the only feedback to drive is your rearview mirror.
That means that the only thing you can see is behind you. Did I hit something along the way?
That is like only doing retrospectives (lessons-learned) as a post-mortem. The patient has died. They do a it to find who did it and to prevent future dead’s. I don’t like that kind of feedback. CSI might look nice on television, in real live I prefer check-ups to keep the patient alive.
Please take a pencil, a baseball bat or anything with that shape. In a moment I want you to:

  • put this post aside
  • put the pencil with its smallest part on the index finger of your main hand.
  • try to keep the pencil (or whatever object you have chosen) in balance.
  • while you do this, you keep track of the time.
  • come back to this post 🙂
  • write your time in the comments and continue reading.

Ok, now it’s time to do it.
How did this go? Was it easy?
Now I want you to do the same with your eyes closed.
How did this go? Did you achieve the same time?
I don’t think so. (if you do please tell me in the comments)

Feedback makes a difference even for such a small task.
Now what if someone else would be your eyes? By now you might be tired of these exercises, if you aren’t, please try the following;
you close your eyes and while someone else gives you feedback, you do the balancing act.

Does it work better? If it doesn’t, maybe change PM euh feedback person.
Does this new person allow you to be back at your original level?

If you are like most people, you aren’t. Looks like your feedback is better than the delayed feedback from other people.
What if you are allowed to open your eyes for one second every 10 seconds?
What if you would do it every 5 seconds?
I don’t think you need to try this, to know that the shorter the feedback cycle, the better the result.
The agile mindset is about shortening the feedback cycle.

If you need another story, check out Lisa Crispin’s nice posts  about how shorter feedback helped her with donkey driving.

A few projects back, I was working with a team, that had a build server, they had automated tests, but they did not seem to care about them. At least not as much as I wanted them to care about them.

Mm, how do I motivate teams to care about their builds?


One of the things I came up with, was a Croissant build.

A croissant build is when we had enough checkins during the day (that was the teams size + 1) (yes I know that is not much, but I have to start somewhere)


And the build was never red (broken build) for more then 30 minutes

or yellow (failed tests)  for more then 1 hour.

I as a scrum master brought croissants the next day.

It helped to show people how I important I found the build (I paid the croissants out of my personal money)


What I don’t like about it, is that it thinks that motivation is extrensic, where I know it is intrinsic. To have less of this problem, next time I use this, I will ask the team what they define as a croissant build.


Question I received after explaining this to other people:

1) Shouldn’t a build be green/blue all the time?

Not in my opinion, if a builds stays green all the time people have been too carefull.

(hence are not innovative enough)


2) They run all tests on their machine and see if it is broken there.

True I want people to run test locally. But I prefer them to run the test of the modules that the are working on. Not all tests, all the time.


3) Should they not run all test before checking in?

Well I want people to check in as fast as possible:

    • Write a test
    • Make it green
    • Refactor.
    • Run the related tests
    • Do a get
    • Run the related tests
    • Checkin


4) My team has to much trouble syncing, when we checkin more often, won’t be have more problems?

Yes and no. You might have more often a problem, but the problems will be smaller and easier to solve. So the time you loose will be less. (On team level) On a personal level, the faster you check in, the bigger the chance is that you won’t have the problem but somebody else (who is waiting too long to check in.)

So no reason not to check in early.


5) What if after a while my teams get’s croissants every day, that is expensive.

You make the rules stricter.

Now it is

-more checkin’s every day

-less time to fix (this depends on the time the builds run)

-same rules but now for a week, instead of a day

-let them come up with some rules.

I have been talking about real life deployment at Flickr for a few years. People have been asking me numbers or places where they could verify what I said. Problem was I did not remember where I read that Flickr deployed every 3 hours. Here are the slides.

This video talks about how Developers and Operation work together at Flickr. I know that Patrick Debois of DevOpsDay will love the one step build, the one step deploy, and one source codebase. (Just like I do) I know some people of my previous teams would love to hear about this.