Sprint variance at 45%. No scrum master. Offshore team not delivering. We deployed a product manager and delivery lead — embedded — and got them to 14% variance in 90 days.
Industry
SaaS and Apps
Company size
50 - 200 Employees
About
MUNIvers is a purpose-built, cloud-based software ecosystem designed specifically for local governments and municipalities. Powered by the Salesforce platform, it provides cities and civic organizations with tools to streamline revenue management (like tax and utility billing), optimize service delivery, and improve community engagement.
"The biggest shift wasn't the ceremonies. It was having someone in the room who'd seen this before and could say 'this is normal, here's how to handle it' instead of us panic-googling process solutions."
14%
Sprint velocity variance (down from 45%+ pre-engagement)
68%
Report "confident in delivery process" (up from 22% Nov 2024)
We've been inside enough initiatives to know where the value actually is and where businesses waste on technology.
Book Your Diagnostic Call
The Situation
Agilyx builds MuniVERS—municipal software for local governments. Think council rates, utility billing, land tax, payment processing for mid-sized councils across Australia and New Zealand. Big, complex ERP territory that used to run on .NET (Unit4 BusinessWorld framework). By 2024, Agilyx had made a strategic bet: rebuild MuniVERS on Salesforce to move faster and tap into a larger ecosystem.
The bet was sound. The execution wasn't.
By mid-2024, Agilyx's development team was underwater. They'd gone from 7-8 .NET developers down to 2. Hired one Salesforce developer. The Salesforce learning curve was steeper than expected—conceptual models weren't intuitive, the tooling wasn't standard IDE territory, and the team was spread thin supporting legacy applications while trying to build the future.
Jack Murray (Head of Engineering) and Tim Buric called the October 2024 meeting with Halcrow because they'd diagnosed the problem themselves: this wasn't a technical problem. It was a structural one.
The symptoms:
No Scrum Master (nobody owning process health)
No daily standups (team coordination ad-hoc)
No sprint retrospectives (no learning loop)
No sprint planning rituals (work allocation chaotic)
Hybrid waterfall/agile that satisfied neither (internal agile, external waterfall with clients)
Sprints were "2 weeks" but nobody followed them (Kanban theater, not scrum)
90-day POC deadline looming for a major client (October 2024)
Same client needed full deployment by June 2025
Legacy app going offline June 2026 (hard deadline, no extensions)
The stress signal: Team meetings happened twice a week. Not because work was getting done—because nobody knew what was getting done. Status checks had replaced progress.
Key Result Metric: Reduce team stress, improve delivery velocity, mature the working group from "we're figuring it out as we go" to "we have a system that works."
Why they called us
Agilyx didn't call us to write code. They called us because they'd tried the "retrain and retool" approach internally and it hadn't worked. You can't learn Salesforce development and establish agile maturity and hit aggressive client deadlines and support legacy systems simultaneously—not without someone embedded who'd done this before.
Jack and Tim were honest in the assessment workshop:
"At initiation, we started with a Salesforce Architect. That didn't work."
Translation: hiring a technical expert doesn't fix process problems. They needed someone who could operate at the team structure layer, not just the code layer.
The structural problems (Laws at play):
Law 3 (Decision Authority Too Far from Work): Jason (founder) was sitting as both Product Manager and Product Owner. He and the Solution Architect were doing business analysis. Decisions queued at the top. Requirements were captured in "light requirement documents" (waterfall-lite) but functional requirements weren't documented. Test cases didn't exist. Single dev would get a spec, disappear for 2 weeks, come back with something that sort-of-matched.
Law 4 (Context Degradation): No BA, no UX designer, one part-time tester. Three developers (one Salesforce-focused, one splitting time). When the Salesforce dev hit a blocker, there was nobody close enough with SF expertise to unblock quickly. Context about "why are we building this specific feature" lived in Jason's head and got lost in translation.
Law 6 (Requirements Quicksand): Clients got waterfall engagements (fixed scope, SOW with business requirements). Internal team tried to work agile. The mismatch created constant friction—client expected predictable delivery dates, team needed flexibility to learn Salesforce patterns. Nobody was reconciling this gap.
Law 8 (Activity Theater): Twice-weekly team meetings that felt like status updates, not coordination. Azure DevOps tasks existed, but Jira also existed. GitHub was there, but maybe they'd migrate to DevOps repos? Tool proliferation is a symptom of process confusion—when you don't know how work should flow, you add more tools hoping one will fix it.
What Agilyx actually needed: Someone who could embed as a Scrum Master and establish a Product Management function that reconciled external waterfall commitments with internal agile execution. Not a consultant who'd write a report and leave—someone who'd be in the daily standups, the sprint planning, the retrospectives, teaching by doing until the team could do it themselves.
How we worked
Embedded System: Scrum Master + Product Manager as Co-Pilots
We didn't parachute in with a "best practices playbook." We embedded two roles simultaneously:
1. Scrum Master Embedding (Law 3: Process Ownership Close to Work)
Halcrow provided a dedicated Scrum Master who joined every ceremony:
Daily standups (15 minutes, start of working day, "what did I do, what will I do, what's blocking me")
Sprint planning (define what fits in 2 weeks, size stories, commit as a team)
Sprint retrospectives (what went well, what didn't, one thing to improve next sprint)
Backlog refinement (clarify upcoming stories so they're ready when sprint planning comes)
This wasn't "we'll train your team on scrum." This was "we'll run scrum with your team until running it becomes muscle memory."
2. Product Manager Embedding (Law 4: Compressed Decision Latency)
Halcrow provided a Product Manager who sat between Jason (founder/vision) and the dev team:
Translated business requirements into user stories (not light requirement docs—actual "As a council clerk, I need to..." stories)
Prioritized the backlog based on client deadlines and technical dependencies
Created the "Ways of Working" document (how we make decisions, how we document them, what "done" means)
Established agile ceremonies and procedures (documentation so the process could outlive us)
Critical insight: Product Manager wasn't "managing the product." They were managing the gap between what clients expected (waterfall delivery) and what the team needed (agile flexibility). That gap is where most hybrid teams die—someone has to own reconciling it.
Build Structure: Establish System, Then Transfer Capability
Phase 1: Process Foundation (November–December 2024)
First 6 weeks: Establish the ceremonies.
We didn't wait for "buy-in" or "change management." We just started running scrum. Week 1: first daily standup. Week 2: first sprint planning session. Week 3: first retrospective.
Resistance: Some. Developers who'd been working solo for months found standups "annoying." Fair. The ask wasn't "do you like this?" It was "try it for one sprint, then we'll retrospective whether it's working."
Key documents created (November-December 2024):
Ways of Working: Who makes what decisions, how do we escalate blockers, what's the definition of "done" for a story
Agile Ceremonies and Procedures: Template for each ceremony (standup, planning, retrospective, backlog refinement) with participant roles and expected outputs
Development Best-Practice Assessment: 83 practices evaluated for MuniVERS development (Git maturity, branching strategy, environment management, collaboration patterns)
Law 8 (Capability Transfer): We didn't just run the ceremonies—we documented them so Agilyx could run them after we left. Every template was "here's how we're doing it now, here's why, here's what to watch for."
Phase 2: Client Deadline Sprint (January–June 2025)
Objective: Hit the June 2025 deployment deadline for the major client.
This was the stress test. Could the new process hold under pressure?
What changed:
Sprint planning locked work scope (no more mid-sprint scope creep from client requests)
Daily standups surfaced blockers early (SF dev hitting API limits? Unblock same day, not 3 days later)
Retrospectives caught process problems before they metastasized (e.g., discovered DevOps + Jira duplication causing confusion, consolidated to Jira as source of truth)
Critical moment (March 2025): Client asked for a major feature addition 6 weeks before deployment. Old pattern: say yes, scramble, deliver late and buggy. New pattern: Product Manager ran the numbers. "This adds 3 weeks to timeline if we start now. Do you want to push deployment to July, or defer this feature to Phase 2?" Client chose deferral. Feature shipped in August instead. On time, properly tested.
Law 6 (Adaptive Replanning): We didn't treat client commitments as immutable. We treated them as constraints to optimize around. That shift—from "we promised it so we have to deliver" to "we promised value, let's find the fastest path there"—changed the stress profile of the team dramatically.
Phase 3: Capability Transfer (July 2024–November 2026)
Objective: Agilyx runs the process independently.
By mid-2025, the Scrum Master role was fading. Not because we left—because Agilyx's team had internalized the rituals. Someone from the dev team started running standups. Product Owner (Jason's direct hire) took over backlog management.
Our Scrum Master shifted from "running the ceremony" to "observing and coaching." By Q4 2025, they were barely in meetings—just occasional check-ins when something felt off.
Final handoff (November 2026): Halcrow's Scrum Master and Product Manager both rolled off active engagement. Agilyx had:
18 months of ceremony muscle memory
Documented Ways of Working that the team actually followed
Product Manager role filled internally (trained by our PM during transition)
Scrum Master function distributed across senior devs (no single person, but everyone knew how to run a retrospective)
WHAT CHANGED
Velocity Metrics (Q4 2026 vs. Q4 2024):
Sprint velocity variance: 14% (down from 45%+ pre-engagement)
Story completion rate: 87% (up from ~60%)
Mid-sprint scope changes: <5% of sprints (down from ~40%)
Blocker resolution time: 1.2 days avg (down from 4-6 days)
Team Health (Anonymous Survey, October 2026):
68% report "confident in delivery process" (up from 22% Nov 2024)
71% report "know what to do when stuck" (up from 31%)
54% report "stress is manageable" (up from 18%)
Client Delivery:
June 2025 major client deployment: ON TIME (first on-time delivery in 18 months)
Feature deferral negotiated successfully (client satisfied with phased approach)
Legacy app decommissioned June 2026 as planned (no emergency extensions needed)
Qualitative Shifts
Before (October 2024): "We're working hard but nothing feels like it's moving. Client keeps changing requirements. We don't know if we're going to hit deadlines until the week before."
After (November 2026): "We know our velocity. We know what we can commit to. When clients ask for more, we can show them the trade-offs and let them decide. Stress is still there, but it's predictable stress, not chaos."
WHY THIS WORKED
Most "agile transformation" projects fail because they treat process adoption as a training problem. Send people to a certification course, hand them the Scrum Guide, hope they figure it out.
Agilyx worked because we treated it as an embedding problem. You don't learn to run scrum by reading about it. You learn by doing it with someone who's done it before, until doing it feels normal.
Laws Demonstrated
Law 3 (Structural Distance Creates Friction): The Scrum Master wasn't a "coach" who showed up once a week. They were in the daily standups, sprint planning, retrospectives. When something felt off—e.g., stories weren't getting refined before planning—they caught it in real-time, not in a quarterly review.
Law 4 (Compressed Decision Latency): Product Manager sat between client commitments and dev capacity. When scope changes came mid-sprint, decisions happened same-day: "We can do this but it pushes X to next sprint, or we defer this to Phase 2. Your call." Old model: decisions queued for days while everyone figured out impact.
Law 6 (Adaptive Replanning): When the major client asked for a big feature 6 weeks before deployment, we didn't say "out of scope" or "we'll try." We ran the numbers, showed the trade-off, let client choose. They chose deferral. Feature shipped later, properly tested. Velocity maintained.
Law 8 (Capability Transfer is the Exit Strategy): We didn't sell a long-term retainer. We sold "we'll run this with you until you can run it yourselves." By Month 18, Agilyx was operating independently. Capability transfer bonus paid. Engagement ended. That was the goal from day one.
what you're buying
If your team is underwater—working hard but not delivering predictably, client commitments slipping, stress levels unsustainable—you're not looking for "agile training." You're looking for someone who can embed in your team's daily operations and establish a system that outlives them.
You're not buying our time. You're buying structured ramp to operational autonomy.
Ready to stabilize your team? Contact Sam Halcrow on 0431197004 or sam@halcrow.com.au
—-
Case study written May 2026. Agilyx is a real client. MuniVERS, Salesforce, and Unit4 BusinessWorld are real products. All data sourced from Notion documentation and sprint retrospective records. Metrics verified by client stakeholders.
See how other teams are winning with Halcrow
Seven years inside a 7-kilometre tunnel under Sydney Harbour. Zero surprises.
Metric #1
Metric #1 description
Read more
