Milwaukee Agile Meetup - Continuous Integration Panel Discussion Summary

Last week I had the pleasure of being on a panel discussion about Continuous Integration at the Milwaukee Agile Meetup. My fellow panelists were Carl Schrammel, Adam Black, Jason Duff, James Carpenter and Adam Johnson.

The discussion grew out of the group's growing interest in this area and challenges that individuals and teams attending the Meetup had expressed recently. I know several people who said they had wanted to attend, so I thought I would post a summary of the discussion.

Q: What does Continuous Integration mean to you? When were you first introduced to the concept and how did it change your perspective?
A: After the initial text book definition was given ("Continuous integration (CI) is the practice, in software engineering, of merging all developer working copies with a shared mainline several times a day." - Wikipedia), the group continued to express their take on CI.

• CI is a powerful feedback tool for both engineering as well as project management - reduces surprises due to integration and deployments and makes the ones which occur more manageable.
• The benefits of CI are best reaped via automation, but even manual CI can bring great improvement.
• CI can help build confidence in the product and the team - one always knows the state of the code at the end of the day.

The distinction between Continuous Integration and Continuous Delivery (CD) was also drawn... with Continuous Delivery being an advanced practice where a team is able to deploy changes to production with high frequency. 

Q: What tools are being used?

A: The standard list of revision repositories, build servers, testing frameworks, continuous integration servers, deployment automation were quickly run through - basically if you are interested in CI there is likely a set of tools readily available for your language/tech stack of choice. It was noticed, however, that there are software products and systems which are not necessarily easy to integrate automation or other CI tools too. Particularly these tend to be configuration based systems, or closed systems which perhaps try to manage revision control internally - preventing access or control by external ci/build/test setups. This led to the discussion that aside from tools, the other aspect of CI is the practices and behaviors. These behaviors are often harder to implement than the tools. However, if the behaviors are embraced by a team, even the most simplistic of CI tooling can become powerful. The further consensus of the panel was that it is best to start simply - implementing behaviors and supporting tooling gradually. In this way, each advancement should be lauded as a positive win in the right direction rather than disappointment at not having achieved an elusive ideal CI or CD state in one try.

Q: How to prove the value of CI to developers? to business/product owners? how soon can one expect to see value?

A: The answers to this echoed some of the previous discussion. The general feeling was to take each instance in a case-by-case basis and look for opportunities to introduce behaviors and tools pragmatically to provide greater insight into specific areas where a team may be experiencing pain. Examples: recurring bugs, painful massive code integrations, lost code, misunderstood and mis-implemented user requirements, painful coordination/integration with other systems/teams on deployment, out of sync versions of code between environments (Prod getting ahead of Dev or Test), not being able to do certain types of testing. All of these were brought up as pain points which some degree of CI could have alleviated. 

Since CI sits on the front lines of ever changing code, the positive impact of CI can be seen very quickly (as soon as one build cycle in some cases). The key is to communicate this to the parties who would most appreciate the benefit. This is where a CI server can help by providing dashboards and automated messaging, but even utilizing the low tech approach of holding stake-holder meetings before and after a CI 'event' can shed light on the benefit of the activity.

The panel agreed that in order to get the buy in to do more advanced levels of CI requires the building of trust, something familiar to Agile Coaches and leaders everywhere. However, even the most rudimentary CI practices can provide excellent data and feedback which, if communicated properly, can facilitate the building of that trust. Due to the fact that CI can generate data about the health of the deliverable every time a change is made, it can be one of the most powerful and prolific sources of data for information radiators. The trick as with all data is to mine it for the most relevant information to the message you wish to communicate.

Q: Who owns CI? Who sponsors/drives for CI?
A: The panelists seemed to generally agree that in most large project teams, there was a dedicated Operations team in charge of maintaining the CI tools (build servers, repositories, deployments and deployment automation, ci servers, etc). However, many expressed how this could lead to the negative effects of siloing. Panelists shared their experiences with teams who used various means to combat this. Rotation of members into the ops team, rotation of ops duties among teams, the use of embedded testers to serve as the bridge between dev and ops, and use of separate scrum-of-scrums to coordinate dev teams with ops.

We did not get too much into the sponsors for CI. I would suggest, as with trying to get buy in, any individuals or groups who feel they would get a benefit out of the use of CI could sponsor it. I have seen CI started as an engineering initiative and I have also seen it sponsored by Project Management and even Product Owners.

Q: Of those doing CD, has anyone automated the signoff process in tightly controlled organization/industry?
A: No one had seen full blown automated sign-off at the level of the typical product owner, upper management deployment committee. However, several had seen groups who had automated sign-off at lower levels, such as moderate UAT sign-off. This can help pave the way to make the manual sign-off at the executive level easier once trust has been established through a record of reliable test/dev/pass/sign-off cycles.

The evening flew by and that was about all we were able to get to. Prior to the discussion, David Neuman from Redpoint Technologies sent out a list of questions to the panelists that would serve to seed the discussion. I think we hit most of the items tangentially. If anyone would like to discuss them further, leave a comment or email me.

The last question on the list asked if there was one recommendation we have for successfully implementing and leveraging CI. 

Build Automated Tests. Even if you still have to trigger your builds or other steps manually, having automated test suites that you can run against your built code is one of the most powerful tools to start getting an ROI on your CI efforts. Furthermore, many of the behaviors and practices of CI which are difficult to master initially revolve around disciplines of TDD. If you have automated tests, it is easier to start to instill these disciplines in your team. As some of the other panelists and I were discussion after the meetup, automated TDD is fun... it makes coding like a game with almost instant gratification to our problem/puzzle solving efforts. Making something fun can really make developing good habits to support it easier.

Put your Adwords fears to REST (managing lead consumption)

I just finished up a neat little project where I got to help a client streamline how they were managing the monitoring of lead consumption among their sales members and making sure that they were not overspending in a particular region at another's detriment.

The Problem: The client is using Adwords to garner leads in various states. Their sales team members are selling in multiple states. They have a third party system for distribution of leads to the team members. This system has a toggle the team members are to use to indicate whether they are actively taking leads at a given time. When this flag is on for a team member, leads are sent to them. However, many team members were failing to turn their flag off. These members where then getting leads assigned to them when they might not even be in the office. This was to the detriment of other members who then would get none. Due to the agreement to provide members leads, this meant a lot of work tracking consumption, establishing quotas and trying to modify behavior. It also meant that sometimes the Adwords budget for particular campaigns would have to be increased in order to meet the internal agreements with the sales team. The cross region nature of sales member activity also meant that it could effect campaigns in multiple regions. They were tracking all this using a spreadsheet and a lot of leg work.

The Solution: Redpoint was asked to build a small tool to automate what the lead manager was having to spend too much of his time fretting about with the spreadsheet. In a short 6 weeks from Inception to Production Deploy we came up with a system to do this. The tool ultimately consisted of a web app and a poller service. The components pulled data from various web services including the distribution tool, internal employee data services, and Adwords. Most were RESTful - hence the title of this blog. The web app gave the lead manager a dashboard to monitor individual sales member consumption of leads against an assigned limit. This contributed to the calculation of potentially available leads for a given state. Once all members selling in a state had gotten all the leads they were supposed to, all campaigns in that state would be paused for the day. If the lead manager wanted to they could then increase a particularly good sales persons limit and allow them to sell more, or refocus a sales persons lead consumption to a particular state or states. The poller service was automated by a Windows Service using Quartz.net CronTriggers to assign various pollers to maintain the list of sales team members, the states they sold in, their lead consumption, the availability pool, and ultimately to pause or restart the Adwords campaigns appropriately.

The Result: The final tool, as it had evolved, quickly gained admiration from the executive team and the project sponsors. Even in its testing state, it had shown that it was more than just an automated valve for Adwords. The dashboards and multiple levels of control built into the solution allowed them to quickly see patterns in sales member activity and behavior. The flexibility of the Cron Triggers allowed them to schedule polls and resets as well as to automatically turn off all campaigns during down times and prevent 'greedy' team members from stock pilling all the leads while others were out of the office. This also assuaged executive fears of blowing the Adwords budget as they soon saw how this was an excellent emergency shutoff valve to control their spending.

For phase two they are already talking about the ease of creating trending and tracking data from what is being pulled as well as adding in different lead types and groupings.

As an Agilist, I appreciated this project as it had become an interesting, dynamic and interactive information radiator that would allow them to manage and change how they do business to meet the changing needs of their market and their staff.

Other Applications: Of course this sort of tool could be very useful to any growing company who is struggling to wrangle their Adwords budgets and their sales team's quotas. A similar tool could be useful to Scrum Masters, PMs or Team Leads to monitor and control story assignment within a team, by using the information from their story management system and assigning categories or even complexity sections to various members ("you did three '1 point' stories this iteration so far, you have to take a '2' or a '3' next" OR "You have been only taking stories involving that piece you created, for the rest of this iteration you need to take stories from other areas of the application"). While not so helpful with a small team, it could be very handy with a large distributed team - like the sale team in this case.