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.

8 Responses to “Croissant Build”

  1. […] This post was mentioned on Twitter by Richard J Foster, Yves Hanoulle. Yves Hanoulle said: Finally blogged about a "Croissant Build" http://bit.ly/8ZZPHY #agile […]

  2. Dean says:

    Mind dissecting it a second?

    This is a Scrum Master case of the SM re-inforcing development practices, not explicit with the Scrum Framework Process.

    Does the team expect the SM to help them realize their ambitions here? Was this build issue/expectation enumerated in a Retrospective or team charter?
    I see this article first as an example of great team member leadership, second as a development coach, and it happened to fit the servant leadership model of a SM.

  3. yhanoulle says:

    Hi Dean,

    I don’t fully agree, scrum also talks about technical excellence. It just does not tell you how to do that.

    As a coach or SM, when the team says they are doing CI builds with tests, I think I can challenge them when I see that they say they are doing something that in reality they are not.
    For me if you are saying you use unit testing and CI, then your test have to be green most of the time, if not you are fooling yourself. (Your team)
    And yes this came up multiple times in retrospectives and everytime they said they cared. I kinda proved with my action, they did not care at first.
    (Although I am biased to think that when I left, some people had learned the real value of having working tests. )

  4. Dean says:

    Thanks — I write because I’m torn on expectations for a SM–and yearnn for leadership yet still find myself looking to the process facilitators for it.

    Does Scrum note that it’s the SM’s role to define technical excellence, or promote it?

    (feel free to remove this tangent and continue in email. 🙂

  5. yhanoulle says:

    >I write because I’m torn on expectations for a SM–and yearnn for leadership yet still find myself looking to the process facilitators for it.
    Please say more. I’m not sure I understand. And I prefer to ask for more clarification then assume what you say.

    >Does Scrum note that it’s the SM’s role to define technical excellence, or promote it?
    No as far as I know, scrum does not mention this.

    I personally believe in Jim Mccarthy’s saying: “when you see it, you own it.” When I see a problem I act on it. That is the example I want to set in a team.


  6. Dean says:

    C&C teams used to taking all their anomalies to a team lead (mgr, tech lead, project lead, etc), instead of the team as a whole or direct resolution; when adopting Scrum may bypass self-organization/mgt by using the SM the new team lead.
    SM not taking coaching roles guards against this, but hinders opportunities to use their personal insight. Team acceptance of Mccarcthy’s ‘see it, own it’ (and SM as peer) is a great covenant.

  7. yhanoulle says:

    Thank you, I understand now better what you ment.

    yes, there is this constant balance between not rescueing and setting a good example.

    For me anyone in a team can and should start with the “I see it, I own it”. And thus I will try to do this as much as possible.
    Even if I own it is make sure people are aware of it and I avoid to rescue people.
    The croissant build is an example of it. I showed the team I cared so much about it, that I wanted to spend money on it.
    Yet I wanted them to solve it. Yet as I wrote, I would let the team come up with the rules next time.