We keep forgetting that we're here to develop software.

In the pre-Agile world, methods got so focused on documents and processes that they stopped talking about how to design, develop, and code. They turned to naval-gazing and lost sight of this essential fact: in software development, software is king.

Agile development started out as a reaction to this problem. Nowadays, I fear that the agile community is falling prey to the same mistake.

Too often, when I talk with people who say they're "agile," they talk about their sprints or iteration plans. Less often, they talk about their coach or ScrumMaster and what they're doing to encourage self-organizing teams. Even more rarely, they describe co-locating developers and the efficiencies they're gaining from improved communication.

Even those teams that accomplish all of these things aren't doing enough until they also incorporate agile engineering practices. Traditional approaches to software development don't work in an agile world; the classic software development lifecycle of plan-analyze-design-code-test wasn't made for weekly cycles. The result? Hacking, as developers find that they don't have enough time to do good up-front design, but don't know what to do instead.

This isn't going to lead to great results. The organizational changes may lead to better results than you had before--at least until the technical debt mafia come to break your kneecaps--but it won't give you great results. It won't lead to the joy of producing endlessly malleable software that's a delight to mold and form. It won't allow you to react at a moment's notice to a fantastic opportunity or competitive threat.

It's time we brought back the early emphasis on great engineering practices. If you're using Scrum or another agile method that doesn't include engineering practices, realize that your method is incomplete. Scrum, for example, intentionally creates an environment in which your team is expected to self-organize and define its own practices. If you aren't doing that--if you aren't talking about engineering practices, what's working, what's not, and how to improve--you're going to run into trouble someday. Probably someday soon.

I'm a big fan of Extreme Programming (XP) for exactly this reason. XP can be a little too inwardly-focused, true--it's a flaw Shane and I tried to address in The Art of Agile Development--but it was created by a group of people who are fantastic engineers. Those new engineering practices that are sweeping the world, like test-driven development and continuous integration? They originated in XP. There are even more good ideas from XP to consider, such as collective code ownership, incremental and evolutionary design, ten-minute builds, and yes, even pair programming and open workspaces.

It doesn't really matter where you get your agile engineering practices from, though. (XP does provide a nice, clearly-defined bundle that's a good starting point, plug, plug.). Whatever you do, don't forget that agile development requires agile engineering. It's not enough to stand around and talk about your iteration plans. You have to code.

And if you're going to code, why not create amazing code, code that's endlessly malleable, a joy to adapt and modify?

PS: Thanks to Brian Marick for reminding me of the importance of Joy and Ease in agile software development.