Why Continuous Integration is like Broccoli
I think Continuous Integration is the ‘Broccoli’ of the Agile world… everyone knows it is good for them but few want to really consume it.
Continuous Integration is one of the most valuable practices in the agile development universe! Despite that, it is quickly clear in most shops “doing agile” that no one there really wants to implement Continuous Integration (CI). Why not? What forces are causing so many to turn away from this Agile ‘superfood’ practice that yields so many benefits?
I was asked in to assist a few groups that had been “doing Agile and Scrum” for a couple of years. One of the major issues holding them back was that they did not leverage any aspects of Continuous Integration. When challenged on this issue, they spoke with almost a perverse pride, “We were warned at the start of our Agile journey, that If we didn’t implement Continuous Integration, our Agile adoption would fail! But here we are, still going.” They went on to tell me that they had other Agile coaches tell them on a regular basis that they needed to implement CI. They finished their saga with a familiar set of refrains on why they didn’t / couldn’t implement CI:
- We can’t because of the technology that we use ….
- We tried and it just doesn’t work in our environment…
- Automated testing isn’t possible with our technology …
- Etc. …
I could have and did challenge each of their technical reasons (or excuses) for why they weren’t implementing CI. But, much more interesting was uncovering the political and cultural reasons why they were not making progress in CI.
I probably shouldn’t have been surprised, but I was to find that: Just like “eating their broccoli”, everyone knew that CI would be good for them… and no one would say that they were opposed to CI… but it was clear that every group had reasons to oppose implementing Continuous Integration.
- Developers … would need to learn a different approach to doing their development work. Instead of working on a batch of changes for a story, they would need to learn to make small changes that were each atomic and benign. The developers felt that working in stories was small enough granularity, they weren’t interested in making their changes less atomic than that.
- Development Management … staffed the scrum teams with a hierarchy of junior developers and relied on a few more expensive, senior developers to check everyone’s work. The fast flow and fast integration of continuous integration couldn’t support the checking that the managers depended on. They would have to change the way that they staffed teams to support Continuous Integration. In addition, they would have to justify the higher headcount cost to their executives.
- Testers … were knowledgeable on the application and testing skills, but had no development skills. They would need to learn a new skill set to focus on test automation, but they were busy doing testing and intimidated about learning the new skill set.
- Test Management … also staffed the teams with a hierarchy similar to Development. A move towards the rapid cycles of CI would require them to hire more skilled people (at a higher cost) and give up the pattern of managers checking their team members work. More expensive hiring meant that they would have to justify the extra expense to executives.
- Operations support team … would have to setup and maintain more servers to support CI, and those servers would need new tools which the Operations team would need to administer and support.
- Program Managers … would need to advocate for and pay for multiple test environments in order to implement CI. They would have to put together the business case to justify the extra expenses for test environments and operations. Without understanding the economic benefits of CI, the Program Managers and Leaders won’t provide the needed infrastructure and test environments. Without these essential pieces the efforts of anyone else in the program to implement CI would be stifled and ineffective.
Some of these forces opposing CI were unique to this organization, but most are common to many organizations. Considering the army of forces lined up against CI, I should be more surprised when an organization actually implements CI and less surprised when they only give lip service to it.
So, if Continuous Integration really is like ‘Broccoli’ of the Agile world… how do we move organizations past the head knowledge that it is good for them to really consuming it and gain the benefits?
Next time, I’ll discuss a pattern for circumventing all of these opposition forces and getting your organization to consume this “Superfood”.