The Convergence of Continuous Integration and Continous Release

There is an emerging paradigm with continuous release that may result in a convergence between it and continuous integration.

The concept of continuous release is not new. However, in most instances where the term is used it refers to deploying and testing the application on a periodic basis - usually nightly - and deploying the entire application. With the latest paradigm, continuous release becomes more like continuous integration - when changes to a component are checked into the version control system, not only does it result in an immediate action of building the component but is extended to include testing and releasing it.

With this paradigm, which I'll call true continuous release, the benefits are:

• In true Agile fashion it provides immediate user feedback thus adding another layer to the Agile feedback loop.
  
• Safety with assuming the risk of integrating smaller and more efficient releases as opposed to a much larger releases of whole applications or large subsets of it.
• Users are provided the flexibility to elect which features they want to upgrade/install.

A few of the requirements for true continuous release are:

• Strong feature coverage with automated testing.
  
• Tight process with recording component versions.
• Significant complexity related to the recursive nature of component dependencies.

I highly recommend a white paper on this emerging release methodology that you can find here. It contains valuable information of its benefits as well as implementation difficulties.

Is this the next efficiency model? Is its value limited to companies such as online gaming companies that are structured based on frequent and noticeable changes? Are its complexities too significant that most organizations will pass on implementing it?

I'm interested in your thoughts.

People, Processes, and Protection

I'm going to drift a bit from my typical subject matter and talk about the importance of managing people and processes for the protection of all involved.

You may wonder in what context the word protection applies. Protection is the obligation of managers to protect their direct reports, direct reports obligation to protect their manager, and everyone protecting their customers and organization. The glue that holds all of the various protections together is a codified set of processes. I know codification is optional, but to be great instead of mediocre, the processes need to be as well understood and unambiguous as possible thus documentation is required.

Example:

Background: A consulting company has a custom software development effort with their best client. The project is highly visible and the client's financial investment makes it high risk as well. Each two week development cycle has a scoped set of features that the development team commits to and at the end of which results in a demo of the working code to the customer.

Manager Protecting Direct Reports: The development manager works with the development team to scope the features to be developed during the current cycle. Each team member commits to one or more deliverables and provides their estimated level of effort. The development manager is doing his/her best to set up his/her reports to succeed by involving them in the scoping, assignment, and estimation processes.

Direct Reports Protecting the Manager: As the cycle progresses, each developer is cognizant of the commitments to the client and all of them know that no one likes surprises. When a feature is bigger than expected or unforeseen obstacles arise that threaten the ability to deliver the scoped feature(s), the development manager is notified as early as possible to allow him/her to manage expectations with those outside of the team.

All Protecting the Customer and Organization: Because the development team does a good job with making the manager aware of the risks as they become known, the manager can notify the customer as early in the cycle as possible. Once the risks are known they are managed throughout the cycle. This allows the customer contact to manage expectations at their end. A byproduct of being disciplined with this process of protecting the customer results in successful projects and enhancing the reputation of the development team and organization as a whole.

Team Value System

Protection and process is all great but those items don't define what is being protected and why were the processes developed. Before processes can be designed and implemented there needs to be a team value system. The value system consists of the things the team views as important principles that are required to be successful.

There are several steps required to crystallize the team's focus of its value system as well as defining who the team is, where it's going, and how it's going to get there. Each of the steps should align with the organization, cost center, department, team, and individual.

1. Vision and Mission Statements: The team needs to know unambiguously why it exists and where it is going. If you don't have them, then write them. You'll be surprised at how much thinking you'll need to do.

2. Team Value System: A team's value system is essentially the rules of engagement at the individual level. Here is a small example:

• Team First
  
  • We constantly strive for balance of skills throughout the team.
  • There is redundancy within the team, e.g. primary/secondary client contacts.
  • Choosing the right resource for a particular task/project is dependent on:
    
    • Task/Project Context
    • Required Skills
    • Desired career path of team members
• Communication
  
  • We err on the side of over-communication
  • We are collaborative with solving problems
    
  • Conversation is more accurate than written correspondence
• Customer
  
• Everyone is everyone’s customer
• Super-pleasing is the standard level of service

3. Team Composition: This is the act of documenting how your team should be assembled; essentially what is the strategy with regard to the the required skills within the team and how that manifests itself into the types or categories of people needed to most effectively perform day to day activities. I'd suggest categorizing your current team members into each of the types that you identify to see if you are aligned properly.

Protection Through Process
Once the three steps are complete it is time to create the processes that ensure the value system is efficiently implemented on a day to day basis - without significant dependency on human oversight. Heavy involvement by people to ensure the plan is executed daily is inefficient because of the transient nature of people, the periodic unavailability of people, the expense of human oversight, as well as a host of other reasons. Processes need to be developed in a way where, for the most part, the team runs itself. This paradigm is scalable. When specific people leave the organization or become unavailable for periods of time, the processes don't fall apart. It also leaves people more time for innovations that make the processes stronger.

Teams and its members have good intentions that sometimes go awry. In most cases when things don't go as well as expected it is because the team/individuals don't have a clear idea of their value system and/or poor processes that don't protect them. The idea is to consistently put people in a position to win. In my experience, implementing the tools described here help teams be the best that they can be.

I'm interested in you thoughts.