What being an Agile Project Manager is really like
Philip Nicholls | Digital Project Manager at Purplebricks
The Myths around Project Managers and Agile Teams
There is a common school of thought among many that project management and the Agile methodology can’t coexist. My experience says otherwise…
Let’s start with a some rough, and often misconstrued, definitions.
Project Management
Project managers try to deliver set work to strict timelines and costs, often over-running both, and they don’t allow flexibility in scope. They insist on accurate estimates, create pretty Gantt project plans and move the little bars to the right, change greens to reds and moan about missed deadlines.
Agile teams
Agile teams don’t care about costs or timelines. They collaborate on increments to the product which deliver value. They like to attempt, fail and learn from experience. They constantly refactor code, figuratively tidying up the campsite because of the mess the previous troop left, creating something that is perfect: nicely structured, robust, self-documented, wrapped in repeatable self-running tests, functionally-rich.
My observations
My favourite myth to bust is timelines. The Agile team commits to deliver (or some say commit to try to deliver) something every sprint, which is often every two weeks. The whole team agrees what it will get done in that sprint and plan the order in which it can do it all, delivering value as soon as possible in that sprint and then building on it. The team members sometimes set aside optional ‘stretch’ tasks, anticipating any issues that might occur or tasks that might fly through unexpectedly. It’s a real art. Agile Project Managers love this bit, especially when they see an Azure Devops board with all the tasks moving to the right and, in their heads, going from red, to green, to blue.
Ah, I know what you are thinking. How do I know the Agile team can commit to deliver in those two weeks? That’s the clever bit. The team also agree how many “cabbages” each task on the list (backlog) will figuratively balance on the Agile scales, a bit like estimating but not in people or time format. And from previous experiences, the team knows how many “cabbages” it can consume in two weeks. That’s cool. It also knows if someone has planned to be on holiday next sprint, so won’t be eating their share of “cabbages”, so the team brings fewer “cabbages” in to consume.
What I like about this approach is that each piece of work’s description is written in simple prose to explain what value it needs to deliver and to whom, although some teams do tend to write very technical, mathematical, Just-Do-It stories, too. Project managers historically do like the wordy versions, like chapters in a good book, but Agile Project Managers hate the old world where they had to wait weeks to get a four-hundred page specification signed in the blood of three yet-to-be-born waterfall coders before they could start work. The Gantt plan marker moves way to the right before the first code turf is even cut. That means we are behind schedule and may miss out on the A-Team.
What does it all mean?
As an Agile Project Manager, I want all the interdependent bits of work to be finished together in priority order so that I can say we delivered staged value to the customer, in each time box/sprint. Just like the Product Manager, if a stakeholder says add something in, I say “what do you want to take out?”
I want to know that it fits in with the strategic aims across all products.
My ‘sprints’ are longer.
A banal example from the Agile text
It’s holiday season, Team V have been diligently working away, firstly creating a plain, old motor scooter which did the job. Then they incrementally added more wheels, a roof and the bigger engine. Meantime Team H has built a functional trailer and is now scheduled to put a top on it.
Our stakeholder wants to know that when his holiday arrives, he’ll have a working car and a caravan. I’ll be helping coordinate that across both teams. And when it’s pointed out that a tow bar is a must, the V Product Manager will say “forget the fancy paint job then!”. And too right.
As an Agile Project Manager, I am happy that we achieved it all. In fact we probably delivered it ‘all’ earlier than the stakeholder expected and now having tried it out, he might decide to forget the fancy paint job altogether, in favour of something else. You couldn’t do that in a waterfall world.
As Eisenhower said,
Plans are useless, but planning is everything.
