Getting started with Agile – how do I ring-fence my teams?
Updated: Mar 22, 2021
Firstly, there’s never an “ideal” time to transition to Agile so don’t wait for it. We have often trained organisations only to find it was just too hard to get started because they had so many projects in flight they felt they couldn’t pause – select resources – and start Scrumming with these ring-fenced teams. So they either never start, or try to start with part time teams and are frustrated when it doesn’t work. And of course they say Agile doesn’t work not that they can’t prioritise and restructure their workload.
We understand that organisations need to finish projects and operate, they can’t flick a switch and change tomorrow. That said, it’s a question of prioritising what’s really important - to quote Michael Porter in an old HBR article, “the essence of strategy is choosing what NOT to do.
Do you suffer from multiple projects that are limping along due to resource issues? Many organisations suffer from too many projects and flatly refuse to acknowledge that prioritisation and stopping some is the best possible course of action. So what can you do?
There’s a great HBR article, well worth a read, which proposes a rationale and structure for doing this, so rather than me reinventing the wheel, check it out!
Alternatively, you could ring-fence your teams 100% and split out their workload, say 70% Agile and leave 30% of their time for AOB. Of course that won’t be possible but it’s a start point. Measure every task accurately and within a couple of Sprints you will see the reality of the workload and how it’s split. This means you can decide where to move the non-Agile work as you can now quantify it.
Project triage done, you will be in a better position to set criteria for any new Agile projects. Things to consider include:
Stating the obvious but do you have the ring-fenced people and budget you need on your team?
Are all of the Stakeholders and end users committed to the time you require? By this I include Legal, Finance, Marketing and whoever else will be impacted or you will need to sign off.
Are Support/Operations involved at the outset and available throughout the product delivery?
Are Procurement briefed and ready to buy licences, hardware and anything else you may need in a timely manner?
Is everyone aware of the consequences of not being available – ie you will stop?
Is there business value in everything you deliver and is it all prioritised?
What can you NOT do?
Perhaps the last point is your biggest challenge. The fact that resources were tight in the first place shows us that you need a reality check in organisational capability. Over-stretching teams at any point, let alone the early days of Agile adoption will at best demotivate them, at worst reduce quality and burn them out.