Agile application lifecycle management is not an oxymoron

A look at ALM

Business organizations generally strive to create uniform processes for safety's sake. When everyone has the same rules to follow and all decisions undergo the same stringent decision process, it's easier to believe that other folks' decisions are the best decisions possible. ALM gives organizations a framework for standardizing their software development processes from design to governance to maintenance.

Unfortunately, Conway's Law reduces the value organizations can receive from their ALM systems. Conway's Law states that "Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations." Therefore, it may be better to model the organization to match the needs of the software, rather than contorting the software to match our preconceived notions of the stages of development.

ALM relates mostly to planning, and planning is a double-edged sword. The good aspect of planning is that it forces us to think about the potential for disasters and about how to avoid them. But there is a dark side as well. Planning can be very wasteful, and the costs may outweigh the benefits. 

In a 1957 speech to the National Defense Executive Reserve Conference in Washington, D.C., President Dwight Eisenhower said, "Plans are worthless, but planning is everything." He also said, "There is a very great distinction because when you are planning for an emergency you must start with this one thing: The very definition of 'emergency' is that it is unexpected, therefore it is not going to happen the way you are planning."

Emergency planning naturally leads to creating plans for all foreseeable contingencies. All the arrangements that we make for contingencies that don't actually happen represent an amount of over planning. Plus, the emergencies that actually come up are likely not planned for and require reactionary handling as they occur. The value we receive from unused planning is very low and brings down the average benefit for the things that we plan for. The total cost depends on an organization's ALM, the number of plans, the number of reviews, the types of artifacts required and more. But the cost could be substantial.

A look at Agile

Agile can be defined as an iterative and incremental approach to software development. It is performed in a highly collaborative manner by self-organizing teams within an effective governance framework with "just enough" ceremony to produce high-quality solutions in a cost effective and timely manner that meets the changing needs of its stakeholders. That's a pretty big sentence, so read it carefully.

The values, defined in the Agile manifesto are: individuals and interactions over process and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan. Generally, the reason that Agile has become so popular is that it addresses the shortcomings of the "waterfall" ALM and keeps development aligned with the business better. Our job is to address what effective governance is within this desirable Agile mindset. As with any application lifecycle management effort, to make it effective, you will have to create one that addresses the customs and cultures of your organization.

Bringing the two together

Here is some practical advice to keep in mind when developing an Agile ALM.

Make sure the new Agile life cycle management process promotes high-bandwidth communication and relies less on stringent process and siloed artifact creation using tools. Rather, it should harness tools to create artifacts based on the conclusions that come from good communication, ideally both high-bandwidth and face-to-face communication.

Lean out artifacts to the point where processes speak to commonly accepted Agile development artifacts and practices, and don't try to merely "map" Agile on top of an old version of a heavy-weight document-centric development process (such as Waterfall or RUP).

Transition to the new Agile ALM in a Kaikaku fashion; introduce the new rules all at once and with great excitement. Start fresh and don't look back. However, allow the Agile ALM to grow through periodic retrospection and achieve incremental improvements in a Kaizen fashion.

Make sure your process strives for collaboration on necessary artifacts, decentralizes all but the core strategy, and only centralizes artifact aggregation and storage.

Pull team status from open information radiators (burndown charts, backlogs, CI server dashboards, etc.) Don't constantly ask for status and push it to a central authority for dissemination. Facilitate getting the right tools in place to allow those who want status to gather it in real time.

"Let those who ride, decide" as much as possible when it comes to tools. Enterprise architecture has its place. But a team that gets great results with a particular set of CI tools is worth supporting. Don't abandon their tools and make them re-implement something only because it fits the enterprise architect's PowerPoint presentation.

If we just remember that ALM is there to support the development process (with working software being the goal) and not to merely permit action on the goal, then the rest is easy. An Agile application lifecycle management is not only possible, but it's the right way to run a business and develop software for it.