Less Yields More?

One of the promises that agile makes is that its adoption leads to less crunch. The implication that is readily available here is that the developers spend less time at their places of employ, more time with their families, and through the magic of agile, the same, if not more, work gets done. How is this possible? Doesn't this assertion violate some fundamental law of conservation? How can it be that any change in process can lead to more productivity?

In Code Complete (in section 28.5), Steve McConnell cites a number of studies that suggest there is over a factor of ten difference in the productivity between programmers. Further studies have indicated that there are also significant, though less pronounced, differences in productivity between otherwise-comparable teams working on identical projects. Is this relevant to the discussion on Agile in any way? In my opinion, most definitely. I would posit that the differences in productivity are related to work habits as much as, or quite likely more than, anything else. Many times I have heard people say, "Agile isn't telling us anything new," and "Agile is merely repackaging things we should be doing anyway." Maybe some of these things, which we all know we should be doing anyway, are some of the things that productive individuals and teams actually do in their own work.

I do fully embrace the idea that the Agile practices can lead to increased productivity. Many of the practices can be applied by the interested individuals, "under the radar" if you will, and those developers will find their own productivity improve. At the end of the day, though, the most effective way to increase one's own productivity is to in have the desire in the first place to become a better programmer. It is those people who want to become better programmers that are the ones seeking out the means by which they can become better; those reading the various forums and learning about any number of techniques to make themselves better at what they do are clearly more likely to make changes in their own work habits to make themselves more effective.

Agile can present enabling technologies to a team desiring to become more efficient. After all, most of the practices are things we've been told we should be doing since we started programming. By themselves, though, they are no magic bullet. Truly increasing performance requires that those involved actually desire to so improve. Doing so otherwise is like washing a cat, it yields only pain and suffering to the washer, while thoroughly aggravating the cat. Avoid the scratches and make sure that the others involved want to take part.

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.

My History

My experience with so-called agile practices started many years ago. Hungry for information and learning, I spent a lot of time reading comp.lang.c++. All of the sudden this new guy (who many know as simply Phlip) appears and starts answering posts with, "oh check out your answer here" and gives a link to Ward's Wiki. So began my introduction to Extreme Programming, and I pushed an early version of CppUnit into my workflow soon thereafter.

From there I took a stab at starting my own game company, during which time one of the other partners stumbled across Scrum and we all agreed to implement it. In many ways, things went spectacularly. Not so spectacular was the fact that money ran out without securing more, and thus it came to a close.

This experience, however, landed me a job at Southern California game developer, where discussion in the interview turned to Agile quickly, and the team appeared really interested to learn more about the whole affair but hadn't done much along those lines to date. This second project ended up bearing significant risk from day one, so I introduced Scrum to help deal with this risk. I also installed a unit testing framework that we could all use as we wished, from my perspective I wanted it mostly to "protect" functionality that I was depending on. Sadly, and despite hitting our agreed-on milestones several months in a row, the studio's primary project was floundering and the financiers really wanted to see more progress. Thus, the second project was shut down, the staff relocated to the primary project, and a Scrum-style system implemented and embraced for the entire team of 70 developers. This studio is now known as somewhat of a poster-child for Agile in games, and I'm glad for having been a part of that.

After that experience, I've been around the block quite a bit. A little Scrum implementation here, a little unit testing there, and some pair programming introductions at this other place. The pair programming was one of the most interesting experiments, because the programmers fought it tooth and nail despite the fact that they ended up getting far more functionality done in any given time period than they had when they were flying solo. At this time, I'm at Yet Another SoCal Developer and basically the guy behind what'll be The New Agile in the company and with any luck, in the industry at-large.