In the first article for this series on Agile in Enterprises with Traditional Waterfall, I gave examples of when and where Agile is appropriate. In this and the remaining lessons I will consider the key differences between Agile and Waterfall as seen from a traditional (waterfall) point of view. This second article focuses on the necessary understanding required to successfully manage the requirements for Agile projects. It is very important to educate stakeholders on what will be different when using Agile and the benefits of using the Agile approach for a particular project.
2. Educating Stakeholders
Whilst the overall aim of the project needs to be clearly understood up front, all the business requirements will not be gathered up front. The Agile approach allows the stakeholders to evolve the requirements based on collective feedback and the value of each requirement to the business.
2. Educating Stakeholders
Whilst the overall aim of the project needs to be clearly understood up front, all the business requirements will not be gathered up front. The Agile approach allows the stakeholders to evolve the requirements based on collective feedback and the value of each requirement to the business.
Understanding the intended outcome is essential - regardless of project approach.
First, key user stories will be gathered in summary format that can be shuffled like a deck of index cards. Next, when user stories are selected for the first development sprint, it is important to educate stakeholders that prioritisation is based on value to the business. They also need to understand that any outstanding user stories will be placed in a backlog for subsequent development cycles until the business decides there is insufficient value in continuing with more sprints. This means that stakeholders have to be able to justify requirements in terms of value to the business (valued added or lost).
Then, after each sprint, the stakeholders will see a working version of what has been developed based on their user story input (typically within weeks), and they will have an opportunity to make minor adjustments (e.g. look & feel). Major changes will have to go through the same change process as used for traditional project approaches. New requirements identified during earlier sprints can be added to the backlog for consideration in future sprints.
The user story format ensures each requirement has a context and it can be understood who will use each software feature, for what purpose, and who will benefit. As the user story format also describes the expected outcomes of each feature, this effectively provides a basis for testing and user acceptance. When transposing acceptance criteria to test cases, additional test cases may be required to ensure full test coverage, e.g. negative test cases and non-functional testing.
In terms of project management, the Agile approach requires intense and frequent engagement with a large number of stakeholders. This can be challenging in terms of availability of key personnel and needs to be considered when grouping user stories to be included in the same sprint. Although face-to-face engagement is used a lot in Agile projects, our experience has shown that web conferencing can be a very effective alternative to review meetings.
Another point to emphasize is that the software that is 'released' after each sprint does not necessarily go into operation immediately. For larger and more complex developments, each sprint provides another component or layer to build up until the overall solution reaches a point where it is deemed sufficient to become operational.
These are some of the main differences to be aware of when managing requirements for Agile projects in a traditional enterprise environment. The traditional approach can benefit from some of the Agile techniques, particularly user stories and prioritization based on business values. At the same time, Agile requires traditional techniques to manage changes and provide project governance.
In the next article, we will address planning and design.
Then, after each sprint, the stakeholders will see a working version of what has been developed based on their user story input (typically within weeks), and they will have an opportunity to make minor adjustments (e.g. look & feel). Major changes will have to go through the same change process as used for traditional project approaches. New requirements identified during earlier sprints can be added to the backlog for consideration in future sprints.
The user story format ensures each requirement has a context and it can be understood who will use each software feature, for what purpose, and who will benefit. As the user story format also describes the expected outcomes of each feature, this effectively provides a basis for testing and user acceptance. When transposing acceptance criteria to test cases, additional test cases may be required to ensure full test coverage, e.g. negative test cases and non-functional testing.
In terms of project management, the Agile approach requires intense and frequent engagement with a large number of stakeholders. This can be challenging in terms of availability of key personnel and needs to be considered when grouping user stories to be included in the same sprint. Although face-to-face engagement is used a lot in Agile projects, our experience has shown that web conferencing can be a very effective alternative to review meetings.
Another point to emphasize is that the software that is 'released' after each sprint does not necessarily go into operation immediately. For larger and more complex developments, each sprint provides another component or layer to build up until the overall solution reaches a point where it is deemed sufficient to become operational.
These are some of the main differences to be aware of when managing requirements for Agile projects in a traditional enterprise environment. The traditional approach can benefit from some of the Agile techniques, particularly user stories and prioritization based on business values. At the same time, Agile requires traditional techniques to manage changes and provide project governance.
In the next article, we will address planning and design.
RSS Feed
