This third article considers project planning and design in projects or programmes using both Agile and Waterfall methods. The project planning stage is an opportunity to identify and examine the interactions between the two methods. We will explore a few examples of such interactions below.
3. Planning and design with Agile and Waterfall
In the first article, we discussed the importance of applying Agile to appropriate projects or project deliverables. In projects combining Agile and Waterfall methods, the article assumes integration between Agile and Waterfall developed software components. It is also assumed that the overall project (or programme) is primarily under Waterfall management and that it has one or more sub-projects managed as Agile projects.
Starting with design, the Solutions Architect is likely to have a longer engagement when a project is using both Waterfall and Agile methods. This is due to the architect continuing the design effort until all the necessary Agile designs are completed.
Until these Agile designs are completed, designers working on Waterfall managed components will be reluctant to commit to work until their parts in the architecture are signed off. Any changes made to the architecture can cause re-work of components managed under Waterfall as Waterfall assumes a stable architecture.
One way to manage the above situation is to schedule the Agile work (that requires integration) early in the project life cycle to underpin the deliverables being managed under Waterfall. If this isn't possible, the Waterfall designs may have to define architecture requirements for the Agile designs to comply with. The latter can be made easier by the Solutions Architect anticipating late arriving Agile designs.
On the plus side, the user stories from the Agile approach should make it easier for the Solutions Architect and System Designers to correctly interpret the business requirements as the stories give a richer context and understanding of business processes than can be understood from functional requirement statements.
There is a risk that the interfaces between Agile and Waterfall developed components will not integrate until the end of the Agile development because of the evolving changes to interfaces. Even minor interface changes can ripple through the architecture design. This can be overcome by defining the interfaces up-front where possible, and by designing flexibility into the common interfaces in anticipation of changes later in the development cycle.
For integration testing, the planning challenge is to ensure all the components and interfaces are deployed in the test environment. If any incomplete components are put through integration testing through stubbing and hand crafted test data, this could compromise the project. Another consideration for combined methods is the need for parallel or multiple test environments to accommodate overlapping setups and test cycles. This will increase the project complexity and resources to manage test environments and code versions.
Release planning also requires consideration as it may not be possible to release Agile sprints until the final sprint has been through integration testing with the Waterfall components. The project manager also needs to ensure robust version control, code merge and test data. For User Acceptance Testing (UAT), the components developed through Agile should be quicker to test as users will be familiar with the software from their involvement in design and development. Be aware that the overall UAT timescale may be determined by testing of the Waterfall components rather than the short Agile UAT.
Throughout the project, it is essential to identify and manage assumptions as Agile and Waterfall approaches will surface different (and sometimes opposite) assumptions. Each Agile iteration may generate additional assumptions so it is important to re-visit all assumptions regularly with the whole project. Similarly, dependencies between Agile and Waterfall components should be clearly shown in the project network and regularly reviewed.
The project manager will face some challenges when asked to forecast the delivery milestones driven by Agile activities. Here, it needs to be decided if timescale takes precedence over cost and scope (I presume quality is not to be compromised). If timescale is the most important factor, then the project may have to time-box the Agile development. Be aware of the temptation to keep the full scope by increasing the sprint size and/or reducing the number of sprints. This is likely to impact the quality and store up problems for later in the project. A reduction in scope for the Agile part of the project could impact the components managed in Waterfall; such scope changes should be done as early as possible to give priority to timescale.
I hope the above examples highlight the necessity for careful planning when combining Agile and Waterfall methods in the same project to get the best from each method. I have found Critical Chain Project Management to be particularly useful when managing projects with many dynamic components and interactions such as those discussed above (see Intelligo PM). In the next article we will look at stakeholder communication in combined Agile and Waterfall projects.
3. Planning and design with Agile and Waterfall
In the first article, we discussed the importance of applying Agile to appropriate projects or project deliverables. In projects combining Agile and Waterfall methods, the article assumes integration between Agile and Waterfall developed software components. It is also assumed that the overall project (or programme) is primarily under Waterfall management and that it has one or more sub-projects managed as Agile projects.
Starting with design, the Solutions Architect is likely to have a longer engagement when a project is using both Waterfall and Agile methods. This is due to the architect continuing the design effort until all the necessary Agile designs are completed.
Until these Agile designs are completed, designers working on Waterfall managed components will be reluctant to commit to work until their parts in the architecture are signed off. Any changes made to the architecture can cause re-work of components managed under Waterfall as Waterfall assumes a stable architecture.
One way to manage the above situation is to schedule the Agile work (that requires integration) early in the project life cycle to underpin the deliverables being managed under Waterfall. If this isn't possible, the Waterfall designs may have to define architecture requirements for the Agile designs to comply with. The latter can be made easier by the Solutions Architect anticipating late arriving Agile designs.
On the plus side, the user stories from the Agile approach should make it easier for the Solutions Architect and System Designers to correctly interpret the business requirements as the stories give a richer context and understanding of business processes than can be understood from functional requirement statements.
There is a risk that the interfaces between Agile and Waterfall developed components will not integrate until the end of the Agile development because of the evolving changes to interfaces. Even minor interface changes can ripple through the architecture design. This can be overcome by defining the interfaces up-front where possible, and by designing flexibility into the common interfaces in anticipation of changes later in the development cycle.
For integration testing, the planning challenge is to ensure all the components and interfaces are deployed in the test environment. If any incomplete components are put through integration testing through stubbing and hand crafted test data, this could compromise the project. Another consideration for combined methods is the need for parallel or multiple test environments to accommodate overlapping setups and test cycles. This will increase the project complexity and resources to manage test environments and code versions.
Release planning also requires consideration as it may not be possible to release Agile sprints until the final sprint has been through integration testing with the Waterfall components. The project manager also needs to ensure robust version control, code merge and test data. For User Acceptance Testing (UAT), the components developed through Agile should be quicker to test as users will be familiar with the software from their involvement in design and development. Be aware that the overall UAT timescale may be determined by testing of the Waterfall components rather than the short Agile UAT.
Throughout the project, it is essential to identify and manage assumptions as Agile and Waterfall approaches will surface different (and sometimes opposite) assumptions. Each Agile iteration may generate additional assumptions so it is important to re-visit all assumptions regularly with the whole project. Similarly, dependencies between Agile and Waterfall components should be clearly shown in the project network and regularly reviewed.
The project manager will face some challenges when asked to forecast the delivery milestones driven by Agile activities. Here, it needs to be decided if timescale takes precedence over cost and scope (I presume quality is not to be compromised). If timescale is the most important factor, then the project may have to time-box the Agile development. Be aware of the temptation to keep the full scope by increasing the sprint size and/or reducing the number of sprints. This is likely to impact the quality and store up problems for later in the project. A reduction in scope for the Agile part of the project could impact the components managed in Waterfall; such scope changes should be done as early as possible to give priority to timescale.
I hope the above examples highlight the necessity for careful planning when combining Agile and Waterfall methods in the same project to get the best from each method. I have found Critical Chain Project Management to be particularly useful when managing projects with many dynamic components and interactions such as those discussed above (see Intelligo PM). In the next article we will look at stakeholder communication in combined Agile and Waterfall projects.
RSS Feed
