Wed, 10:10 session: Why I love CI (and you should too)

Saw that this got posted (thanks!) but also there's another posted about the session with photos. You could merge them.  :-)  http://aonw2015.blogspot.com/2015/02/why-like-love-ci.html?m=0

On Wed, Feb 11, 2015 at 5:08 PM, Bob Gale <bawbgale@gmail.com> wrote:

Wednesday 10:10 - 11 session by Bob Gale (@bawbgale)

I'm a technical program manager at the GameHouse division of RealNetworks in Seattle. I've recently come to realize that a big part of what I love about my job is the degree to which we've adopted Continuous Integration. CI is usually presented as primarily a Dev team thing, but I've realized a few ways that it makes my life as a PM much better. 

Brief definition of CI

Continuous Integration is the software development practice of having every code change trigger an automatic rebuild, retest and — in some cases — redeploy of the entire project.

Audience Participation

• Raise your hand if your team uses CI now
• Keep your hand up if your team writes acceptance tests in Cucumber

Why PM buy-in matters

CI is usually a dev team thing. Advocated by a dev, or they even just go ahead and do it. Buy in by PMs and other business stakeholders can be important:

1. Up-front investment required before benefit realized. You need to allow cycles to be spent on it and respect the effort.

2. Requires coordination among Devs, QA, IT. Sometimes have to go through IT to get machines to run CI servers. You can help facilitate. Some may be more enthusiastic than others.

3. Needs sustained attention. You set the tone. Initial surge of interest can give way. 

4. Goes a lot smoother if you get in the habit of writing Gherkin-style DoDs.

Three Key Benefits for PMs

Lots of reasons why it's good for the team and good for the project. But there are also reasons why it's good for YOU.

1. More engagement in requirements and definition of done

Software developers are not known for their love of reading requirements. But wait, you say, agile stories are not meant to be specifications. They are placeholders for conversations.

Well, many software developers are not known for their love of conversations either. They would rather be coding. 

Cucumber and BDD a great bridge. It starts by writing behaviors in Gherkin. "Scenarios". But they don't become part of the test suite until someone writes Step Definitions. 

Sets up the conditions described in "Given"

Triggers the actions described in "When"

Checks the results described in "Then"

Entices them into thinking about the behaviors by writing code around them. Exploits their tendency to jump right into coding. Channels this urge into better understanding the desired behaviors first.

This also gets you better feedback sooner. The act of writing the BDD code often reveals inconsistencies, missed scenarios.

2. Devs are more portable

Have you ever faced the situation when the business priorities don't match the resources available? You've painstakingly prioritized the backlog with your stakeholders. Then you bring it to the development team. Most of the features at the top of the list can only be done by the same few overloaded developers. You find yourself skipping down the list, pulling up lower priority features to fill up the dance cards of everyone on the team who has available cycles. Certain tasks always get picked by (or are more trusted in the hands of) certain developers.

For sure some specialization is real. e.g. back-end vs front-end specialists. Sometimes you have a genuine skills imbalance. But often it is habit and familiarity.

How does CI help this?

Studying the tests is a great way for a developer to learn how a feature is expected to behave.

Makes it safer to dive in and start changing because automated tests will quickly catch any inadvertent breakage

Also makes it easier to on-board new developers

3. Living documentation

We all know the agile principle of preferring "working software" to "comprehensive documentation." But that doesn't mean no documentation. Means don't get caught up in producing grand detailed plans. There's still value in having some description of what the system does, how it behaves

Experiencing the "working software" may be the truest way to understand what it does, but not the most efficient. Like saying the only legitimate way to know a country is not by looking at a map but starting at one end and walking all its roads. Like saying the only legitimate way to know about a movie is to sit and watch it. No plot summary or cast list.

Each Cucumber scenario becomes part of a growing body of documentation of what the system does. Unlike a static document, it is continually tested so it won't get stale. Makes sure it does not fall behind. The beauty of behavior driven testing is that it is a two-way street. The behavior descriptions test the code. Code tests behavior descriptions, continually confirming that they are still valid descriptions of the behavior.

- Bob

--

- Bob