This blog is based on the interview with The Agile Business Consortium’s Andrew Craddock and APMG’s Richard Pharro.
AgilePM for Scrum is a brand new business agility solution designed for people using Scrum who also have a need for project-based working, and for project managers who need to embrace Scrum for team-based working.
The frameworks of AgilePM® and Scrum began back in the 1990s. The original version of Scrum can be traced back even further. Both frameworks have been proven to work extremely well, so what benefit can be gained from combining the two and how is that possible?
The Agile Business Consortium has always championed both frameworks. Scrum is focused on product development and product value rather than overall business value, whereas AgilePM®on the other hand, although containing its own inbuilt version of Scrum, focuses on the wider picture – the overall solution you get from a project approach.
For example, software is likely to be a component of a business change initiative but it’s just that – one component. It’s all very well building a system that people can use within a business but you also need to be able to see how that system will be implemented and deployed within the business. How will people be trained to use the software or other product for instance?
Scrum is of course a global phenomenon for teams who are building products and services, and no-one is trying to detract from that.
However, Product Architecture Lead Andrew Craddock explains: “There are project management aspects it doesn’t cover that presented a fantastic opportunity for us to help advance business agility worldwide.”
Andrew is keen to stress that this advancement of business agility is indeed the aim of AgilePM for Scrum.
He said: “Our aim is to make it easier to adopt good agile practice. AgilePM for Scrum explains precisely how these two proven frameworks can work in harmony.”
“There is a recognition that agility as a concept goes beyond a framework.
“We have left Scrum as pure, as true to the Scrum Guide, as we can and have simply layered on the value around the outside that AgilePM® brings.”
He explains further: “People were saying they liked projects but that Scrum doesn’t do projects so how could they bring the two together?
“And people using AgilePM® were saying they had all these people that understood Scrum but that DSDM – the founding principles and practice behind AgilePM® — was a whole lot of different terms and language.
“So we thought – let’s just bring them together – let’s embrace Scrum for what it is and let’s add the value that AgilePM® brings to that party around the edge.”
The one small change that has been made with AgilePM for Scrum is using the term ‘product increment’ instead of ‘increment’, as in the Scrum Guide. This is to distinguish between a product increment, delivered by a Scrum team and a project increment, managed by the organisation that the Scrum teams exist within.
So what exactly has been added on to work alongside Scrum?
The Scrum Guide says that the product owner is the one individual that provides the direction the Scrum team needs to build its product and that it is up to the product owner to manage the interest of stakeholders.
With AgilePM for Scrum, Andrew has defined three distinct roles to simplify the primary stakeholders the product owner needs to deal with:
- A business visionary, who is the visionary for the overall business change and business value
- A solution architect who is responsible for the overall solution – not just software, but the hardware the software runs on and not just IT, but the business change associated with it that needs to be rolled out
- A project manager who is responsible for making sure projects are delivered, as a whole, within constraints such as time and budget.
In AgilePM for Scrum, the product owner is still exclusively responsible for shaping the product backlog. They now simply need to consider as well the needs of the business visionary, the project manager and the solution architect in doing that.
Andrew explains: “So if the project manager says a specific feature of certain software needs to be delivered in a particular sprint by team A, because team B needs that, in order to do something they need to do in the next sprint, that’s just one of the considerations in the ordering and refinement of the product backlog.
“Once we’d made that connection it was actually really easy to build one thing on top of another.”
Of course, just as the application of Scrum has moved a long way beyond software, AgilePM for Scrum is as suitable for physical products as it is for software products.
AgilePM for Scrum was created specifically to bridge the knowledge gap for people using Scrum who also have a need for project-based working, and for project managers who need to embrace Scrum for team-based working. Andrew adds: “What I’d like to see AgilePM for Scrum do is to start to realise the value that a project framework can bring to an agile environment.
“If there’s only the development of the product, then Scrum is great, but it’s the other things that need co-ordinating around the edge.
“If people recognise that those other things can be done in a way that’s just as agile as the product development in Scrum, that’s the key.
“I think that for those people who are using Scrum but need that level of project management, moving to adopting AgilePM for Scrum brings those things together, and that for me is what success looks like.”
You can watch the video of Introducing AgilePM for Scrum here
Please note blogs reflect the opinions of their authors and do not necessarily reflect the recommendations or guidance of the Agile Business Consortium.