Here are two related questions I received from a site member about Agile, my answer, and Kent's and sanity check on my answer. These are great questions not just for a PM, but for an executive understanding of how it works and what they do and don't get to do in terms of driving scope and date changes when the team is trying to run by Agile principles and practices!
"How do you protect the scope of an Agile project, since Agile projects leave space for users to change their requirements ?"
Cinda: Agile projects leave space for users to change their requirements, BUT – not within short plan-develop-release iterations. A key concept of Scrum, a specific approach to how project teams schedule and manage their work in an Agile manner, says that you prioritize features into iterations of two to four weeks…. And once the iteration has started, the scope cannot be changed (added to or the list changed) until the iteration is finished. Once it is, customers and team looks at results, any new information, changes in priorities etc. and decide what the next iteration is about. So you protect the scope in an iteration to ensure the iteration can finish quickly (although lowest priority stuff in that iteration may not get done if the team runs out of time. In which case it is considered for the next iteration.)
Other than that, you do NOT protect the scope in the large (protect whatever got envisioned as the scope of the entire project way up front), because that’s the point of doing Agile – acknowledging that you can’t know everything up front, things may change during the project, you will definitely learn more about true customer requirements as you go. You want to pair delivering high priority value to the customer at regular and frequent intervals, while allowing scope to adjust between interations based on learning more about what the customer really wanted etc etc. as you go along.
Kent's additions: Yes to Cinda's answer plus a couple of nuances. Teams using XP [extreme programming, another specific technique in the Agile family] may allow features to be added to an iteration, but the customer must pull a feature of equal or greater size out of the iteration in exchange. Basically, you are keeping the overall amount of stuff that a team works on during an iteration the same. I prefer the Scrum approach better because it allows for more focus (what if the team started working on the feature that was yanked as a result of adding a new one) and really, can't the business wait 2 - 4 weeks for a change given the much longer waits they are used to today?
Also, it's important to be clear about the level of requirements we are talking about. The requirements assigned to an iteration or "sprint" in Agile are at the "things the system should do" level, allowing the more detailed requirements of things like UI design to be defined in the iteration, so it may still look like requirements are changing, but they aren't. They are just being better understood and defined as you quickly create things with tight customer feedback. In most projects I have experienced, what people claimed was requirement change was really just refinements of implementation brought on by better understanding of the desired solution.
You protect the overall scope of the project by defining scope as what problem the system will solve as opposed to a particular list of features. That is why it is so important to understand the purpose of the project. It may turn out that far less functionality is required to appropriately satisfy the purpose of the project. You also protect overall scope by ruthlessly prioritizing features. Make sure that all the really important stuff is done first (with importance measured by how much it helps accomplish the purpose). This leads into the second question.
"How to do you protect the delivery date of an Agile project?"
Cinda: The idea in Agile is to deliver working product to the customer more frequently than our past typical monolithic projects. At the end of each relatively short iteration, the aspect created during that iteration works and can be delivered to customers. The end date of an iteration NEVER EVER is changed. Having regular iterations that deliver working product off a prioritized list - instilling that discipline - is core to the beneficial "regular, frequent business value delivery" Agile is intended to bring. You show the customer what is ready and it can be delivered to them if they want it.
Kent: And when you reach the overall delivery date of the agile project, you deliver. You have been giving your customer regular updates on your progress, and now give them the appropriate information to decide whether to extend the final delivery date, but that should be the exception, not the norm. That is why prioritization is so important. Agile methods typically timebox features/functionality into iterations and hence treat time as fixed, allowing scope and budget to flex.