Agile is Not a Silver Bullet

Agile and lean approaches, with either short timeboxes or explicit limiting work in progress and a focus on transparency works for many organizations. In the past few weeks, I've received a number of inquiries from all sizes of organizations asking the same kind of question, “How can we go all agile?”

Experiment with an Agile Approach

My suggestion is this: Take an agile approach to going agile. That is, take a small project, something you think will take about six months, and try to do it in an agile way. Train everyone on that project. If you want to do Scrum, fine. (BTW, Scrum != Agile. Scrum is one organizing approach to agile.) Choose a Scrum Master, who is not anything else. Choose a Product Owner who is not anything else. Chose a relatively short iteration duration, such as two weeks, and start working in two-week timeboxes. Do not extend the timeboxes. Use your retrospectives at the end of the timeboxes to improve what you do in the project. See what happens.

If you want to use kanban instead, you might learn even more in less time. You will still need a Product Owner, someone who owns the backlog and can create stories that are sufficiently small for the team to work on. The nice thing about kanban, is that you get feedback even faster. If the stories are too large, nothing moves on the board. If you make your work-in-progress limits too large, nothing moves on the board. If you have a bottleneck, nothing moves on the board. Anyone can see lack of board movement and say, “Hey, nothing is moving on the board. Do we need to do something about that?”

There are two things you cannot count on: that you will find exactly the right agile approach for you the first time you try agile, and that agile is a silver bullet.

Focus on Learning

That is why at the end of the first project, use what you have learned from that one project and consider what it would take for the entire organization to move to agile. You might need one more project (or two or three). You might realize that the cultural changes required for agile mean that the managers need to leave before you transition to agile. Or that the architects need to leave. Or that you finish one more large program before you transition, because the business value of that program is too high to endanger it before you transition. Or, because you are so geographically distributed, the costs of transitioning to a straight agile approach will make everyone so crazy, they will tar and feather you. But a staged delivery lifecycle might work.

Choose Your Lifecycle

Agile is not the only approach. Yes, integrating testing with development makes a ton of sense, and you get that with incremental lifecycles. Yes, iterations make a ton of sense, and you get that iterative lifecycles. You can even combine iterations with increments, and still not have an agile lifecycle. Release trains, for example, are an iterative and incremental lifecycle that are not agile, because they do not have a product owner, and do not incorporate fast feedback. But, they are better than waterfall. They are even better—for some people—than straight staged delivery.

The lifecycle you select depends on your context. I have yet to see an organization that did not benefit from having a cross-functional team work on a small set of requirements together, finishing one thing to done before starting on another. However, working in an incremental way does not always have to be agile. I am a big proponent of agile approaches. And, I would like to see you succeed. Maybe you can read What Lifecycle? or the lifecycle chapter and appendix in Manage It! first. (Added in 2024: See Project Lifecycles for much more information on lifecycles and culture.)

I rarely recommend anyone take a waterfall approach to transitioning to agile. I like to try a little something and get a little feedback first. When I help clients transition to agile, we often discover they need something that's a little of this, a little of that.

Agile is not a silver bullet. You have many options. Please use them.