Agile projects very often seem to stall out after gaining perhaps twenty-five percent of the possible benefit. Why is this? What can be done?

agile barrier

If your organization is like many others, you have adopted Scrum or another “Agile” method. You have received some benefit and are glad you have gone Agile. Yet very likely you feel there should be more – and you’re right!

The creators of Scrum agree: Ken Schwaber has said that perhaps only twenty-five percent of Scrum teams get the full benefit of doing Scrum. Jeff Sutherland has said that every high-performance Scrum team he has seen was using practices that go beyond Scrum.

To move beyond what Scrum and “Agile” have given us, we need to do some new things, and likely we need to do some old things better. Let’s explore together how to recognize those things, and how to begin to address them.

We’ll be looking in these articles at the things that need to be done inside your projects, and outside your projects. We’ll point out what the manager or executive should ask teams to do, and we’ll talk about why. We’ll also be look at what managers and executives themselves need to do to help projects to become successful. Some of these ideas may not be new to you, and others probably will be. Some of the ideas will be challenging, even a bit difficult. Make no mistake: to attain the higher levels of performance, we all need to work a bit differently.

The fundamental benefit that the Agile methods try to provide is the continuous delivery of “Running Tested Features”. Here’s why:

For most projects, we have a deadline in mind, and we have some understanding of the capability we want to have by that date. There are two key questions we need to address: <p style="padding-left: 30px;">Planning: How can we decide how much time and how many people we need, in order to get the capability we need by the time we need it?</p> <p style="padding-left: 30px;">Managing: Given this overall plan, how can we manage the project to get what we need by the time we need it?</p>

Even with a great plan, we can’t succeed without good project management. We can even produce great results from poor plans. Our teams need to execute every day, and we plan only seldom. So first we’ll look at ongoing management of our projects, and then at how we should plan them. features conventional plan

Conventional software project plans used to look like the picture above. Mysterious and magical things go on in development, and then toward the end of the project, we expect to see features rapidly coming on line, with a successful delivery right at the deadline.

Yes, and on Christmas, Santa will bring you a pony. When we plan this way, the reality usually looks more like this:

features conventional reality

The mysterious and magical stuff happens all right, but when things start coming on line, they start late, and arrive more slowly than expected. The project turns from “ALL OK” to “IN TROUBLE” very late on. As managers, we have little or no time to respond to the trouble, yet our sunk costs are so large that we have no real choice but to go ahead.

Incremental development, as Scrum and Agile taught us, gives us the ability to manage the project. The capabilities of the modern project come on line incrementally, a few every month. We can project the growth of features to see how we’re doing. Even if we don’t go any faster, we’re in a better position to make decisions about what to do. We can look at feature growth and the deadline and decide to what extent we should cut scope, and to what extent we should extend the deadline. The incremental project looks like this in comparison with the conventional:

features incremental vs conventional

Because of the value of this information, the modern software manager asks for an incremental process, with smooth growth of features. We demand that actual progress be faithfully presented to us regularly, like the blue line above. Our first job is to recognize that a faithful blue line is the truth, and that our job is to manage to that truth. We build our organization’s plans around the truth of what is happening.

Secondarily, we do want to help that line to climb more rapidly. We do things to help it climb – and we do things to make sure that the line remains true. As we succeed in improving feature growth, we update our plans. Always, we focus our plans on what’s true, not on what we wish were true.

In the articles that follow, we’ll discuss what it takes to keep that line growing smoothly and steadily. We’ll talk about how to manage them, and about what the people on the projects need to do. Our focus will always be on this blue line of progress, keeping it smooth and steady, so that we can guide our projects to the best possible success.