March 18, 2014

Agile development has become the approach of choice in IT departments across the country, but problems with its management and shortcomings in implementation have made quite a few "agile" IT departments clumsy instead.

There is so much written about agile development and the wide spectrum of agile approaches; for example: SCRUM, Extreme Programming and Feature-driven Development. Agile has become part of the everyday IT lexicon, and IT development areas in most companies have adopted some form of agile development with varying degrees of success. Business areas have also undertaken agile projects, with mixed results. Many of us can cite IT and non-IT examples of agile projects that have been huge successes. That said, there are too many examples that became bottomless money pits and do not achieve their goals.

Gerald Shields, The Nolan Company
Gerald Shields, The Nolan Company

It's not uncommon to find divergent agile development processes and methodologies within the same company. Each project team changes the processes and/or approach to meet their specific project needs. To quote one IT professional I know, "Our company has a standard agile methodology that we follow at all times - except when we don't." Unfortunately this is not uncommon. It seems many organizations still believe agile means very little planning, loose schedules and no real end to the development project. Some organizations have taken steps to define and document their own "best practices" and have defined their methodologies and processes to produce predictable results. However, there are still many agile projects that are not managed with the controls and insights to deliver the desired business outcomes. No company can afford that kind of risk. Any company in that predicament should take immediate steps to get their agile processes and rules defined and institutionalized.

[Previously from Shields: Why an IT Service Management Approach is Crucial]

In today's integrated world, every project seems to be related to and dependent on multiple other projects. For example, a project might be dependent on a subject matter expert who is occupied by a late project. Yet another new project might be on hold until an architect frees up. Often there are environmental needs that are stalled, waiting for a project to get out of the way to free up server capacity or some other infrastructure constraint. It is not unusual for a project to be dependent on some functionality or business function that has yet to be delivered. I have found the web of dependency to be profound, murky and generally not clearly understood until the bottleneck reaches a critical point. For this reason, it is imperative that all projects be managed to meet delivery schedules.

Agile development projects are no different than "traditional" projects. They have dependencies, and they must meet schedule, functionality and delivery expectations. When agile development projects are managed effectively, they have the capacity to identify and remove these bottlenecks and free up the needed resources to empower better delivery throughout the development portfolio.

Best-run agile shops have adopted many of the practices from the discipline of production order management to keep the "agile factory" running like a plant floor. Mastering the order management approaches, techniques and disciplines to keep manufacturing lines running is critical to keeping the agile development lines running at full capacity. Just as the manufacturing world optimizes resources (people, equipment, raw material and floor space), so too should agile development teams. While raw material and engineering specs must be tuned for the manufacturing plant floor, so too should agile application development "specs" tune resources for full utilization. The raw material for development is the data and the functional requirements. Time spent waiting for raw material (business specs, design specs, etc.), equipment (server resources, space, etc.) and parts (data) is wasted and drives up the manufacturing (development) cost. Even worse is the latency on the business side waiting for needed functionality. This directly correlates to other projects now waiting for functional requirements and the data to complete the development process.

As agile development is now generally accepted in most IT shops, IT leaders must embrace process improvements to capitalize on the proven methods in the manufacturing world and tune the development world to keep the agile development lines running at full capacity.

About the author: Gerald Shields is Practice Director, Healthcare IT for The Nolan Company. Gerald has over 30 years' experience managing enterprise scale IT functions, with a focus on enabling the business through effective automation. At Aflac, he served as CIO and in senior IT management for over ten years, and is a respected thought leader and innovator in the areas of IT management systems, technology strategy, and mobile technology.

[To hear about how insurance companies and financial firms are managing their complex data architectures, attend the Future of the Financial Services Data Center panel at Interop 2014 in Las Vegas, March 31-April 4.
You can also REGISTER FOR INTEROP HERE.]