In my last article I shared some background and differences between agile and waterfall development methodology. I would now like to share a few lessons learned in managing a project that is utilizing both methodologies concurrently. As I come across more, I will add a post.
Scheduling
Agile, by definition doesn’t typically consider functionality being designed or deployed past the current working month. This has to be reconciled. Especially for a project that requires integration. Any system that has dependencies on the design or development of functionality under the agile team’s domain should be built into future sprints on the schedule. On our project, we built sprints as monthly Level of Effort tasks. The status is updated as percent complete and time spent. The details of accomplishments are tracked in a separate tool so they can be shared with the project sponsor. In order to ensure a specific function is built on time, this has to be added as a task on the schedule within the sprint month that it is required. That is technically how it is done in the scheduling tool. However, we learned that is not enough. It needs to be monitored and controlled by the impacted teams along with whoever manages the schedule on the project. This can be easily overlooked by the agile team when recording status on a schedule by just advancing it the same each month. The communication needs to be constant to coordinate the development efforts. Just like any other dependencies, modeling it in the schedule only shows a plan when someone’s actually looking at it. Communication of the dependency tasks needs to be a part of the day to day activities.
Sprint Planning
There also needs to be participation in the monthly sprint planning meetings by the dependent waterfall systems. This ensures the priorities are set by the proper stakeholders and allows a time for negotiation of the upcoming sprint. In our case it was easy for the teams working waterfall development to get consumed by meeting their own major milestones and forget about being more involved in the agile sprint reviews as a stakeholder.
On my next post I would like to share an approach to accommodating major phase milestones by an agile development team.
Waterfall
Large extensive software development projects have typically used the waterfall development methodology. Its uses defined milestone gates to proceed onto the next phase of development. For large projects this is necessary to ensure all elements are in lock step with each other before they are integrated into the larger system. Agile development methodology came along in response to the need for quick deployments and stakeholders that are not completely sure what they want until they see it. I am a Lead Systems Engineer on a very large multi-year project to deploy image processing software for a satellite ground system. The complexity, size, and number of systems and subsystems being developed and needed to integrate together made waterfall methodology a requirement. Many elements need to integrate together on fixed schedules for coordinated testing efforts before product deployment. Although the schedules for each element and subsystems may be on a slightly different time line, they need to converge at each level of the system’s milestone phase. This is particularly important for interface success and coordinating end-to-end testing. As part of this new development, a new Service Oriented Architecture (SOA) framework was going to be needed to support the system messaging between subsystems and security between the various applications. Because SOA was going to be the foundation for the development and required for any integration and testing between elements and subsystems, it was recognized early on that it needed a faster development cycle to deployment. I would like to share some experience and lessons learned in trying to manage a project using agile and waterfall software development.
Life Cycle 101
It is important to realize that in project management we like to use the project phases of Initiation, Planning, Execution, Control, and Conclusion. But engineering follows different project life cycles usually described by the following phases or slight variations on these terms: conceptual, requirement generation, preliminary design, detail design (critical design), development/implementation, test, and deployment. A brief distinction between waterfall development and agile is that waterfall takes the entire system or subsystem requirements through the life cycle in entirety with major milestone reviews used as gates for approval into the next phase. At these milestones, engineers in charge of the interfacing elements, subsystems, or systems have chances to review and negotiate so they can all integrate smoothly. Agile development works on small amounts or groups of functional requirements which can complete a life cycle in one month sprints. Whatever requirements weren’t completed or failed testing are worked on the next month with another group of requirements.
Agile
Each month allows a re-prioritization of requirements to work on. There are typically not major milestone reviews in Agile development, only peer reviews. The intent, as stated earlier, is for quick deployment and would be counter-intuitive to “slow down” for a major review.
Over the course of a few articles, I would like to share some lessons learned in managing the two types of software development life cycles. The first topic that I would like to discuss will be scheduling.
(To be continued)
