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 had to start somewhere)
- The build was never red (broken build) for more than 30 minutes
- The build was never yellow (failed tests) for more than 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, and then knew)
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 careful.
(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. (This is true from the moment we have + a few thousands tests )
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
- Run the related tests
- Do a get
- Run the related tests
4) My team has too much trouble syncing, when we checkin more often, won’t be have more problems?
Yes and no. You might have more often a problem, and the problems will be smaller and easier to solve. Hence 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.
7 comments on “Croissant Build”
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.
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. )
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. 🙂
>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.
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.
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.