(by Diego Arimany)
Agile project management is a great methodology. Having a successful agile methodology seems easy enough. With a catchy name, it appeals to millennials as it focuses on managing a project’s scope. Scope management is done by giving team members the decision-making ability regarding the delivery of requirements.
Let’s be honest, every project suffers changes in its scope, and we all hate scope creep. You know – scope creep – that little process that turns a project never-ending, out of the budget, and with different deliverables. That’s because scope creep alters the set of requirements. But what we actually hate delivering an unsuccessful project. Missing requirements, and getting reprimanded for it. What if… What if, we could adjust the scope to match just what we can deliver? Enter Agile+MOSCOW.
Agile+MOSCOW is the combination of Agile project management method and MOSCOW prioritization; thus, allowing an unseasoned team the ability to alter the project’s scope on the grounds of time-boxing and requirement downgrading.
On occasions, when product owner or project sponsor opts for the MOSCOW method of prioritizing, they give team members a clear set of requirements. Many use the method without knowing (shame on you). MOSCOW stands for Must have, Should have, Could have, and Won’t have. This scale is used to prioritize project requirements, which then becomes the deliverable. Interestingly enough this method permits downgrading requirements. Since Agile lets you manage a project scope and MOSCOW allows you to downgrade it requirements both work well together. This combination can be great or terrifying depending on who is on your team. I consider this practice plainly stupid especially if your team is very young (mostly consisting of millennials). We’ve taught millennials to get a just-for-competing prize, and now with Agile+MOSCOW we’ve given a path to label any project a “successful project”. In all fairness, this method does not intend to promote lousy or sloppy project management. That’s just the by-product of great temptation.
The great temptation is committing to accomplish much (looking like a champ and getting everybody pumped), and then safely discarding what the teams hasn’t time to complete. For example, if you look at Star Wars Death Star II under an Agile+MOSCOW methodology the project team can state that the project has been completed successfully while showing that the requirements have changed and that we’re receiving the intended deliverable. It’s pure nonsense.
How have a successful agile methodology
Here are three simple actions to take:
- Proper time allotment,
- Adequate prioritization,
- A basis for downgrading a requirement.
1. Proper time allotment
Proper time allotment means that team members understand their capacity to deliver. That is, they know how long it actually takes to complete a task or a function; and not committing to more than they can handle.
2. Adequate prioritization
Downgrading or trading requirements prove incorrect prioritization. Complement requirements prioritization with additional methods helping to distinguish critical tasks or strategic ones. These are the tasks bringing the project closer to completion.
3. A basis for downgrading a requirement
Giving team members the decision-making ability to alter requirements is dangerous. A seemingly thought out decision can yield unexpected results. First, make sure your team has a track record proving sound judgment taking key decisions. Second, make sure the end result of those key decisions aligns to the organization in order to realize the intended benefits. Lastly, as a project director, clearly establish which requirements the team can change and which ones go through the steering committee.
In conclusion, there’s no shame in missing a deadline or varying the budget as long as it’s within a predetermined range. We’ve all been there. The reality is that rarely a project – a complex project – is completed on time, within budget, and with all requirements met. As for me, whenever a project manager claims to always complete a project successfully, I can’t help but wonder which requirements were left out, and more importantly which was the criteria for their dismissal (keeping my fingers crossed that it wasn’t for fear of looking bad).