I’ve been working for IBM for over twenty years and I’m currently assisting the Collaborative Lifecycle Management (CLM) team in its adoption of DevOps with the goal of enabling continuous delivery. I was previously the development manager for the CLM project and for Rational Team Concert. I’m also a jazz bassist and bandleader. When I have the time I write about the parallels between jazz music performance and software development as well as other fields.

The Jazz team has been doing agile development for many years now. While we began the Jazz project in 2005, many of the developers in the Jazz team were involved in Eclipse before it was released to open source in 2001 and before that many of us were using iterative methods and doing pair programming, test-driven development and rapid prototyping in Smalltalk for many years. You can read more about our history here.

It comes as a surprise to some that agile methods are now over twelve years old and that’s if you consider the declaration of the Agile Manifesto in 2001 as the birth of the agile movement. In fact many incremental, iterative, and adaptive software development approaches and techniques such as Scrum and Extreme Programming were developed in the mid-1990s.

Given the incredible pace at which the software industry evolves agile could now be considered old news yet agile continues to be a hot topic of discussion. Despite the wealth of information and an abundance of experts many teams and organizations still struggle with gaining the real benefit of agile methods which is simply to develop agility. Agility is, quite simply, the ability to respond to change. In today’s fast-moving and tumultuous world agility is needed to stay ahead of the competition or perhaps even simply to survive in the face of constant complexity, confusion and chaos. The adoption of agility is a constant journey. Despite the Jazz team’s long history of using agile methods, we’re still seeking to be more agile every day.

In 2011, ten years after the Agile Manifesto was written, ten of the manifesto authors reflected on the success of the agile movement. They concluded that while some people, teams and organizations had adopted all the trappings of agile methods with agile tools, agile processes, and agile certifications and titles, they had failed to become more agile. As Andy Hunt, one of the authors of the Agile Manifesto, observed, teams “knew how to do agile; they didn’t know how to be agile.”

It’s easy to forget the greater goal when you’re spending your days in the trenches. When I speak to teams in the throes of agile adoption I often ask people to describe the goal they are pursuing and all too often many of them are not sure. They are so preoccupied with the doing that they forget why they are doing. Sometimes it simply hasn’t been explained to them. They received orders from above to use certain tools and adopt specific processes and they proceeded to carry out those orders. In other cases they’ve simply bought into the cult of agile preached by the press, the agilistas, the tools vendors and the consultants. Yet as Andy Hunt wrote, “true agility goes beyond the dogma, beyond the practices. Agility is about adapting; adapting your process, your language, your tools, your team, and yourself to respond to the situation at hand.” Being truly agile demands fundamental cultural changes and not just the adoption of tools and specific processes.

Another reason teams may fail to realize the full value of an agile approach is that agile methods traditionally focused on transforming development cycles but did not necessarily address deployment of finished software into production. Continuous delivery focuses on optimizing throughput of the deployment pipeline that delivers software from development to release using automated, verifiable, repeatable steps. The term “continuous delivery” comes from the first of the twelve principles described in the Agile Manifesto: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” Continuous delivery typically demands collaboration across organizational boundaries with dev, (test), and operations all working together to improve the pipeline throughput. The ultimate goal of continuous delivery is to have a pipeline that’s optimized enough that you can deliver new quality software to production in minutes. This effectively means that your codebase, or at least some stream of it, must be in a constant state of release readiness. With such a requirement it’s not surprising that adoption of continuous delivery also requires fundamental cultural changes. The idea of continuous delivery includes not only software-specific activities such as continuous integration and continuous deployment but more fundamental activities such as continuous learning (often through constant experimentation with measurable results) and continuous improvement.

Since 2012, the Jazz team has been adopting DevOps processes and tools with the goal of continuous delivery. Before we began that transformation we were shipping releases with new features every twelve or sometimes every six months. Recently we’ve moved to a quarterly cadence of releases but our goal is to do much better than that especially for customers running on a hosted offering. Our Collaborative Lifecycle Management team is leading the way to more rapid delivery of releases of Rational Team Concert, Rational Quality Manager, Rational Requirements Composer and other products. We’re telling the ongoing story of our journey to transform our development and business processes through posts on the Jazz team blog.

Check out these other posts from some of my colleagues in the CLM team:

• Jeanette Deupree, the leader of our continuous delivery transformation effort, writes about what continuous delivery means to her.
• Maneesh Mehra, the architect for our deployment pipeline, writes about the progress we’ve made to date and the plans for future work for improving throughput in our deployment pipeline.
• Kevin Williams, a test architect in our System Verification Test (SVT) team, writes about how we’ve leveraging the cloud to enable continuous delivery.

Also look for these forthcoming posts:

• Frederic Fusier, the Automation Lead in our Function Verification Test (FVT) team, will write about the improvements we’ve made in automating our CLM Build Verification Test (BVT) scenario.
• Robbie Minshall, our continuous delivery implementation architect, will write about test practices that were employed when he worked for the WebSphere team and how we’re applying those in CLM.
• Pete Steinfeld, a build infrastructure architect, will write about the changes we’re making in our build infrastructure to enable faster, more reliable, continuous builds.

We’ve got many other members of our teams lined up to tell you about their work and we’re eager to get your feedback and hear about your experiences in adopting DevOps and taking agility to the next level.