When I very briefly joined TCS (Tata Consultancy Services) as an IT service management (ITSM) consultant a year ago today, I met a fellow new recruit Sandy Winschief – a vendor/supplier management specialist armed with a pair of Six Sigma black belts. Sandy was/is a key piece in TCS’ Service Integration offering jigsaw and someone who made me think more about the relationships between IT infrastructure and operations (I&O) organizations and their suppliers.
Sorry, you said, “Service Integration”?
For those new to Service Integration I offer the following “definition” from a Forrester colleague’s “thinking”:
“To make multisourcing arrangements effective, customers must get suppliers to work together, both from the commercial and operational standpoint. The services integration layer, comprising elements of process, tools, service-level agreements (SLAs), and related structures, is absolutely critical to the success of these arrangements.”
If you've been reading the research I've been writing over the past year, you know that I'm a fan of implementing an application life-cycle management strategy that focuses on increasing development flow and supports high-performance teams. You don't need to religiously implement all 22 CMMI processes or deliver dozens of intermediate development artifacts like some leading processes advocate. Rather, there are certain important processes that you should spend your time on. We wrote about change-aware continuous integration and just-in-time demand management in last year's Agile Development Management Tools Forrester Wave™. They are two of my favorite areas of focus, and they are great areas to invest in, but once you have them working well, there are other areas that will require your focus. In my opinion, the next process where you should focus on flow is everything that happens post build and preproduction. Most folks think about this process as release management or configuration management, but I think there's a better term that focuses on how quickly software changes move through both processes. It's called continuous delivery. When you focus on establishing a process of continuous delivery, you'll find that your capacity to release changes will increase, your null release cycle will shrink, and a larger proportion of the productivity gains you've seen from your Agile development efforts will flow through into production.
Recently, I spoke with a major airline about their adoption of Agile, which they considered critical for a major customer loyalty project. Based on previous experience, the dev team expected the business users involved in this project to move slowly, so they saw Agile as a strategy for being ready to pounce on any opportunity to make progress. How slowly? The current estimation for the project's completion was....[drumroll]...five years. Now that's a customer loyalty program ensured to be left with just the most loyal customers imaginable.
As hair-raising a situation as this might be, it's hardly unique. App dev teams contributing embedded software elements to hardware products must time their deliverables to arrive at key landmarks in the overall release schedule. Compliance requirements weigh down software development with extra documentation and validation. Flawed requirements force teams to go back to the drawing board. Dev managers live and die by the schedule, and there's always something that could jeopardize the schedule. Development is pretty pointless unless someone delivers the bits and bytes, but dev ops still remains a relatively mysterious and unpredictable process for dev teams, over which they have little control once they throw their code over the wall.