Fiction writers I've met have said that the hardest section of a novel to write is not the beginning or ending but everything that happens in between. The middle chapters trace the course of the protagonist's struggle in way that must be both engaging and credible. The story of how people adopt Agile successfully also has a beginning, middle, and end. The middle part here, too, poses some of the most difficult challenges. The first chapter is a grabber, with teams energetically and fervently doing daily stand-ups, blazing through sprints, christening a product owner, prioritizing their backlogs, and living through all the other exciting events that happen at the very beginning.

And then the plot takes a different turn. Success at the small team level is fantastic, but how do you fit into a development organization? What if you need to work with an offshore team? How do you maintain velocity when builds take several hours or maybe even a full day? Is it possible to deal with compliance requirements without a significant amount of automation? How do you work better with the ops team so that the speed of deployment matches the speed of development?

Since Agile went mainstream, the number of teams reaching the difficult middle chapters of Agile adoption has increased markedly. Both I and my colleague Dave West answer questions about the middle phases every day. Many of these questions also arise during the yearly conference that the Agile Alliance holds in the US. (This year, it's in Salt Lake City to mark the tenth anniversary of the signing of the Agile Manifesto in nearby Snowbird.)

Unfortunately, this year's Agile conference isn't emphasizing the middle chapters of Agile adoption. The agenda is full of content pitched at the Agile neophyte, which is good, since there are still a lot of them out there (and a lot of them attending this conference). There are also plenty of outlets for the highly experienced Agilists, the people who have finished the basic story and are now moving on to the sequels. The intermediate levels are represented in the agenda to a much lesser degree.

Many of the intermediate-level concerns are technical. Continuous integration, technical debt, and test automation have a much smaller human dimension than timeboxing or user stories. The agenda for Agile 2011 has covered fewer of the technical issues than the human ones, which is a pretty good indicator that the middle chapters of Agile aren't getting much attention.

The first keynote address set the tone. Barbara Fredrickson, a professor at the University of North Carolina, gave a good overview of recent findings in biology and psychology about the effects of positive emotions. While good vibrations might be a contributor to Agile success, the connection is neither direct nor obvious.

One of the keys of Agile's success was praxis, the close marriage of theory and practice. Nothing was oblique about Agile, even if it did require a mix of values and methods, new attitudes toward work and new ways of doing work. Other methodologies like CMMI told you what you should be doing (often in overwhelming detail). Well-intentioned concepts like “co-creation of value with customers” lack any clear program for action. In contrast, Agile told you that you should embrace change and uncertainty and then instructed you how, through Agile practices, to adapt to change and uncertainty. The more we stray from praxis, the harder we make it on beginning, intermediate, and advanced Agile practitioners.

Fortunately, it's not hard to address this issue in next year's agenda. Many of the developers who are enthusiastic about Agile are equally interested in treating their work as a craft. Making the craft of software development a track in next year's conference, or even a theme of the conference, might steer the conference toward many of the intermediate-level issues that didn't get enough attention this year.

Just to be clear, I'm definitely not saying that the Agile 2011 conference has gone completely in the wrong direction. It's still a great event, one of the best that I regularly attend. Many of the new ideas this year, such as the executive day and the embedded software track, are very worthy additions to a lot of high-value content. The audience just needs a bit less of topics like social media and Agile and more like what kind of tools investments will help teams save their agility from the weight of regulatory requirements.

No story can include every idea that the author finds interesting. Nor can it skip over details essential to the narrative. The story of Agile, as told through the Agile conference agenda, needs the beginning, middle, and end to be strong and compelling.