Agile: It’s not what I thought it was
Agile Journey
On my journey to becoming the first PRINCE2 Agile Certified Trainer in North America, I was pleasantly surprised at what agile was and what it wasn’t.
Prior to beginning my learning regime, my position was that AGILE was just another flavour of the day, designed by IT folks and being “sold” as the saviour of the disastrous beast called “The IT Project”. I knew it was all about embracing change, yet I had heard mixed stories of success because the decision makers didn’t really buy into the whole change dynamic due to decades of wanting to know everything up front and resisting change at every opportunity.
I had tried to learn more about AGILE in the past, but got quickly frustrated with the books I was reading, usually within the first few pages. Their primary message seemed to be that AGILE was good and something they named TRADITIONAL Project Management was bad. They also equated this phrase TRADITIONAL with a waterfall approach to product development.
In all my years as an active project manager and project management instructor, there have been 3 phrases that encompass best practices.
- Planning horizon – only plan in detail what you can reasonably see
- Rolling wave – 3 steps forward, 1 step back; learning, change and step back to adjust
- Progressive elaboration – start with the big picture and the details evolve as you progress and understand more. AKA – it is impossible to know all details at the start of anything.
PRINCE2 put these 3 into a documented best practice methodology. PRINCE2 Agile addresses the current reality that most of our projects are time/ money constrained and that what was asked for in the beginning is not always what is needed in the end.
If we equate best practice with something I call Reality Based Project/Program Management, then these can be applied appropriately to any product/project life cycle. This will enable the decision-making stakeholders buy in to the fact that things change and we are unable to plan or predict the future with 100% certainty. Does it guarantee a successful project? Of course not! But it goes a long way to increasing the chance of success and potentially redefining success in a way that makes more sense.
As I studied PRINCE2 Agile, the idea of managing change in relation to prioritizing and trading off on lower priority requirements/scope made a lot of sense. If the User Communities have been directly involved in defining the requirements/scope (product backlog in Agile speak) and they have been prioritized appropriately using a MoSCoW prioritization, then the discussions about changes become substantially less argumentative and adversarial. These arguments are usually over time and cost. When we remove those from the discussion (in PRINCE2 Agile, it is suggested that the time and cost tolerance be set to 0) then it is all about understanding which requirements truly are necessary and that those will change over time.
Change management (inside the project) has always been a big part of any project. In our project culture, resistance to changes also seems to be integral to projects and project management. If the only thing that Agile enables us to do is to get our decision-making stakeholders to appreciate change, then that IS a job well done.
Julie Grabb PMP, PRINCE2, MSP, P2 Agile