Holistic view of Continuous Integration & Build (Agile and CM Mindset) – Part 3 of 9

In the last episode (e.g., Part 2 of 9) of this series, I introduced the elements of Continuous Integration and Build (CIB).  One of the key elements in CIB involves a mindset change to think more continuously.  For Continuous Integration and Build to work effectively it is important for the Agile mindset to merge with the CM mindset.  Let’s examine this in more detail. 

CM Mindset

The CM mindset focuses on the CM values.  CM thinking focuses on modularity and in small building blocks.  This makes it easier to group configurations when the building blocks (e.g., configuration items) are uniquely defined.  Thinking in a modular manner also makes it easier to construct and deconstruct a process, particularly when CM professionals are often asked to automate processes so they understand the checkpoints along the way as they script and code.

CM professionals also think in terms of integrity.  This includes both personal integrity in the manner in which CM professionals work and integrity in the product development they are supporting.  Personal integrity implies that CM professionals believe strongly in doing the work the right way and feel accountable to ensure correctness and completion of the task.   Integrity in the product implies that CM professionals feel strongly in working processes that have the ability to track changes to the product and have the ability to verify the baseline of code in which they are working.  

Agile Mindset

Agile thinkers bring a different frame of mind to their work.  In traditional methodologies, the world appears well planned with very specific milestones and changes are constrained after a certain point.  In Agile methodologies, the world is much more fluid, changes are dynamic, and changes are welcome.   Traditional methodologies use a phased or a more serial approach while Agile uses a continually evolving and iterative approach.  In effective, traditional methodologies look for a fairly fixed and pre-defined path while in Agile the path is more collaborative, allowing for learning and gaining an understanding of value to the customer. 

Agile thinking focuses on short iterations and small increments.  In Agile, you time-box activities and breakdown work into small chunks.  This is not dissimilar to CM in thinking modular. This incremental building of functionality allows the customer to provide feedback which in-turn ensures we are building something the customer actually wants.  This allows you to continually see progress. 

The “Continuous” Mindset Shift

A very interesting shift occurs when the concept of “continuous” is ingrained in the culture.  Agile embraces continuous change and those practices that support this.  In more traditional cultures, processes tend to be set up to maintain the status quo and constrain change.  This is why Agile professionals often have challenges getting Agile adopted in more traditional companies.  This is not really a clash of processes, but instead a clash of cultures.  The process used reflects the way the culture works.  Some cultures are heavy in ceremony, governance, and multi-level approval.  Agile will have challenges with this type of corporate culture.

The continuous actions of check-ins and builds introduce a new challenge to CM.  A continuous integration and build practice places considerably more stress and load on the CM version control and build systems.  Having modern, faster, and automated CM tools with underlying infrastructure that can support these continuous actions is important to the success of this practice.

Moving from Event-Driving to Continuous

In an Agile context, what we see in CM and the build space is a fundamental shift in the way we build software.  The build process moves from an event-based integration process to a continuous integration process. In other words, no one needs to hold onto large amounts of changes for a major integration effort or declare that builds will occur nightly, weekly, even hourly.  There is no ceremony needed.  We move away from the infrequent and often painful integrations (a.k.a., merges) and move to an integration and build process that becomes part of the team’s daily activities. 

When you integrate and build all the time, integrations and builds become non-events.  As an example, when code gets continually promoted based on successful private builds and unit tests, an integration and build at the project (or next) level becomes automatic and trivial (e.g., minimal merge and build problems).  Then the results of a successful build routinely become candidates for test and release if they pass the defined tests (e.g., integration, system, performance, etc.) and meet the customer need in the end-of-iteration reviews. 

The primary benefit of continuous integration and build is that the changed code provides immediate feedback whether it runs correctly with the rest of the code in the integration branch (e.g., project release branch or main branch).  When code sits in a programmer’s private workspace, no one else can see it, nor can it be accessed by other programmers. Much like the concept in Agile where value is only realized by working functionality, the same is true with continuous integration.  Progress is only realized when the code has been integrated into the active project code-line where others realize that it exists and it can be built as in an integrated manner with the rest of the code. 

As you move to Continuous Integration and Build, your team must also evolve to a mindset change that involves thinking more continuously.  For Continuous Integration and Build to work effectively it is important for the merging of the Agile mindset and CM mindset in both thought and in action.  Stay tuned for the next episode where we will focus on the Getting to Bit-size work and what this means in a Continuous Integration and Build process. 

References

· If you started with this entry (Part 3), consider reading the first two parts.    

  o   Holistic view of Continuous Integration & Build – Part 1 of 9 (Introduction)

  o   Holistic view of Continuous Integration & Build – Part 2 of 9 (Elements of CIB)

· Also consider reading: Adapting Configuration Management for Agile Teams - book by Mario E. Moreira, Wiley Publishing, 2010