As a seasoned Prince2 Project Manager, I was very comfortable in managing projects in stages. The scope was defined and locked in. The sponsor and project board had a clear understanding and agreement of what would be delivered in the stage. Any deviations to the project delivery were managed through exception reports……Life was good.
Then – along came Agile and to be brutally honest, the prospect struck me with fear….
WHAT ?? the client can change their requirements on a whim ? My mind screams ‘that’s not in scope!!’
A Sprint is only 2 weeks long?? My mind exclaims – ‘what can these developers build in 2 weeks??’
There’s 100 stories in the Product backlog ? How can these not be in a Project schedule…. I NEED to build a detailed schedule….
A requirement is a User Story ? and I’m thinking – a User Story is what I read to my daughter every night…
There was a lot to learn in this new Agile world…. and yet I do enjoy a challenge….. so the lessons began.
I was the new PM on the Block…. (is that a song?)…and I needed to show my team some confidence that I (somehow) knew a bit about Agile.
So we had daily stand-ups – this was a great idea! I could now grill….no not grill…..I could request a daily update from each team member and find out if there were any issues that I needed to resolve. This would definitely assist me in tracking project progress.
We held Sprint Planning sessions, bought some Scrum Poker cards and had great debates about business value and story points…. I enjoyed negotiating with developers on the effort to complete a user story, but it was also difficult to assign business value to a story without the Product owner present.
We conducted Sprint Retrospectives – these were difficult to begin with but the team soon learned the benefits of having regular reviews and getting feedback from all team members.
We appointed a Scrum Master to help the team manage their sprint products and keep the team on track.
I was beginning to enjoy this new approach in managing a software development project…. and I quickly began to understand how Agile can be used to deliver products to our customers in a faster way.
Not everything went to plan though so I would like to share my own lessons learnt –
- Get a Scrum Master on board at the START of the Agile Project. I see the Scrum Master as the lead who will provide the guidance and direction to the development team on a daily basis. They are also great for managing the product backlog and keeping the team on track.
- Like the first point – Get the Product Owner on board and keep them on board through the entire sprint. The ideal scenario is where the Product Owner is embedded in the Project team. They can make business decisions on the spot and this is what makes the project delivery truly Agile!
- Develop and deploy a product version in every sprint – this can be difficult with a lengthy and complex project but there is a definite advantage in conducting regular testing and reviews with the Product owner. We held product refinement sessions to demonstrate our product and seek immediate customer feedback that we can quickly build into the next release.
- Don’t underestimate the testing effort or timeframes. This includes integration, user acceptance, performance and regression testing. Of course – I think this applies to both Agile and Non-Agile projects but it must be factored into Sprint planning sessions. You may be tempted to squeeze testing effort – my advice – don’t!
- Business engagement and communication is still a key requirement – although you may have a Product Owner working in your Agile team, you still need to maintain regular contact with all your client stakeholders to ensure they are aware of current project status, issues and risks.
Overall – I can now begin to appreciate the benefits and techniques in Agile Development and I am more confident in applying these in new Projects.
I would be keen to hear your thoughts and experiences in adopting the Agile approach in your projects.