Author: Matt Hamp
Agile methodology is the new kid on the block in the project world, but are you using it most effectively?
In this series of blogs, I will discuss Agile processes and ceremonies, their intent and how we can get lost in their process. I will provide my view on how, as a project leaders, we can identify potential pitfalls and ensure we are as Agile as our Agile projects.
What is Agile to the Project Lead?
Agile is the flexibility to changing demands, clients and teams, and us as project leaders. It enshrines communications on all levels and frees up our teams to drive business requirements, deliverables and outcomes at velocity.
Whilst it’s a great delivery method, if we stick to the principles to the letter, what is agile about for the project leader?
Whilst this methodology and ceremonies are important and provide some structure to modern projects’ dynamic, pivot-based nature – if we’re slaves to them, are we really demonstrating best practices to our team?
Do as I say, but not as I do.
Understanding the intent and bringing agile into the agile environment is important.
Knowing when to follow methodology and ceremonies to the letter and when we can provide a more fluid environment, we must first understand three things:
• Agile Intent
• Our client
• Our team
As project leads, we always need to be reviewing these groups of stakeholders to understand how much ‘slack in the rope’ we need to deliver in an agile way.
Agile Ceremonies
What are ceremonies you ask? I will cover these in more detail across this and future blogs. Ceremonies are generally meetings within a sprint cycle (discussed later in this blog), with the intent to provide visibility, structure, collaboration and communication between developers, project leads and the client.
The primary ceremonies used in Agile include:
• Sprint Planning
• Daily Stand-up
• Sprint Retrospective
• Sprint Showcase
In this blog, I want to begin a conversation about Agile intent, ceremonies, their importance, some mistakes to avoid and tips to improve your ceremonies. Let’s begin with Sprint Planning.
Sprint Planning
Below we discuss Sprint Planning, the foundation for all that comes next…
Intent
The Product Owner or Project Manager will come to this meeting with an understanding of the proposed sprint goal; the Scrum Master will host this meeting.
The business and delivery team will discuss tickets within the product backlog and carry over from previous sprints.
The team will discuss any blockers/issues, update delivery estimates then align on a sprint goal that will guide the next two weeks’ delivery.
The importance of the sprint planning session is that they provide both the development team and the client with expectations for the sprint and an anchor to review at the end of the sprint.
Having been involved in 100’s sprints across corporate and government projects, I’ve learnt – sometimes the hard way – how best to manage sprints for success. Here are my top five mistakes to avoid:
- Sprints cannot be changed once started: Once sprint planning has been completed, the sprint is a closed book. Any attempts to input change requests or move items from or to the backlog are denied.
- Sprint Goals are pre-determined: The project lead comes to the session with a pre-determined deliverable schedule, usually aligned to its waterfall project delivery Gant chart.
- Sprint timeframes must follow a standard cycle – every sprint must be two weeks and begin the day preceding the previous sprint’s completion.
- Incorrect velocity planning – under or over-quoting sprint velocity based on unrealistic expectations (100% velocity) or covering for other issues in the development chain (50% velocity)
- Not being prepared before sprint planning– Using the time for sprint planning to discuss and further refine user stories and gain estimations. Lack of preparation either results in separate offshoot meetings or a longer sprint planning meeting.
Top Tips
Everything is not always mistakes and learnings; here are my top tips for agile sprint planning success:
- Sprints are not just for the development team but for the business team also – If we focus on the delivery team, we lose focus on the Business Analyst (BA) / Subject Matter Expert (SME) and other business members who drive delivery.
- It’s important to ensure both teams are working to a sprint cycle – this will allow you to maintain that two sprint head start on delivery but also provide the goalpost for the business team to complete or escalate items, which can otherwise go unnoticed.
- Prioritise change – don’t lock yourself into a sprint, be adaptable. Make sure, as part of your sprint planning, items are estimated, and priorities set. This will allow you to pivot should there be a change request or update to requirements.
- Communication is ongoing – As change occurs, it’s important that you have a clear communication channel with your team and stakeholders. Prioritising change will limit developer downtime and allow you to discuss impacts with your client…it may cause a re-think of a change request.
- Velocity is an outcome of agile – understand its impacts and communicate to the wider team. Don’t hide your team’s velocity – track it, communicate impacts with the client, remove barriers and continue to aim for the best velocity available. As an example, my preferred velocity target is 70%.
Whether you’re new to agile working or have years of experience, we can always improve how we work.
To conclude, our key takeaway is ‘flexibility’. Agile allows clients and developers to move/ update and remove deliverables. As Project Managers, we need to understand this flexibility also applies to us. Yes, there are best practices for sprint planning, but use these to guide your successful project, not constrict it.
In my next blog, we will build on the message of flexibility within the agile process and discuss Daily Stand-ups and Sprint Retro ceremonies.