The Agile Way, Our Way - Specialmoves

The Agile Way, Our Way

Specialmoves Labs

At Specialmoves, we’re into agile. We like the structure it brings to our development, the understanding it has for how technical stuff is made and the inevitable changes we’ll encounter along the way. But above all, how it empowers developers far beyond the more traditional waterfall approach. The sprint planning, development, retrospective and demoing at the heart of agile puts the development team in the driving seat. Skill plus ownership will produce results that skill alone never will.

Though loved by software development companies and start-ups alike, pure agile remains at odds with much of how agency-work is produced. Detailed statements of work upfront, fixed deadlines and fixed costs are expected and demanded of us by partner agencies and end clients. And for many of whom, the learning curve is steep and unlikely to be achieved within the span of a single project.

With these real and practical constraints in mind, we’ve brought the best of agile and waterfall into a single process that works for us – one that takes the bits we like about each and enables us to produce brilliant interactive experiences, made by motivated developers and hit every milestone along the way.

Here's a topline view of this process...

1. Planning and UX

30% of the time you have should be spent on planning and initial UX/designs. Any less and you’re rushing into development only to waste time and money later. A project plan is crucial and identifies milestones that need to be met to deliver on the ultimate deadline. Development could shrink or grow within these milestones but the milestones themselves won’t move. IA is specced out in painstaking detail and signed off. It’s this IA that designs for keyframes are based upon and the following sprints are developed against.

2. Agile development

The next 50% of the time you have is spent on core development and is where agile comes in. One, two, or more sprints would be planned and executed using best-in-class tools like JIRA and Confluence. At the end of each sprint, the work is tested and demoed to the client, and any changes worked into the next sprint or the impact of these changes agreed. A retrospective is held to ensure learnings are taken into the next sprint rather than just the next project. Each sprint is unlikely to produce something ready for release, but aims to be completed user stories, ready to slot into the final product.

3. QA & deployment

The final 20% of the time you have is spent on QA and deployment. QA is so often neglected, compressed and compromised at the end, but the risks of failure at this stage is significant. The steps laid out here are usually more involved than many of us realise at first, not forgetting the inevitable multiple rounds of QA and validation, regression testing and approvals. A final checklist check reminds us that this is our last chance to make sure everything that should be done, has been done. Beyond this, you’ll be fighting damage to your project and your client relationship.

What’s next?

Our process, like all good processes, is always a work-in-progress. It’s what works for us right now and how we’ve chosen to work today. But as we deliver each project and new people who join us bring their own experience, expertise and perspective, we will adapt it accordingly. After all, it’s this agility and adaptability that agile was founded on in the first place. 


Huey Nhan is the Production Manager at specialmoves where he appears to spend large parts of his day colouring in cells in spreadsheets.

Follow us on Twitter @specialmoves