Transitioning a Waterfall production team to an Agile project
The first thing that springs to mind when tasked with moving an inherently Waterfall production team to a more Agile way of working is “How will they manage their own time without a project manager telling them what to do?”.
In this instance I’ll talk about Scrum.
The first thing for the team to get their head around is the differences in their new job roles:
- Development Team - Self-organising and cross-functional. Decide how to work together to get tasks done and accept that everyone owns all tasks collectively. If it’s being designed…you all own it...if it’s being developed…you all own it...if it’s being QA’d...you all own it.
- Scrum Master (that’s ME!) - Time to lead by being a servant. The biggest challenge of all is learning to LEAD by SERVING the team. Set the ego aside, no telling the team what to do, just lead by facilitating and coaching the team.
- Product Owner - Optimize the value of the product, engage stakeholders, inform the development team and hopefully the organisation will respect your decisions 100% to get that awesome product!
As with transitioning in any shape or form, it’s a journey rather than a single lesson. It’s key as a Scrum Master to observe how team members are adapting to their new roles and help educate them over the course of the project. The aim is to enable them to have the skills and mindset to become the self-organising team you dream of.
Meetings are boring, ceremonies are fun…..
To aid the new roles the team have, Scrum ceremonies are key, not only for project quality but also personal development.
First of all Sprint Planning is going to be longer than your usual project kick-off. You will get the odd cry of “Can we just start already?!”, it’s important you help the team understand the benefits and that the time investment here leads to bigger rewards down the line. Make sure the team comes out with a clear idea of what they’re aiming to produce and set out a “Sprint Goal” to keep the team focused on the bigger picture throughout the Sprint.
For 2 week Sprints, our planning meetings usually last 3.5 hours, handily this concludes the meeting at lunch time. Focusing for 3.5 hours is a challenge in itself for anyone, so organise a post planning meeting team lunch. This also establishes the team mentality.
Daily scrums are an opportunity for the Development Team to take the lead. As a Scrum Master you can help facilitate the meeting, but be conscious to take a step back and let them answer:
- What did I do yesterday that helped the Development Team meet the Sprint Goal?
- What will I do today to help the Development Team meet the Sprint Goal?
- Do I see any impediments that prevent me or the Development Team from meeting the Sprint Goal?
Remember this is their meeting, coach them and let them find their own way.
So the team has done the hard work in the Sprint, but it’s not about how you start, it’s about how you finish. Sprint Reviews should be kept informal (this does not mean without structure). Showcase what you’ve achieved over the last sprint openly. This shouldn’t be a ‘tada’ moment as hopefully stakeholders have been kept engaged by the Product Owner. Think of it more as an opportunity to inspect and adapt, an opportunity to learn.
Look back, reflect and grow…
Make sure you follow up the Sprint Review with a separate Sprint Retro. We’ve run a variety of Retro techniques, but Mad, Sad, Glad works well. It allows the team to express how they’ve felt over the course of the sprint as well as pattern spot any recurring themes. Finish by defining the actions and a plan for implementation.
It’s always important to emphasise the meaning behind meetings, try and kick-off any subsequent Retros with the simple list of actions from the previous Retro and let the team decide “Did we achieve this? Yes or No”.
That’s the raw materials, but what tools do you use?
Scrum doesn’t prescribe using any tools in particular so I won’t go into too much detail on this (I may cover this in future blogs), however the one thing I do recommend is taking over your workspace:
“We shape our places, then our places shape us.” Winston Churchill
Help the team immerse in the product they are working on, make it easy for teams to see important information at a glance and encourage ownership. You own the product, so you should own your space.
Finally, celebrate the small wins, a feature going live, a test completion, whatever count as an achievement. As a Scrum Master make sure you Ferris Bueller (yes I did just turn that into a verb).
