Agile Ain't Easy

Agile's a big deal these days. Everyone is talking about it, it's getting a lot of press, and by the sounds of it, you'd be leaving your company's neck out for the competition to come snack on if you do anything but put your company on the Agile track it Right Now.

Why does it seem then that so few organizations are actually going ahead and installing one of the multitude of Agile Systems? Why are many of the people who are using these practices complaining that their organizations feel anything but agile?

It really comes down to the fact that the literature talks about Agile as if it's easy to install and execute. The problem is, sadly, that it ain't. It is in fact really quite hard to implement completely.

So what's up, then? Why are there so many people out there generally tossing words around as if it's dead simple to just turn Agile on in your own organization? The fact is that the individual practices are pretty simple to do, so they make for good articles and lectures. The infrastructure to support the various practices, whatever your flavor of agile, shouldn't take more than a couple of days to put into place. What tends to be the hard part, though, should in many ways be the easiest because it doesn't require any purchases or any sign-off procedure or any of the other corporate trappings that often interfere with getting things done. This part, which is perhaps the most important step in adopting Agile in any form, is the change in mentality, mindset, and focus of the management team that is required to participate in anything that truly is to be considered Agile.

So, what is this change in mentality, and what's hard about it? In short, the change inverts much of the management structure that exists in the "traditional" development methods. Part of the difficulty is that the manager's role is now almost exactly reversed from what it was before in practice, but even more insidious are the parts which require a substantial shift in the underlying principles that the manager needs to hold dear. No longer is the manager really "the boss." The manager certainly stays on the hook for the development goals, but this person's role changes from one of authority to one of service to the team. This is a tough change for many managers to make.

Indeed, it has been said that this is one of the hardest parts of switching to Agile, and is one that many simply fail to make at all. The other difficulties are similar, in that truly being agile requires comprehensive changes in the management structures that surround the developers, to enable those developers to be truly productive.

One picture of how this can come together is to examine the feedback mechanism by which the "scheduling" of agile projects occurs. In Scrum, for example, there's a backlog of tasks to be done "at some point in the future," and every iteration cycle the team takes some number of tasks from that backlog and sets their "iteration goals" in such a way as to make visible forward progress with the product while committing to deliver an amount of functionality that they believe they can deliver. Compared to a more typical development cycle where the management defines the work to be done over the current cycle, the obvious change hereis that the people doing the work are selecting and committing to only those tasks which they think they can deliver by the end of the iteration cycle. The more insidious effects, however, are that the management team may still cling to a hope that the team could (or even worse, that they should) deliver more functionality. The management, then, need to embrace the idea that the team knows best how things get done, and how long it takes to do these things. Otherwise you're left with friction between what the team is intent on doing and what the management wishes the team would do, and friction is really what Agile strives to eliminate in the first place.

So is long-term scheduling out the window? Not at all; long-term scheduling actually becomes more viable in this model. Since the parties are no longer in an adversarial relationship, they are able to discuss product goals and reach a mutual understanding of what needs to get done and what it'll take to get it done. Agile practices make it easier to see how much is getting done as the project progresses and future development can take this historical information into account while planning. Again, though, management needs to embrace the idea that they are not in control of the project's destiny. The fact is that in a traditional development environment the management is no more in control, but the power structure is comfortable for some and the power game is well-played by many. For agility to take root and truly be effective, the management needs to recognize and accept that they were never in control to begin with, and embrace the idea that the team is the best source of information upon which to base the future plan.

Additionally, as much as the game industry is a hit-driven one, it is also an opportunistic one (and I would guess that much of the software industry is similar). Slipping by even six months can mean that the competition can barrel on by and all of those cool features that were in the plan mean nothing because "now everyone's got them." Shorter development cycles also require the team to focus on what really matters, the core areas and features that will sell the product. Longer and longer development cycles are often the result of "kitchen sink design," where a team tries to add every feature they can think of into the game. Why not monetize often and early, and defer secondary features until the next revision of the product? Since the industry is so hit-driven, shouldn't it be obvious that more releases yield more opportunities for a hit? Agile practices specifically enable this frequent release model, yet many game studios have trouble adopting the underlying mentality to enable themselves to produce games quickly enough for it to matter.

This is only a glimpse into the sorts of challenges that development teams can run into when transitioning themselves to Agile. Sadly, few of the Agile sales force talk about these pitfalls, which in my opinion are much deeper and harder to solve in the long-term adoption of Agile in any given organization. Implementing the things that we all hear about really is easy, but the ease with which agile planning or agile development is implemented belies the complexity of the thought-change that needs to occur to be successful over the long haul with Agile. In these pages I will tend to talk about this side of Agile, as it is in my opinion, very much the important side. Indeed, a change to agile-minded management without implementing the easily-observable aspects of agile can lead to a very effective team. On the flip side, doing pair-programming and unit testing does not automatically make a team agile.