When Should We Utilize an Agile Approach?

November 25, 2013

Our goal with planning software projects is predictability. But as we’ve proven with traditional approaches, our age-old enemy – variability – inevitably creeps into the equation to wreak havoc with our plans. This isn’t a planning failure; it’s a failure to assume that we can plan with certainty up front.

The Cone of Uncertainty (McConnell, 1998) is an excellent visual model that captures this dynamic. It plots the range of variability encountered with software projects as they progress through time. Figure 3-1 depicts the general shape of the Cone of Uncertainty, minus the actual data points used to create the cone.


Figure 3-1

The Benefits of Agile Change

November 15, 2013

If you are going to adopt agile, you are in for a change. But why change? What are the benefits that you should expect from agile development? In other words, what is in it for you?

In the latest VersionOne State of Agile Survey, ninety percent of the respondents reported improvement in managing changing priorities by implementing agile. This is not a big surprise since agile is often billed as being able to respond to changing requirements.

In that same survey, eighty five percent of the respondents reported an increase in productivity. Since agile development is a lightweight approach to software development, we should expect an improvement. Less overhead – while retaining the necessary framework for coordinating and managing work – certainly contributes to improving productivity.

Couple this with a few other ingredients like greater collaboration, combining of conventional tasks to reduce formal handoffs and practices designed to increase feedback and produce working software in short cycles with quality, and we have the critical elements in place that lead to greater productivity.

Here’s a reported benefit from the VersionOne survey that might make you think: Eighty-four percent of the respondents reported an improvement in project visibility.

Despite all of our planning, reporting and tracking with non-agile approaches, agile still manages to improve project visibility. What is the difference?

The Breadth of Agile

November 7, 2013

As I thought about the model in Figure 2-1 from my last post, I adapted it to make something else more explicit when talking about agile development and setting agile expectations. This speaks to the breadth of agile as opposed to its depth.

I observed that the bottom three layers are more timeless than the top layer. Specific frameworks are implementations of agile; practices and techniques may change over time while the values, principles, and characteristics are qualities that will stand the test of time. So I lopped the top layer off. This provides us with a deep, rich set of agile qualities that comprise a common core.

And while these agile qualities comprise a common core, they will be realized in different ways at a personal, team and organizational level. And these elements are all interrelated, as Figure 2-2 depicts:


Figure 2-2

Now we have a little more to explore as we consider the previous learning example. Agile is now being implemented broadly, giving us depth and breadth. Let’s start with personal agility.