How We Work
We have a strict Agile process here at Singing Horse Studio LLP. It’s been honed over years of practice, and we continue to refine it with every project we undertake. Here’s a whistle stop tour of how we ensure successful delivery of your software.
The MVP
We always recommend our customers launch an MVP as soon as possible. Time and time again we’ve seen this artefact of the Lean Startup process pay dividends. MVP stands for Minimum Viable Product. An MVP is the smallest set of features you can include to launch a useful product. Many times we are handed a huge specification with a long long feature list. Our first task is to sit with the customer and help them pare the list of features down to the minimum list of features.
Why do we try and reduce the work we’re commissioned to do in this way? Because launching an MVP is the single most useful step a new product can take. Having a useable subset of your product running live as soon as possible pays dividends. Firstly, it ensures everything is written to production quality from day one. Secondly, the sooner you have an MVP launch, the sooner your customers or users have something to try out and give feedback on. That feedback can often take your project in a fantastic, practical, or more profitable direction than was in the original plan. Plus the sooner you have working software, the sooner you know if we’re implementing your vision in the way you want.
We recommend all our customers read Eric Ries’ excellent book on the subject: The Lean Startup – we’ll even lend you one of our copies while we’re working together!
The Sprint Process
Once we have the MVP planned, we break the project down into sprints. A sprint is between 3 and 10 working days long. Before we start we add all the features of the MVP to a backlog. We’ll ask the customer to prioritise the tasks in the backlog in order of importance. This means if we work from the top down, we’re always working on the next most important task.
We’ll kick the sprint off with a planning meeting. We invite the customer to join us to choose a coherent set of features from the backlog that we can include in the sprint. We’ll give the sprint a title, then we’ll keep our development free of distractions and provided with plenty of caffiene until the sprint is complete.
On completion, we’ll ask the customer to join us again so that we can demonstrate the fruits of our labour. The customer gets the opportunity to have a play and give us instant feedback on what we’re producing.
Working in this way leads to a happy development team – they always know what they are doing, and they always know they are solving the customer’s most pressing problem. This approach also leads to a happy customer – the customer gets to see their product evolving at every step, they get to give their feedback regularly, and the customer has the opportunity to try the sprint deliverables out on their beta customers to get that ultra-valuable real world feedback.
More Detail
You can read more detail on our process in H’s blog post How We Work.