Proven, Practical Tactics For Agile IT Release Management - Lessons Learned

Overview:scoring did not differentiate between performance in
This article is the last in a series of five which explainOperations, or on Projects or on implementing Change
how an IT organization delivered a releaseRequests. It was the simple view of their Overall
management process that exceeded itsSatisfaction. We believe that the efforts on release
management's expectations and provided a foundationmanagement were a major factor in raising the score
for continued success. The series includes:from the prior year. Another major win was that the IT
organization turned the corner on the Year 2000
1. How did we get here - THE CONTEXTwithout mishaps.
2. First solution steps - DEFINITIONS AND TRIAGEChange Requests Completed or Cancelled The
3. Intake and Release Planning - THE COREconsulting engagement began in early May of 1999. At
SOLUTIONthat point in time the definition of Change Requests did
4. Production Change Control - FINAL QUALITYnot include production software changes caused by
CONTROLmajor projects. Using the new definitions of what
5. Metrics and Insights - LESSONS LEARNEDRelease Management considered an in-scope Change
Summary:Request, the base of Change Requests Completed
Many Information Technology organizations flounderwas expanded for the earlier time period so that a fair
when they are tasked to understand, organize andcomparison can be drawn. The IT organization, using
implement change to the system and applicationRelease Management, dispatched about 85% more
software serving their clients and end customers overChange Requests over 12 months. As a parallel
a period of several years. This fifth article focuses onmetrics observation, the IT group set annual targets for
the key results of the solutions developed during thecompleting change requests. Their goal for the year
Release Management consulting engagement. Please1999 was 140 (this was considered an aggressive
refer to the first Article - THE CONTEXT for a fulltarget at the time). On a calendar year basis, IT
discussion of the problem domain and organization, tocompleted 172 Change Requests in 1999.
the second article - DEFINITIONS AND TRIAGE for aMajor Projects Completed In case people wonder if IT
discussion of the get-ready steps, to the third, THEjust re-directed effort to do more change requests,
CORE SOLUTION for details on planning releases, andthus short-changing the efforts on projects, the
to the fourth FINAL QUALITY CONTROL to learnnumbers for major projects are shown. We do not
how implementation quality was improved. Theseknow what % of total resources were used year
articles all were entitled Proven, Practical Tactics forover year, as project-hour accounting was weak.
Agile IT Release Management. Now is the time toGiven that the Year 2000 Project was a major
assess how "Agile" were we? This Releaseendeavor, I offer that it is safe to assume that there
Management process was implemented in 1999,was no disproportionate shift of resources that
without benefit of access to the thoughts and ideasfavored better Change Request results.
published following the Agile Manifesto. We also haveAverage Age of Change Request Backlog We
some basic metrics to consider and explain, anddecided to consider how well we were doing in terms
thoughts on the lessons along the road.of reducing the amount of time the clients were
How Agile Was This Work?waiting to get their Change Requests taken care of.
I willingly concede that there are experts in the AgileFor the period in question, no significance can be
community who are far better qualified to render anobserved. At least it didn't trend up! Our first-hand
opinion on how closely this work conforms to theexperience was that we were getting to the high
principles of Agile Software development and thepriority requests quicker, but we didn't collect metrics in
complementary Scrum approaches to Product andExcel for this.
Enterprise Requirements management. On the oneSize of Change Request Backlog In a similar vein, we
hand this was not a discussion of softwarekept an eye on the total change requests. We saw
development. The Agile Manifesto states (Author'sminor fluctuations, but in general, the client community
Note: the specific reference for this quote is given atwas always submitting more improvements. There
the end of this article): "We are uncovering ways ofwas no budgetary chargeback mechanism from the IT
developing software by doing it and helping others dodepartment to the VPs, so asking for more IT work
it. Through this work we have come to value:had no direct consequences for them.
Lessons Learned
1. Individuals and interactions over processes and tools
2. Working software over comprehensive1. First and foremost, the direct investment made in
documentationRelease Management implementation brought better
3. Customer collaboration over contract negotiationthan expected results for the stakeholders.
4. Responding to change over following a plan"2. I was amazed and delighted to see the Wall of
Our process work was very steadfast, disciplined andIndex Cards morph over time to be a more elaborate
critical to success. Our interactions were frequent andinformation radiator for the organization. One example
very focused. We used plain cheap tools, butwas the addition of colored dots to the cards for Top
exceedingly well. Individuals - we used everyone's5 and also QC status. We also got tricky with
strengths to succeed. I'd give us a grade of a B onpositioning cards above and below certain horizontal
item 1. The Release Management process took nolines to convey new information. We also started to
notice of the interim steps of software development. Indisplay the thermometer of completed change
fact we stripped out tracking of interim dates, then putrequests versus the annual target (it was uplifting).
back in the importance of starting QA. The only thingThere is a lot of truth to the adage that you learned
we worried about was production-ready software. I'deverything you need to know in kindergarten.....
give us a grade of A. On customer collaboration, we3. The solutions we applied were just about perfect
certainly improved communications about what wasfor a collocated organization with the configuration
being worked on (and what wasn't also was obvious).management and QC processes in place and an
We definitely showed the VPs that we were trying toorganizational commitment to release management.
slide their Top 5 requests in at the earliest juncture in4. The CIO, seeing that the process was successfully
the overall plan. The Release Management processembedded, at the end of 1999 asked the consultant to
did not operate at the level of the software'sdo a fresh study of the commercial software market
requirements, design and functionality. In essence wefor supporting tools in the Release Management arena
just did a great job of clearly starting and stopping- none were found that could match the team
work. I'd give us a B on item 3. This process excelledeffectiveness we achieved with cards on a wall.
at responding to change over following a plan. Every5. The role and actions of the Release Manager were
week we would build a firm Release Schedule for 6very well defined. Hence, I prepared a transition plan to
Releases, and the very next week we would re-workbring in an internal manager for the ongoing position of
the whole thing due to circumstances and reality. WeRelease Manager. It took over 4 months to locate and
did that with clarity, collaboration, understanding andtrain a replacement candidate for the permanent
high levels of communication. I'd give us an A+ here.position. The first chosen candidate just couldn't keep
Metricsthe pace of detailed item management that was
I will restate my opinion that 99% of the publishedrequired.
material regarding IT processes lack meaningful6. If this problem had involved 600 Change Requests, it
statistical indicators. There is a lot of "crowing" aboutmight not have worked at all. As long as we had
methods and tools, but not a lot of believable concretefewer than 350, we could handle it on one wall and
information. Also, keep in mind that IT headcountsyou could read every card from about 15 feet away.
were held constant for the periods in question. Here isThere are limits to this media/storyboard approach.
a sample of the data and metrics we collected:Conclusion/Transition
Release Management Selected MetricsThere is a huge amount of value to creating a Visual
Year End 1998 Year End 1999 ImprovementDecision board that covers the whole problem for an
Customer Satisfaction 2.5 4.0 60.0%organization. This general finding can be applied in a
6/1/98 - 5/31/99 6/1/99 - 5/31/2000 Improvementlow-cost manner to many problems. In my research to
CRs Completed or Cancelled 97 218find an adequate software package solution for
Including Project Releases 118 218 84.7%Release Management, nearly all stumble on the
Major Projects Completed 10 15 50.0%problem of scale on a 21" computer monitor. To this
As of 5/31/1999 As of 5/31/2000day, the tenth anniversary of this endeavor, only very
Avg Age of CR Backlog 197 days 187 days -10 dayssophisticated hardware systems and conference
Size of CR Backlog 307 297 -10 CRsroom environments begin to match THE WALL and
Customer Satisfaction - IT The CIO conducted a verythe practices we used. I smile each time I see a
simple poll of the senior managers in the organizationmodern spy movie, or "24" or CSI Miami dazzle the
each year, asking for an overall degree of satisfactionaudience with technology for the virtual space and
with the IT performance for the prior year. On a scaleindex card/puzzle manipulation approach in a
of 1 to 5, the 10 managers selected from Verysophisticated manner.
Unsatisfactory (1) to Outstanding (5). This simple