agile development

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.

{ 0 comments }