When many companies decide to go Agile, they do so out of the realization that the usual approach – gathering most of the requirements and doing most of the analysis at the start of the project – is not working very well. And, too often, it leads to projects that seem to get out of control.

So, it is natural to see the difference in Agile methods mainly in terms of its project management, especially “two week iterations.” Many Agile methods seem to emphasize this project management viewpoint. Get the project management right, and everything else will follow, right?

Not quite. The Agile project management approach is necessary, but it is not sufficient.

This may not seem fair. After all, simply getting to the Agile approach of managing projects through iterations is hard enough. Corporate culture, organizational structures, the attitude of different roles within the organization will all work against this transition.

Aren’t the obvious rewards of an iterative approach enough?

• Customers will see higher returns because they will tend to get quickly those features that are most important them.
• Customers can more easily provide the details they need in the next iteration of the product when they do not have to worry about describing everything.
• Developers will be able to learn from what they are doing and from more immediate feedback from customers who are using the tool. They can make course corrections by seeing the system working.
• The overall complexity of the system will be lower.

These are all good and flow somewhat naturally from an iterative approach. However, our experience shows us that if managing projects through iterations is the primary focus, then developers will likely experience some difficulties during their transition to Agile. They have to come to understand that testing will be required after each iteration. They have to come to understand that the architecture of their system will change on an ongoing basis.

A healthy approach to transitioning to Agile must help developers:

• Know how to write unit tests so they can run them automatically
• Learn how to write maintainable code
• Understand that architecture is not about having a non-changing structure from within which to add functionality but rather a way to relate the different aspects of a system to each other to readily accommodate change.

They must also learn how to work with smaller pieces of feature requirements. Since customer requirements will be ascertained and analyzed as the project moves along, there will be a need for pulling out smaller stories that describe the features than the development team is used to. In other words, developers are used to building product from a complete feature specification; in an Agile process, it is best to build the core of the feature and then add to it. This is a learned skill.

Our experience in helping teams transition to Agile methods shows us that the following skills are needed:

• Project managers must understand the principles and practices of the Agile project management approach.
• Analysts must understand how to unfold use cases.
• Someone on the team must understand the customer requirements enough so that they can represent the voice of the customer correctly to the team (we call this person the Product Owner).
• Developers must understand design patterns to some minimal level so that their designs can allow for changes.
• Developers must understand refactoring
• Developers must understand testing sufficiently so that they can write automated tests.
• Quality Assurance must be able to define for the team what it means for the product to meet customer requirements and describe how to write acceptance tests early that can verify this.

The bottom line is that although the project management aspects of Agile software development are the most visible – and the most difficult to solve, they only provide some of the benefit. To realize the complete benefits of Agile, other technical aspects must be addressed as well. If these other aspects are not addressed, system development may appear to move forward well for several months; but then, the lack of quality tests and quality code will make the code difficult to change and the team will find iterative development grinding the quality of their code down and down.

A transition to Agile methods must include all of these technical skill sets. Not doing so may get the project going more quickly and less expensively, but it does so at a risk of the project’s future peril