OK the title is a bit “click bait” as this isn’t quite the case, but I’ve just been on a Scrum training course for a couple of days and realised the traditional project manager (PM) isn’t part of the team anymore! Product Owners and Scrum Masters are the new roles for Agile project management. Kind of ironic when legal has just embraced project managers, always behind the curve eh! [edit]: I am not saying the PM isn’t required, more that to work in the scrum framework their role changes, see below for more on why trad PM skills are still needed.

It’s impossible to distill a two day course into one blog post, let alone a whole framework. And after two days I don’t profess to be any kind of expert! But with a background in project management, I thought a post that explains some of key takeaways would be worthwhile.

• First off it’s not a replacement project management methodology, it won’t work for everything and is most suited to “projects” where a product is being developed (the product can be a software development or a “hardware” product).
• The aim is to deliver to the customer a minimum viable product as soon as possible, thus introducing value as soon as possible. Addressing one of the key issues of the traditional waterfall, that of something tangible for the customer not being available until right at the end of the project in the release or implementation phase. This allows for early feedback.
• The key aspects are the small teams; the product owner, the scrum master and the dev team.
• The team has a product backlog that covers everything that might be needed (features, requirements, enhancements etc) is an ordered and estimated list.
• The sprints (typically of a couple of weeks in length) go through a sprint planning to determine the product backlog items to tackle, then create a sprint backlog of the tasks to deliver a potentially releasable product increment.
• After each sprint a review and retrospective allows immediate feedback into the process for the next sprint. Improving planning, product and the development as a whole.

There were some key points that were raised to watch for.

• As we covered the Agile Manifesto. In particular the need to keep teams together as much as possible, as the successful team relationship with all the required skills is key. As is the need to face-to-face conversation, it’s not impossible to run across disparate sites but productivity decreases dramatically.
• The PM isn’t finished, some key aspects of traditional project management isn’t catered for in Scrum. For example, stakeholder management, ROI, governance, marketing, feasibility etc. Scrum caters for the “How we build stuff” phase.
• Also keeping the “noise” from the team is crucial, avoiding constant interruptions. This could prove difficult where teams are traditionally balancing projects and support demands.
• Overall it was clear that moving to a Agile framework isn’t an easy task, it’s not just a case of deciding to do it and renaming all your project managers. There needs to be thought on how things are set up, the office, the people and the institutions.

It’s not a solution to all project failures and without a lot of effort I suspect could cause more. But I can see areas where agile would work really well, much better than traditional waterfall methods and would recommend anyone with a stake in delivering projects to find out more.