The agile Scrum framework is powerful. It has proven itself highly effective for startup teams, larger organisations, and teams working towards continuous digital product improvement.
But what we’ve discovered is that it often costs more money to run a textbook Scrum approach for smaller and more ‘controlled’ digital product builds.
For a great overview of what Scrum is, check out this article from Atlassian.
For startups paying out of pocket, or SME’s working from a tighter budget, cash is scarce and there’s not a lot of wiggle room. When I say smaller projects, I mean smaller marketing website builds, or first release of a small mobile app, for example.
The Scrum process in the hands of an in house team and stakeholders has little downside. But when a client and digital product team (not in-house) are working together, there are two new factors to consider:
- Client and delivery team are not always aligned and prioritisation is generally harder. This leaves margin for constant changes in direction in an attempt to reconcile differences. This wouldn’t be too bad, but:
- the delivery team are not on the client’s payroll. This means changes during the project will cost the client extra time and money.
But I am not proposing a standard waterfall approach either.
No matter what project you are doing, there will always be rework and iteration – it’s necessary for success. But the Scrum process encourages highly regular iteration and “re-steering”, and when it’s abused it creates a “we will figure that out later” culture.
This is problematic for smaller client+studio projects because it’s nearly impossible to create a controlled scope of work, meaning:
- The client can change their mind and revise, endlessly. If a client can do that, they will – it’s a law of nature and the Srum process encourages it (although with logical and constructive intention).
- Friction occurs because if the studio bills per-hour or per-sprint, the client ends up paying more and lengthening the project timeline.
In these cases we have created a cycle where the process to execute doesn’t quite match the client’s need to control the spend and timeline while guaranteeing some kind of finished product.
The agile mentality and Scrum framework was designed for software teams with a view of continuous improvement. Atlassian’s guide says:
“People often think Scrum and agile are the same thing because Scrum is centered around continuous improvement*, which is a core principle of agile.”https://www.atlassian.com/agile/scrum
*Bold style added to highlight and emphasise.
As my co-founder Bailey says “the whole philosophy with Scrum is that your product is never really finished.“
This approach, then, isn’t going to end well for a client with a short budget. The kinds of projects I’m talking about here are meant to be “finished”, not go forever.
But if you don’t allow for iteration, alignment, and room for adjustment as things become clearer, then it’s also going to end up a complete mess.
So, how do we approach it?
It sounds very abstract and something that a digital transformation consultant says to get new business, but it’s true:
We combine the sequential, requirement-focussed and scope-controlled approach of waterfall with concentrated and ‘expected’ pockets of iteration and flexible response to change.
Rather than the iterations changing the scope of work and causing the client to lose track of their budget, we’ve designed our approach so that each planned ‘pocket of iteration’ better informs the next phase of the project.
Design & Prototype Sprint
One way we do this is by starting every project with concentrated Design and Prototyping Sprint. This is an altered version of the design sprint. It focuses on the creation of a high-fidelity interactive prototype (using inVision, Framer, or other appropriate tool) which is then tested with users/customers or target audience.
This lets us take a controlled “chunk” of the budget and “jump into the future” of the product, shortcutting the build and launch phases of a Scrum cycle/sprint.
Design & Refine
After this initial sprint, we reassess and prioritise everything that must go in the final product based on what comes from the user validation as well as what was not covered in the prototype sprint. From here we try and answer every question we may ask during the design phase. Then we design the product, with the view that what gets designed will “go into development and come out the other side as a real product”.
Tech Spec Doc
Next, we create a tech spec document as a team, which involves designers, devs, PM and the client documenting everything that can’t be obviously assumed from the prototype. This covers things like how forms will be stored, database schema, and even the subject line of automated system emails. It’s like writing a script you could hand to a developer to follow and come out with exactly what you are hoping for. Our intention isn’t to direct the developer and tell them how to do their job – it’s to give them all the information they need to do it well.
*Disclaimer, a tech spec doc can never cover everything, but it takes out a lot of guesswork.
Don’t get me wrong, I’m not saying digital product studios can’t run a Scrum process – we do it with bigger projects and ongoing engagements with our clients and partners. It works best for bigger product builds and continuous improvement. What I am saying, is that you need to apply it to the right projects. Small, controlled projects are not the right ones to do so.
So, to summarise?
The Scrum framework is powerful and flexible for teams working with a view of continuous delivery. It’s great for big projects and products that are intended for ongoing improvement. Small digital product builds (marketing websites, first release of an app, etc.) where the client is not yet intending on “continuous improvement” are not appropriate for Scrum. This is because the client is looking for a particular outcome for a set spend and intend to simply launch the product when it meets completion criteria and may come back when they need further rounds of iteration.