I’ve been working in the Collaborative Lifecycle Management (CLM) team in various development manager roles for the last three years. Recently I’ve moved into a role that will let me focus on helping the CLM organization deliver more frequent releases. After 20+ years working for IBM and 10 years as a development manager, this is a very exciting time for me. Continuous Delivery and DevOps are very hot topics lately. To some people these terms are somewhat interchangeable. To me, however, there is a distinction. DevOps is a very important part of being able to deliver more frequently, focusing more on the tools and infrastructure to support development and operations but there are other aspects to Continuous Delivery that are also important. The development and release processes as well as culture across the organization are also critical pieces. In order to support a frequent delivery model you must have the ability to quickly and reliably build your offering. You then must be able prove the quality. This might start with being able to deploy the offering into a test environment using an automated deployment technique. Then you want a comprehensive set of automated tests that cover unit, functional, system, and performance testing. However, you also need to define the “right” set of tests because you need to understand the test results quickly. Depending on whether you are creating an offering for the Cloud or one that will be installed on premise, you might also want an automated deployment tool to push to the Cloud. All of this assumes you’ve got the surrounding process in place to support this, as well as the buy-in of the entire team. If everyone is not engaged in making you successful, it will be a long uphill battle.

For the Collaborative Lifecycle Management (CLM) team, we have chosen to focus on five areas: automated test coverage, deployment pipeline, build time, development process, and culture. We are still very much in the middle of our journey to Continuous Delivery. We face significant challenges each day. Our builds still take too long. We need more automated tests, and we need to define the right set of tests that need to run to prove a build’s quality. We have a deployment pipeline that is used for test, but we need to expand beyond that. Being IBM, we have a lot of good processes, but some of them need to be optimized in order for us to deliver CLM more frequently. Then there’s culture. Not only do we need to help ensure developers are bought in with our plans, we need to ensure our executives, our support team, marketing, sales, etc. are also all bought in.

So what have we done so far? We have delivered a full CLM mod-release every quarter starting with the 4^th quarter 2012, which is what we committed to ourselves to do. This represents a tremendous effort from our entire team. We have also made progress in each of the five areas we have focused on.

We have identified separate function and system level testing teams. These teams have focused on creating automation frameworks and automating as many different tests as we can, including system, function, upgrade, build verification, and more. We still more manual testing than we would like, but we continue to work on improving our automated coverage. We have also established a dedicated performance team to ensure the right level of focus on performance aspects of our offerings.

We have created a team that is focused on automating deployment of our offerings. Right now we are only automating into test systems, but in conjunction with the increased automated tests, this has helped increase the speed and reliability getting from build to test.

We have invested a lot of effort to improve our overall build time. Through a focused effort to better orchestrate how we build all of the parts of CLM. We are also starting to explore different build technology and other ideas to help improve our build time.

We have made several changes to our development process, ranging from how we structure our teams to how we ensure getting our features “done”. We have created teams with dedicated focus on responding to customer issues, working on improving the overall quality of our releases, and new features. This will give people the chance to focus. We have also created a checklist of items required to complete a plan item. You can see this in any of the plan items in the release plans across the CLM teams. This has really helped the developers stay focused, and get some of the ancillary items, like New and Noteworthy, done while the feature work is still fresh in their mind.

Culture is one of the more difficult areas to measure. All of the changes I’ve mentioned above are designed to make the day in the life of our team better. As we continue to improve each of these areas it will have a positive impact on everyone’s impression of the benefits Continuous Delivery can bring to our team.

Across all five of these areas, we have made significant improvements over the last several months. However, we still have a long way to go.

I encourage you to read our posts on the Jazz team blog to follow our progress. As a team we will be blogging about these five different areas as we continue to learn and make progress. I also encourage you to share your thoughts and experiences with us. We want to hear about and learn from your successes. We want to collaborate on the challenges we all face.