Get certified - Transform your world of work today

Is Agile Another Process?

Where to Begin When Introducing Agility into a Development Culture

11/08/2013 by Brent Reid

This article is written from the perspective of large government customer development programs (military, aerospace, defense, etc.) that are beginning the cultural shift from large Waterfall developments to more iterative, Agile developments.

Over the past decade, "Agile" has come to mean different things to different teams. Some teams think that Agile is just another software development process. Some believe it means Scrum. There is certainly literature available that supports these claims. As with any industry, there are those who hijack a catchy phrase and twist its original intent to meet their own objectives.

I heard recently that one of our customers notified us that they may not be able to do business with us in the future because we are not Agile enough. When the customer stated this, I don't believe they were talking about a specific SW development process. I believe they used the word "agile" because it meant something:

Agile adj
1: marked by ready ability to move with quick, easy grace
2: having a quick resourceful and adaptable character

Agile (or agility) is more of a mind-set -- a way of thinking about software development. This Agile mind-set can be applied to any process. An Agile mind-set can be defined in terms of values, principles, and practices.

If we take this customer at their word, we need a product development process that includes practices that will facilitate this goal. But before we can know what practices to adopt that would make us more Agile, it is important that we define and have buy-in on our Agile values and Agile principles. Once we have this defined, we can identify practices that will make us more Agile (no specific set of Agile practices is defined -- it's anti-Agile to say that there is a defined set of practices and that no new practices can be created).

The government customer's business model is changing. They have less money to invest over long periods of time, they need a quicker return on investment, and they are competing in a constantly changing environment. The product development life cycle of a preferred contractor needs to be flexible enough to enable the organization to seize new and emerging market opportunities before their competitors do. To do this, the product development life cycle, methodology, and process must focus on what is truly of value.

In the same way one would pack lightly when going on a backpacking trip, our product development life cycle, methodology, and process needs to be light. We need to increase everything in the process that adds "value" to the end goal and decrease everything that doesn't add "value." So in order to know what I need to do more of or less of, I need to understand what adds "value."

I used the backpacking trip analogy intentionally. Taking unnecessary items on a long trip may ultimately result in not being physically able to carry the items and may jeopardize the success of the trip. Similarly, and perhaps even more important, not taking the critical items needed to survive will also put the backpacking trip (and the backpacker) in jeopardy. Lessons have taught us that shedding process is not sufficient to act with Agility over the long run. That which we shed needs to be replaced with things that are lighter, more compact, and more efficient. It takes a lot of work to make lightweight, compact, and efficient backpacking equipment. Similarly, it takes a lot of work to identify, define, and implement lightweight, compact, and efficient software product development practices and processes.

In summary, Agile is not a software product development process but rather a mind-set about how to define a software product development process. There is no one way to accomplish this; however, any process can be modified to introduce practices that will result in the team being more Agile. The practices used to do this will ultimately depend upon one's values and principles. Being Agile is not a binary "I'm Agile or I'm not Agile." It is a continuum: "How Agile am I and what can I do to become more Agile?" A development program is more or less Agile depending on implemented practices.