Another decision indicator is your organization's process maturity. If your enterprise is process-driven and you're thinking of adopting an agile software development approach, you may want to consider how it will be implemented at the ground level. For instance, departing from process and moving project managers from waterfall to agile may seem as if you are asking them to abandon process and "relinquish control" and this isn't an easy proposition for some process-driven PMs to stomach. It takes considerable change management and coaching before people can really see the benefits of an adoption or transformation.
A third consideration lies in what may happen post-adoption or post-transformation. While the foundation of agile is quite powerful, it makes sense to understand the common pitfalls companies experience in a transition. Consider the following:
* Fixing both the hours and scope This restricts the teams' ability to be agile and gives the business what they asked for, not what they need. In waterfall, project managers are comfortable using change requests to adjust their hours and scope of work. Agile somewhat departs from this change approach, as teams are encouraged to respond to change by constantly adding to their backlogs (read: requirement sets), rather than adding to scope and schedule. While the requirements may change in agile the schedule always remains the same.
* Scheduling all of the sprints/tasks in advance The desire to plan every requirement, task and story, in every sprint, up front, is a natural tendency of first-time agile project managers. Resist the temptation! Trying to schedule all tasks in advance prevents the teams from truly self-actualizing, impedes their ability to find their true velocity and sets unrealistic expectations for delivery.
* Dictating the velocity of development across all teams -- Each agile team will have its own velocity, its own challenges and its own speed. Teams get faster as they go, so managers should not try to compare velocities between teams and work efforts. Let the teams learn and adopt at their own pace (with the correct amount of coaching, of course).
* Feeling like an acceptance of agile is a loss of control If agile is implemented correctly and scaled appropriately, leaders at the project, program, and portfolio levels will have a better understanding of the work in progress on a daily basis, know exactly what is left to complete, and know the same day if something is slipping.
* Excluding your QA testers on the sprint planning/execution processes Having QA as part of the team planning sets the direction for the test plan and defines what "done" means. This requires organizations to engage their testers much earlier in the process, which is a departure from a waterfall approach where testers come in toward the end. While involving testers is a great idea, in theory, it can be rather difficult to implement in practice, as test/QA resources in waterfall projects are typically budgeted for (and allocated) toward the end of the project. Make sure your teams and your test leads understand the implications of a move to agile before you engage in complex resource capacity discussions!