Home > Blog > Posts > Introducing Agile Principles to a Waterfall Project
IT Insights Blog Follow SkylineFollow Skyline On TwitterFollow Skyline On Linked InSkyline's RSS FeedEmail Skyline
Topics




Introducing Agile Principles to a Waterfall Project
2/9/2012
Eric Hyland
Senior Software Engineer

I know that introducing Agile principles to a Waterfall project is something that is usually not recommended, but I see some value! I'm presently working on a development project using waterfall methodology. We have the usual Microsoft Project plan, a set of milestones, and loose project management oversight with respect to the five week development cycle.

I'm in charge of the three-person development team, which is working remotely. I've decided to utilize the Scrum burn down and daily standup meetings so I can actively monitor the progress. I am also participating as a developer. I've divided the work into two two-week sprints and one one-week sprint. I've also assigned the most critical and architecturally signification items to the first sprint. This structure allows me to do several things.

First and foremost it allows me monitor our progress daily and gives the team a visual representation of the progress. I have found this to be more effective at identifying progress problems than reporting percent complete in the weekly team meetings.

Secondly, it has allowed me to produce the required "lock down estimate" for the client. This estimate attempts to finalize the cost of the development effort within the client’s methodology. It’s a refinement of the initial estimates and leverages the knowledge gained during the technical specification phase. To make the generation of the estimate more accurate than sitting around the table and discussing the original estimate versus the technical specifications our team performed, sprint planning for the remaining tasks and the total numbers were communicated as the total development effort. I’ve reviewed the burn downs with the client, educated them a bit on the process, and put the usual caveats on the estimate such as no contingency was planned.

Additionally I’ve scheduled the normal Scrum sprint review and retrospective meetings. I’ll be inviting the business members to the review as I feel it’s important to allow them to see the working software early in the process as opposed to the normal waterfall delivery at the end of the development phase.

I understand that in some areas I’m not going truly Agile (i.e. assigning things to sprints up front, sprint planning for future sprints early, etc.) but I feel pretty good about introducing some agile principles to the client and project team and I think this gives our development team the best possibility of delivering on time.

Comments

There are no comments for this post.

Add Comment

Items on this list require content approval. Your submission will not appear in public views until approved by someone with proper rights. More information on content approval.

Title *


Screen Name *


E-Mail


Verify Comment


Body *


Attachments


Agile methodology, Scrum, waterfall, agile principles, project management

I know that introducing Agile principles to a Waterfall project is something that is usually not recommended, but I see some value!