Last week, we had a small incident arise with the team I’m working with. Our Continuous Integration server is now live, meaning that code gets compiled with every check-in. This is great from the perspective of rapid feedback – if there is a failure, we don’t have to wait for a nightly build – or for someone to have a problem on their machine – before we discover it.
However, this practice can be a bit overwhelming, especially in teams that haven’t conquered the Five Dysfunctions. In this case, some of the staff were a little nervous that every change would cause a build, and were adamant that they had a specific need to check in broken code.
In cases like this, especially as an external change agent, it is important to step back and look at what is going on, and what solutions are. In this case, I have the authority to say, “This is how it is” – but it is very challenging to win the trust of the team that way.
Instead, recognize what is going on:
- Something new has happened, and so there may be pushback because it is change
- The feeling may be that the breaks would be used as a metric-stick to beat the developers with. In reality it is a tool solely for them, but not everyone has the trust of that yet
- Some people may feel very uncomfortable being put in the spotlight
- The CI server automatically forces 2 of the 5 dysfunctions – inattention to results and avoidance of accountability. Well, assuming the team doesn’t just ignore the build server breaks
- There may truly be a need for someone to work in that manner. It may sound silly, but don’t rule this out
Given that we want to keep our mainline building, and that not running the CI server isn’t an option (nor having it not build on every checkin) what are the options we have?
- Work with the developers to understand their need, and offer help to mend the process so checking in broken code isn’t required
- Have them move forward with checking in with the understanding that you’ll work closely with them to fix any breaks
- Have them create a branch they can check in to, and then merge the changes back to the mainline once everything is in
So, even though it is tempting to just say, “Do it!”, we have options at our disposal. In this case, I recommended options 1-3 above. And once we had a chance to talk even more (because they felt more at ease) they were able to internalize more of the reasons for a CI server, and it turns out that they didn’t need any of the above.
So, as you work with your teams, it is vital to take into account the stages your team and the individuals are at. Sometimes we have to make tradeoffs in our process to account for the people. And People over Process is why we’re doing this at all.