Agile for Startups: Scrum is a toolbox, not a doctrine
In a recent “CTO Thoughts” podcast, I discussed my philosophy towards the Scrum framework when working with startups. Since it’s such a ubiquitous topic in the tech industry, I felt it was worthwhile to put these ideas into writing too.
I know that the Agile methodology is generally very well documented and there are some specific patterns that you should follow.
However, the Agile frameworks are just that — frameworks.
When it comes to Scrum, you should treat it as a toolbox and pick and choose the practices that work for you.
I say this because I know there are plenty of articles out there with titles like “You’re Doing Scrum Wrong, and Here’s How to Fix It” and “10 things you must do to build high-performing Scrum Teams” but really, I don’t think there is one overarching practice that will work for all teams.
It’s OK to customize Scrum
If you’re new to Scrum, by all means, you can start with practising Scrum “by the Book”. But you should keep in mind that this is just a starting point and you should be open to adapting it.
Eventually, you’ll get to a point where you can reassess specific routines and dump the ones that aren’t working.
You need to make sure that the process fits your organization, the type of work that you’re doing and the nature of your product.
This also applies to the additional roles that are part of this framework — like the Scrum Master or Agile Coach.
Contrary to what I’ve often observed in companies — i.e. Scrum Masters forcing people to follow the Scrum doctrine to the letter — I think their job is to propose and enable ways of working that best fit the team’s needs and create the most value. They can only do this by paying close attention to the organization, its teams and its products.
Make sure you have a flexible Scrum Master
You need to be cautious when selecting people for this role. I can tell you from my own experience, that the right person can have a hugely positive influence on the process. The wrong person also can have a huge influence: either a negative influence or, in the best case, their influence keeps the team mired in mediocrity.
And as for many things, experience and the right mindset are key if you want to be a good Agile Coach, Scrum Master or any other agile role. A certification only proves that you learned the theory — but every company and team culture is different, so you can’t turn up with a head full of theory and try to apply it to every situation.
My teams and I have had the privilege of working with many different companies, so we’ve developed a feeling for the right level of process to apply.
I’ve seen teams run into problems and friction on both ends of the spectrum. They were applying too much process when they weren’t yet ready for it, or projects were getting out of control because there wasn’t enough process.
And it takes a bit of experience to find the sweet spot on the spectrum and also to nudge it in one or the other direction when necessary.
A concrete example: the Gartenhaus project
At the moment, we’re developing a middleware solution with Gartenhaus — one of our ventures (by the way, they have a really good team and they’re hiring). This piece of software is built from the ground up and includes a lot of infrastructural work in addition to the concrete task of implementing the solution.
Could we have used a hardcore “Scrum by the book” approach here? Sure!
Would it have been helpful? Absolutely not!
Why? This was a project where we knew we had to build a lot of things from scratch. We also had product managers creating a lot of tickets on the fly and getting ahead of the development team. There were many different tasks being worked on in parallel.
Now, if you opt for Scrum, you need to commit your team to a specific sprint. Which in turn means you know exactly what you’re going to do and how you’re going to do it. You’ve groomed your tickets and you know how much effort each one is going to take.
That wasn’t the situation with this project. We didn’t have large epics, rather we had smaller tickets to lay the groundwork for the application. Like creating a skeleton for the project structure, setting up local development environments, configuring the infrastructure and CI/CD pipelines. These are all tasks that are hard to estimate. We could have attempted to estimate them, but I felt like this wasn’t worth the effort.
What we had was a huge “to do” list rather than a set of features. These tasks simply needed to get done and it wouldn’t have helped anyone if we’d used scrum to manage this work. It would have introduced unnecessary bureaucracy and wasted everyone’s time. We didn’t need any elaborate grooming process or sync meetings. The team was also really small and they were able to align and communicate in an organic, spontaneous way. There was no need for a “heavy” process.
And if we see the need for change — we change. It’s as easy as that.
Do you really need more process?
In general, when considering scrum, I think you need to ask yourself “Do I really need more structure and processes right now?”, “Is the project complex enough to justify this?”. If you’re not sure of the answer, I think Kanban is the safer bet to begin with, especially if you’re a smaller startup.
The thing is, Scrum is often used to provide predictability. You already know your team’s average velocity — roughly how many tickets and story points they can manage in a sprint. For example, suppose that you know your team can do about 50 story points per sprint. If you know that your backlog is worth 500 story points, then you know that you’ll need about 10 sprints to get everything done.
But you need to be careful with long-term predictions like these. If you plan too far into the future, you might end up in a process that looks more like classic project management (team “A” will deliver “feature X” on the 3rd day of sprint “Y”) rather than agile product development where change is expected.
The toolbox approach
My final recommendation is to start with a lean and pragmatic approach. You’ll eventually get a feel for when it’s the right time to introduce more process. And then you can take the next step in your path — peek inside your Agile toolbox and pick the tools that help you most.
