Now Reading: You Don’t Need To Just Be Agile On The Ice!!
-
01
You Don’t Need To Just Be Agile On The Ice!!
The Team
Right, let’s talk about Agile projects, or as I like to call it, the mystical art of making chaos look organised. Picture this: Perth Panthers (because who doesn’t love an imaginary Scottish sports club creating software?), embarking on an epic adventure to develop some shiny new software with a crack team of talented souls.
Let’s break down this motley crew, shall we?
First up, we’ve got the Scrum Master and Project Manager. In theory, these can be two different people, but let’s be real—most projects have this as a single, slightly frazzled individual trying desperately to keep things moving while simultaneously herding cats.
Next, two Power Platform Developers—the wizards of JavaScript, Logic Apps, and PCFs. Basically, they’re responsible for the actual magic that everyone else promises.
Then, five Power Platform Functional Consultants, who translate user stories into technical designs and then configure the Power Platform accordingly. Think of them as translators fluent in both ‘Business Speak’ and ‘Tech Jargon’.
Our four testers come next—these brave souls spend their days crafting automated test scripts, test designs, and gently reminding everyone that yes, testing is still important, no matter how brilliant your code looks.
We’ve got three API Developers thrown into the mix, doing proper old-school development to create custom connectors. They’re the backbone of integrations, making sure everything talks nicely to each other.
Three Business Analysts (BAs) round out the analysis side, crafting user stories completely agnostic of technology. In other words, they describe the dream without getting bogged down in pesky realities like ‘feasibility’ or ‘complexity’.
Lastly, one Subject Matter Expert—our oracle of knowledge. This person essentially knows where all the skeletons are buried and why certain things are done in inexplicable ways.
The Tools
Now, onto the tools. We use Azure DevOps (ADO) with a nicely customised process—think of it as Microsoft’s answer to “keeping track of chaos with post-it notes,” but digital and slightly less prone to getting lost.
Here’s how it actually works in detail:
We kick things off with our BAs whipping up user stories and marking them as done once they’re ready (because ‘done’ obviously means ‘done writing’, not ‘done-done’, which is an entirely different state of done-ness).
Once we have a solid set of stories, our Functional Consultants step in for some good old-fashioned User Story Poker—scoring each story’s complexity using a customised Fibonacci sequence. Because nothing says tech project quite like making simple things complicated with maths.
These scored stories are then broken down into specific tasks:
• Story Design
• Story Build
• Test Build
• Test Execution
• Micro Deployment
Each of these tasks gets allocated specific percentages of time because, let’s face it, we all like a bit of structured panic.
The Sprints
Here’s how the sprint structure unfolds over seven sprints, each lasting two weeks:
Sprint 0
This isn’t even officially a sprint but a magical pre-sprint buffer. Our BAs ensure we have enough backlog to keep everyone busy (and slightly anxious) for at least the first two sprints.
Exactly one week before Sprint 1 starts, we gather the troops for a Sprint Planning meeting. Here, we finalise what user stories will be tackled in Sprint 1, revisit their scores if needed, and ensure everyone’s clear on the expectations. Functional Consultants immediately jump on the Story Design tasks to ensure the momentum stays high right from day one of the actual sprint.
Sprint 1
Functional Consultants dive straight into the Story Build tasks, crafting the technical reality from theoretical designs, while our Testers start setting up their Test Builds. Meanwhile, developers get stuck into the nitty-gritty of building connectors, JS components, and Logic Apps.
Midway through Sprint 1 (specifically, on day one of week two), we hold the Sprint 2 Planning meeting. In this meeting, we score, select, and prep the stories for Sprint 2 and immediately kick off the Story Design tasks for Sprint 2. Because heaven forbid anyone has a quiet moment.
At the end of Sprint 1, we host a Playback session—a glorious showcase of what’s been completed, where the team presents their efforts, and we collectively nod at our victories and quietly acknowledge minor disasters.
Sprint 2
Sprint 2 kicks off with a Sprint Retrospective—this is the session where everyone candidly discusses what worked well, what didn’t, and makes lofty promises to avoid repeating the same mistakes (which, let’s be honest, we absolutely will).
During Sprint 2, while the functional consultants and developers begin Story Build tasks for new stories, our Testers are now busy testing the code built in Sprint 1. Any bugs uncovered in Sprint 2 are gracefully queued up and scheduled for fixing in Sprint 3. Because nothing says Agile like politely passing your problems forward.
This cycle repeats, creating a rhythm where development and testing neatly overlap across sprints, each sprint meticulously planned, executed, reviewed, and retrospectively scrutinised.
By the time we reach Sprint 7, ideally, we’ve created a cohesive, fully tested, and high-quality product ready for deployment—assuming, of course, we’ve managed to dodge the chaos and keep our sanity intact.
Agile projects: organised chaos, beautifully executed.
