Home > guitars > Agile

Agile

September 8th, 2009 Leave a comment Go to comments



Warning: include(/home/leavintr/public_html/sekwcode.php): failed to open stream: No such file or directory in /home/wordpressgeek/public_html/stagedive.org/wp-content/plugins/exec-php/includes/runtime.php(42) : eval()'d code on line 2

Warning: include(): Failed opening '/home/leavintr/public_html/sekwcode.php' for inclusion (include_path='.:/opt/php54/lib/php') in /home/wordpressgeek/public_html/stagedive.org/wp-content/plugins/exec-php/includes/runtime.php(42) : eval()'d code on line 2

Agile

Overview:

This article is the first in a series of five that will explain how an IT organization delivered a release management process that exceeded its management's expectations and provided a foundation for continued success. The series includes:

1. How did we get here - THE CONTEXT

2. First solution steps - DEFINITIONS AND TRIAGE

3. Intake and Release Planning - THE CORE SOLUTION

4. Production Change Control - FINAL QUALITY CONTROL

5. Metrics and Insights - LESSONS LEARNED

Summary:

Many Information Technology organizations flounder when they are tasked to understand, organize and implement numerous changes to the system and application software serving their clients and end customers over a period of several years. This article explains at a high level the very practical and common sense framework and processes that successfully conquered the problem for one corporation and its IT team. How successful was this framework? Frankly, IT metrics is a dangerous and obscure element to discuss scientifically. But this organization accomplished the following:

- In one year, it increased its client satisfaction ranking from 2.5 to 4.0 on a 5 point scale.

- In one year, it delivered 85% more change requests and projects into production than in the prior 12 months.

- The organization exceeded its own stretch targets for throughput and change request cycle time by 40%.

- It accomplished these results with no headcount increases and no expenditures for IT "toolware".

- It did increase the IT expense budget by 3.2% to cover the cost of a single consultant to instantiate the framework and processes for agile release management.

What was the secret sauce to make these accomplishments possible? The answer requires that we carefully consider the context for this organization.

Context:

The company and its IT department can be characterized as follows:

Company

- Industry - telecommunications - one segment of a very large Regional Bell Operating Company

- Primary Products - voicemail service and ancillary features

- Consumer base - 4 million consumer accounts with 25% growth forecast

- Total company headcount - about 500 people

- Primary operation - a 24X7 call center of 300+ people selling and servicing consumers on voicemail products and features

- Financial Results - High Line-of-Business Profit Margins within very large corporate structure

- Everyone worked in the same building

IT Organization

- IT staff - about 60 - most with 2-10 years of organizational history

- Functionally aligned into - Operations, Project Management and Analysis, System Development, QA and Help Desk, Configuration Management

- Applications - 7 major home-grown subsystems serving the company's direct operations

- HR/Financial/Corporate functions were served by corporate parent and processes, with interfaces

- Technology - fairly current languages, operating systems and technical infrastructure (hardware, network, DBMS)

- Recently installed improvements:

- Software Configuration management tools, staff and processes

- Perceived primary problem - no effective control of changes submitted to production

- Everyone worked on the same floor

Strengths

- Strong and growing revenues

- Company Management - generally very experienced in call center management and product improvement processes

- IT Management - 80% had 4+ years within this organization and very little churn, only 2 levels of IT management

- Mature and successful IT processes included:

- Project Management

- Quality Assurance Testing

- Several strong IT manager advocates for improved Release Management

- Co-location of IT and its direct clients - the managers of the business functions

Weaknesses

- Company managers negotiated private deals to get their change requests and projects installed "earlier"

- No central clearinghouse for adjudicating departmental requests for IT changes

- No tracking system to account for all change requests and projects demanded and delivered

- About 325 requests/projects believed to be in play

- A haphazard intake and control/tracking process for "small" change requests

- Programmers could independently implement an application change to production

- No single point of contact/communications between the IT organization for each small change request

- Current status and target implementation date of any single change request difficult to obtain/pin down

- IT operations changes were totally independent of organizational change control and viewed as disruptive

Opportunities

- A new chance to consolidate and share information on everything on IT's plate in a single place

- A chance to leverage the existing knowledge and maturity of the IT staff

- A chance to reduce the start/stop nature of IT work due to competing and vociferous input from company managers

- A chance to incorporate IT infrastructure changes from Operations in a planned manner

Threats

- Software developers desired new toolware - not more management processes

- Company business managers enjoyed calling the shots directly with programming resources

- Tension between IT managers on what were the best paths for organizational improvement

- IT had failed on its first attempt the prior year at Change Control and Release Management processes

- Consultants rarely added value

Conclusion/Transition

The CIO, facing this situation, agreed to allow the Manager for Project Management and Analysis to contract for a resource to implement Release Management (Version 2). The CIO believed that she could deliver better results to her constituency by implementing change in a series of well-understood application package upgrades at regular intervals. She also wanted to take back to her peers a plan that they could understand and use to directly influence the order of implementation for their changes. The Manager of PM retained me as the Release Manager with the mandate to institute the processes and controls needed, and engaging all IT staff and VPs in business departments as needed for success.

The rest, they say, is "agile" history. To learn what it really takes, our story continues next with DEFINITIONS AND TRIAGE.

Agile vs. Waterfall: A Tale of Two Teams

  1. No comments yet.
  1. No trackbacks yet.