 Introduction
The current market trend for producing software nowadays is to apply Agile methodologies such as Scrum and the like. The benefits can be huge and on an enterprise scale those benefits easily run into the millions of dollars. However, in those same enterprises we see observe a typical pattern when software comes out of its production phase and needs to be put in operation: a package is delivered to another department, and is then deployed on production systems. This is the area of software deployments.
We claim there generally is a lot of waste in the deployment process and the elimination of that waste can easily save funds in the 1 million dollar order. We will first discuss what is waste in Agile terminology, then point at waste in a general deployment process after which our claim simply proved when observing what KLM/Air France did to minimize its waste.
Waste
In Agile terminology, waste is defined as anything that does not contribute to the final result. There are many sources of waste and the typical example is creating a full blown design of a software system before starting to build it. During the build phase requirements often change leading to original requirements becoming obsolete. At that time all design work on the now dropped requirements becomes waste: it does not contribute to the end result anymore.
A very generic area where we find waste in is in waiting. Waiting obviously does not contribute to any end result. We do an enormous amount of waiting in our day to day jobs: we wait for the meeting to start, we wait for the traffic jam to dissolve, we wait for the coffee not to drip from the machine anymore, we wait for the status report, for that important email to arrive, etc, etc.
Once you have learned to see waste, you will be surprised: it is everywhere. At the level of an enterprise size organization you will now understand we are talking millions of dollars that can potentially saved.
Waste in software development
When we observe modern software development we see that a lot of waste has already been eliminated from the software production process. Development teams are provided with a whole suite of tools for building, testing, refactoring, co-authoring, reviewing, etc. Agile ways of working further eliminate waste: the team is co-located to avoid waiting for one-another, meetings are prevented by shielding the team from “the business”. Working in iterations eliminates waste in design work caused by “big upfront design” and provides crucial early feedback. The list of waste eliminations already applied is quite impressive. Still there are areas for improvement and this should be of ongoing concern to development teams as it will increase team velocity.
Waste in software deployments
Once the development team is done, their product needs to be deployed. Here we are in for a surprise: where waste elimination in software development has seen many advances over the last years, the deployment process found in enterprise size organizations is commonly found to contain huge amounts of waste!
The enterprise typically employs two different departments: ‘Development’ and ‘Operations’. When software is ‘done’ it needs to to into production. The former is handled by ‘Development’ where the latter is handled by ‘Operations’. As a consequence, we see a hand-over. Any hand-over is a potential source of waste. Let us take a closer look at some typical scenarios we find.
Deployment to test machines
Test machines are usually administrated by ‘Operations’ as these are shared resources. Developers are not allowed to put new versions of their software on these machines or on middleware running on these machines. In other words, Operations has put strict change management in place and for good reasons. Multiple groups must not be in each other’s way. Acceptance test systems need to mimic production systems as much as possible, so the configuration of middleware can not be changed lightly. Clusters need to be set up, memory and disk space allocation settings are crucial. Load systems must not be interrupted during a load test or wrong conclusion may be drawn from its measurements.
Deployment to production machines
As with test machines, Operations usually applies strict change management to production systems. It goes without saying that compared to test systems the procedures are even more strict.
Impact of hand-over
Although there are good reasons for strict change management, it is also a huge source of waste. We give just a few examples.
When a developer works late, the deployer has gone home so the developer waits. When the deployer arrives the next day and runs into a problem, he has to wait for the developer who comes into office late that morning as he made some overtime.
When the developer team things they are ‘done’ and want to start an acceptance test, the deployer is not available as he is attending a team meeting. The whole development team now waits.
The load tester is done and wants to start a new test. He needs to wait for a deployer to become available to do the deployment work for him.
The elimination of waste in software deployments: self-service deployments
Can we eliminate waste in the deployment process? Yes we can! Note in all cases any solution needs to adhere to the strict change management process put in place by Operations.
The key to the solution is the introduction of ‘self service deployments’. That is, the deployment process is highly automated and implemented by Operations. That department stays in control, but becomes a change enabler to Development.
Software deployments at KLM/Air France: 1 million dollar saved yearly
KLM/Air France has implemented self-service deployments in their organization. Developers can deploy new versions of their software to Test systems at will, but they can not modify middleware configurations such as port numbers, or modify cluster configurations. Load testers are in full control of their load test systems. Deployers do deployments to the production systems faster and less error prone than before due to advances in automation of their process and the strict change management control that is automatically adhered to by other user groups.
Savings achieved
KLM/Air France management has computed to save a total of about 1 million dollar yearly, due to elimination of waiting time and more efficient utilization of shared resources. The interested reader is referred to [2], or [3].
Conclusion
Software deployments tend to be overlooked as a process that can be improved in terms of waste elimination. The KLM/Air France case shows waste due to hand-overs in the software production process can be eliminated to a large extend without breaching strict change management rules bringing huge yearly savings to their enterprise.
References
[1] “Lean Software Development: An Agile Toolkit”, Mary and Tom Poppendieck, Addison-Wesley Professional (May 18, 2003), ISBN-13: 978-0321150783
[2] “Unleash the Agile power: bridge the Gap between Development and Operations”, J. Sutherland and W. Koorn, Proceedings of Agile 2010, USA, to appear August 2010.
[3] “Agile Deployment Automation - Bridging the Gap between Development and Operations”, W. Koorn, http://www.xebialabs.com/agile-deployment-automation-bridging-gap-between-development-and-operations
Dr. Wilco Koorn learned programming in 1978 during his physics study when it was the punch card days. He holds a PhD in computer science from the University of Amsterdam since 1994. He has been working in many roles in computer industry since that date. He worked as developer, senior developer, architect, (project) manager and technical director in both large (14000 employees plus) as well as in small start-ups. In almost all these roles there was a large focus on how to optimize the software development process, both from the human interest point of view as well as from the automation of support processes point of view. Wilco is using Agile methodologies since 2000 (eXtreme Programming) and became a Certified Scrum Master about three years ago.
Wilco is currently Scrum Master of a team developing a product aiming at automating the deployment of complex java enterprise systems to enterprise middleware.
Trackback(0)
Comments 
Write comment
 |
CM Journal Articles 
TrackBack URI for this entry
Subscribe to this comment's feed