Aspire Fridays with Scott Hanselman: Modernizing Architecture with Scrum
Introduction
This session of Aspire Fridays brought together Scott Hanselman and three dev teams from the Aspirify group. Acting as a Product Owner, Scott opened up his long-running set of applications — blogs, podcasts, and admin sites — for a real-world modernization exercise. Using Scrum thinking, the team tackled architectural challenges and explored how Aspire can unify Scott’s diverse .NET apps.
The video can be watched here: YouTube Link
The Product Owner: Scott Hanselman
Scott manages several apps under what the team jokingly calls Hanselman International:
- Hanselman.com – brochureware site on Razor Pages (.NET 8).
- Hanselman Blog – running on DOSBlog, also in .NET 8.
- Hanselminutes Podcast – separate app with caching and third-party APIs.
- Admin site – newer site in TypeScript.
- Azure Friday site – another .NET app in the mix.
All of these live behind Azure Front Door, hosted on App Service for around $41/month. His role in this session resembled a product owner in Scrum — balancing business needs (cost, performance, reliability) while enabling developers to explore architectural improvements.
The Dev Teams: Aspirify Engineers
The Aspirify team (Maddie, Damian, David, and others) acted as three Scrum dev teams, pairing and swarming around Scott’s repo. Their Sprint Goal: aspirify Scott’s architecture by pulling one of his apps into Aspire for orchestration and better developer experience.
Sprint Planning: Choosing a Slice
The group applied Scrum’s “vertical slice” principle. Instead of aspirifying all apps at once, they selected the Hanselminutes Podcast app as their Product Backlog Item. It was complex enough to show value (caching, APIs, feeds), but isolated enough to deliver in a Sprint.
Sprint Backlog: Key Tasks
- Setup Aspire AppHost – scaffold a host project.
- Reference Podcast Project – wire it into Aspire.
- Update SDKs – align Scott’s machine with .NET 10 RC1.
- Fix Dev Loop – ensure Aspire Run can orchestrate local services.
- Plan for Multi-App Future – discuss extending to blog, admin, and main site.
The Daily Scrum Moments
Like a real Scrum team, blockers and surprises came quickly:
- SDK Mismatch – Scott only had .NET 8 + preview 5, no .NET 9 runtime, causing Aspire templates to misbehave.
- Naming Chaos – legacy folder naming (“Hanselman-Core”) created confusion when adding projects.
- Tooling Gaps – Aspire CLI vs Visual Studio templates led to frustration; the CLI lacks smooth “add to existing solution” workflows.
- Power Outage! – Scott’s entire neighborhood lost power mid-session, forcing him to tether his laptop to a phone hotspot while the team continued.
These became classic Scrum impediments, handled collaboratively in real time.
Sprint Review: What Was Delivered
By the end, the team had:
- An Aspire AppHost running Hanselminutes locally.
- Project references wired through Aspire with resource naming clarified.
- Confirmation that the Podcast’s caching and third-party API dependencies could be observed via Aspire’s dashboard.
- A roadmap for scaling this to other apps under Scott’s ecosystem.
Retrospective: Lessons Learned
- Start small – Aspirify one app first; expand later.
- Tooling gaps – CLI experience needs to catch up with Visual Studio integration.
- DevOps pain – expiring tokens (GitHub, Azure DevOps) are ongoing impediments.
- Resilience matters – even a power outage didn’t stop progress; distributed Scrum teams can adapt quickly.
Conclusion
This Aspire Friday highlighted the intersection of Scrum practices and modern .NET tooling. With Scott as Product Owner and the Aspirify teams collaborating, they demonstrated how real-world architecture can be modernized incrementally.
The next Sprint? Expanding Aspire orchestration across Scott’s blog, admin site, and Azure Friday app — continuing the journey from legacy silos to a unified aspirified architecture.