Agile teams may become connected to a program delivering a new suite of products. The program may follow a different delivery method than the agile teams, and it is up to the people in both the program and teams to inspect and adapt to a new model—bridging the impedance mismatch brought by incongruent methods.
In this example, consider an agile Scrum team with proven delivery success and a new program following a waterfall methodology. The program governance will require specific steps, approvals, and engagement with specific partners. These program requirements will not lock in step with the typical project start and development cycle of the Scrum team. The reverse is the same—the Scrum team cadence will not match the heavy start and end of a waterfall project.
1. Charter and Funding
A first mismatch occurs during the program’s project charter and funding. The Scrum team will recommend a small funding of the determined team for a small number of sprints in order to gain a better understanding of the project, and produce some working software from which immediate feedback can be gained by the customer. The program and selected architects will recommend a full requirements and architecture phase to determine the complete scope up front, and then request approval and funding for the entire project.
A solution to this mismatch is to sell the Scrum team’s recommendation to the program and architects. Having successful delivery in the past will help the Scrum team with the sell, but if a new Scrum team is assembled, the arguments for assembling the Scrum team can be directly used to the program for a small initial funding of the project.
2. Feature-driven and Component-driven
Another mismatch occurs while planning the first release of the project. The Scrum team will recommend a feature-driven development approach. The program or architects may recommend a component-driven approach. The feature-driven approach uses the whole technology stack and produces value to the customer in the form of a production-ready feature. The component-driven approach shows the architects progress on the architecture up front.
A solution to this mismatch is to ensure the architecture is defined using the correct process for the product, project, and people involved. Typically, a candidate architecture is crafted from the architecturally significant requirements. Any development framework or methodology can determine the architecturally significant requirements. Once those requirements are identified, the mismatch can be solved. In this example, the Scrum team will recommend the user stories are mapped to architectural significances and progress of the architecture can be measured against completion of those user stories. Since Product Owners consider architecture significance in prioritizing, these user stories should be completed early in the project.
3. Release Approval
Another mismatch also occurs while planning the first release of the project. The funding and approval process of the program takes significant time relative to the sprint cadence of the Scrum team. Two or more sprints can go by while the next release is socialized with the program governance. In the first release, the governance will need to review the Scrum team’s velocity in order to gauge completion of later releases. However, if the Scrum team has not been provided sufficient time to stabilize a velocity, the approval for the next release may not occur based on accurate information.
A solution to this mismatch is to allow sufficient time to gain the most accurate information possible. If the first release is only four sprints, the approval for the following release would occur after two sprints—not sufficient time for a stabilized velocity. The Scrum team will recommend a longer first release or a shortened approval cycle. An alternate solution is to complete the full release (all sprints) and hold the team while the approval is gained for a next release.
4. Monitoring and Controlling
Another mismatch occurs in the monitoring and controlling project execution. Program and project managers will naturally want a project plan containing all activities, durations, and start dates—the standard command and control nature agilists are well aware of. The Scrum team will recommend sprint and release burndown charts to track progress. However, the program manager can point to another dependent team—not working with agile—that needs a specific feature or component completed by a specific date.
A solution to this mismatch is to categorize those stories needed to fulfill that dependency. Then, similar to a sprint or release burndown, the Scrum team will burndown that story category, and track its completion to the date. Stories from this category can be planned into sprints as necessary (starting backward from the delivery date).
5. People
Mixed in with these planning and delivery mismatches, the people themselves are mismatched based on mindset, experience, and motivation. Waterfall team members are not comfortable up front with such limited information. Scrum team members need to get started with little up front information so that they can get feedback. Mismatches involving people’s understanding of the process, techniques, values, and principles should be resolved throughout the project by continuous coaching (at the team level and then at the individual level as well).
To fit agile and waterfall together, both sides need to change. Agilists hope each instance will allow more agile remains each time. The complete fix is to make gains toward a lean organization that sends prioritized project work to agile teams focused on their product.
