 An old "I Love Lucy" episode shows Lucy and Ethel working at a candy factory. Their job is to take pieces of candy off a conveyer belt and put them in packages. At first everything goes well. Lucy and Ethel have this candy packaging thing down pat. Alas, things start to change. The conveyer belt sends out candy faster and faster. At first Lucy and Ethel try to cope. They try to work faster. Then their work gets sloppy. Finally, rather than packaging the candy at all, they resort to throwing it away, or even eating it. A quick leap of the imagination would show retailers struggling to get the additional candy packages on the shelf, customers refusing to eat more candy just because there happens to be more available, and the factory management struggling to get their supply chain responsive to the faster manufacturing process.
The moral, of course, is that just because you are able to make candy faster, it doesn't mean you can make more money selling more candy.
What does this have to do with agile software development? Agile software development promises to help development bring software to production faster. Rather than every six months to a year, application development may be able to deliver software updates or new capabilities every month. While that is a laudable goal, it won't make any difference to the business if the other ends of the software pipeline can't adapt to the faster pace.
Consider the Program {sidebar id=1} Management Office (PMO) or other project approval agency. Before Agile methods became widely accepted, projects were approved based on a business case and requirements that specified the cost, scope, and timing of a release. With Agile methods, requirements are assumed to change over the life of the project, so scope as defined in the past is variable. Clearly the two philosophies are at odds.
One way around this problem is for application development, in league with the business analyst, to construct a fictional account of scope just to make the PMO happy. They define a set of requirements, do the analysis of these requirements, and get funding appropriately. All the while knowing with a wink and a nudge that everything will change as soon as the ink is dry. Unfortunately, this isn't mere theory. I have seen this approach in use at several organizations, and it causes friction between the PMO who believes application development is deceitful, and the application development team who believes the PMO is inflexible and driven by bean-counters rather than people wanting what is best for the business.
An alternative was suggested by an agile practitioner I met at a conference recently. His organization no longer defines scope as a set of features and functions to be implemented, but rather as business objectives achieved. For example, in the past, scope might be defined in terms such as ‘Modify eCommerce Web pages to reduce the number of clicks needed for a customer to get help.' Instead, the scope would be something like ‘Decrease eCommerce page abandonment rate by 30%.' This type of measurement clearly limits the scope of the release in terms of business objectives and gives application development the freedom to figure out how to do it as the project progresses.
Regardless of how your organization will eventually solve the funding problem, both the PMO and application development team will have to evolve and define a project approval approach that doesn't interfere with development methodologies, isn't based on known deceit, and includes accountability.
Now let's move to the other end of the application development pipeline. Consider what happens when development delivers software to production, usually through a hand-off to IT Operations. IT Ops often sees its top priority as protecting the production environment. The implications of this philosophy have a great deal to do with how application development hands off to IT Operations. The burden of proof is necessarily on application development to demonstrate that new releases won't disrupt production. If there have been past disasters, it's likely there are multiple sign-offs and extensive acceptance testing in place before anything new will be deployed.
As application development speeds up its delivery, IT Ops is unable to take the updates. Current processes may be able to support somewhat faster delivery, but in the end IT Ops will become a bottleneck, and much of the advantages application development expected to gain will be lost. The IT conveyor belt will simply drop these faster releases on the floor.
As with project funding, solving the production delivery bottleneck will require changes both in application development and in IT Ops. IT Ops has to change its focus from protecting the production environment to enabling the business, and application development has to be much more concerned with quality. Both have to learn to trust each other. This trust will grow over time, and can be facilitated by some practical steps.
IT Ops should automate a number of activities that are now performed manually. Application provisioning through virtualization software is a good first step. IT Ops should be able to set up a virtual test environment automatically when software is released by application development. Automated performance, security, and functional testing should be part of this step as should automated sign-off based on these test results. Rolling out a new release to the production environment should take hours, not days. Finally, IT Ops should have a rollback plan in place for any software release. As with the release to production itself, IT should be able to roll back a problematic release in hours, not days.
Application development must be fanatical about quality. This is especially true in an SOA environment where a single bad service can take down a number of applications. This means automated unit testing, automated security testing, automated performance testing, and, wherever possible, automated integration testing. Application development must also clamp down on unauthorized changes. If the theme of the release is to improve the customer experience on the eCommerce site, don't allow rogue changes to the reporting engine. Remember, you don't need to throw everything into the release. You don't have to wait six months to get the next set of changes into production. Another release vehicle will be along soon.
Now take the story a bit further. Assume that the funding agency and application development work out their differences. Assume IT Ops and application development are aligned so a release can go into production every month. Unfortunately, this won't help deliver value unless the business can take the changes.
Long application development schedules often result in complex and fairly disruptive changes to the way end-users do business. If you only get one or two chances a year to change the application, everything and the kitchen sink will end up getting thrown in. There will be minor changes, major changes and even some completely disruptive changes. End users expect software updates to be troublesome. Now you want to deliver these changes at a faster and faster pace. What do you think the business will say if you tell them you want to update their software every month rather than once or twice per year? I suspect the response from business will be unprintable.
As with IT Ops, application development will need to build trust with the business stakeholders. Rather than have omnibus releases every month, make sure the release has a theme and will only change or disrupt one part of your end-user community. For example, if you want to update your eCommerce application monthly, have one release concentrate on updating the shopping cart experience, another concentrating on metrics, and a third only for streamlining the payment process. It doesn't matter that reporting also needs work. Remember, you don't have to wait a year for your next release. Concentrate on one area, limit the disruption and work with the business to make sure they understand what you will deliver when. Finally, be aware of the business calendar. If you run a retail site, you wouldn't touch the eCommerce site the month before Christmas. Don't go near finance the last quarter of the fiscal year and stay away from CRM the last three weeks of any quarter.
Successfully moving to agile methodologies can significantly decrease the amount of time it takes to turn a business idea into software. However, this transformation must reach beyond application development. The PMO, IT Operations and even the business will need to change to make sure these changes are put into, production without disrupting operations.
The alternative is candy all over the floor.
About the author
Kevin Parker is Vice President of Market Development at Serena Software. He has over 25 years of experience in the industry, nine of them with Serena. Parker also serves as an Eclipse Application Lifecycle Framework (ALF) Project evangelist. He has extensive development, consulting, and management expertise and is a sought after speaker here and abroad.
Comments 
Write comment
|
Show/hide comment form