Adopting Scrum into Waterfall Projects
Scrum or Waterfall? What methodology should you be using on your projects? There is no one-size-fits-all methodology when it comes to managing projects. There is however, the opportunity to take the best aspects from each methodology and apply them to your projects.
I’ve found that the biggest factor in selecting how you’re going to manage a project is the project environment and stakeholders. How familiar is your team with Agile and Scrum concepts? How disciplined are you as a project manager to follow two-week iterations? How disciplined is the product owner to attend sprint planning and determine feature priority? Do you have a product owner? If you don’t feel confident that a Scrum methodology will fit your project, don’t force it.
However, there are parts of Scrum that lend themselves very well to managing projects, regardless of the over-arching methodology. I’m going to discuss them here.
Daily Standup Meetings
I don’t know how these are not part of the PMBOK personally. These daily meetings are an invaluable way of catching up with the rest of your team, finding out what they’re working on and what’s in their way. By time-boxing them to no longer than 15 minutes and removing the chairs from the room (or at the very least, forcing your team to stand), you can all but ensure that they will move as quickly as possible. I like to run my standups by having the ground rules visible on a whiteboard for all to see.
3 Topics for each person – what did you work on yesterday; what are you working on today; what roadblocks do you have
No problem solving or solutioning – call another meeting with the right team members to do this outside of the standup
Be brief but informative – we don’t need technical details but we should know at a high level what you are working on
Consistent Product Demonstrations
While in pure Agile/Scrum projects there are rigid schedules around product demonstrations to the product owner and other stakeholders. While your project may not suit a regular two-week intervals for product demonstrations, getting something in front of your key stakeholders early on and as often as feasible is a great way to detect changes early on in a project (when they’re cheaper to put in). It also renews the confidence that your stakeholders will have in you and your team. Often development teams are viewed as this black box where requirements are fed into it and then it’s radio silence for 6 months while the build takes place, after which a product is shown for the first time. This is almost guaranteeing you to see change requests that your budget and schedule cannot absorb. By getting stakeholders seeing in-progress work early on it will save you many headaches down the road.
Agile and Scrum is not for every project but by adopting techniques from that methodology that fit across all projects, you can give yourself and your project team a leg up in steering clear of common project pitfalls.
Want to know more? Let's talk!
