In a startup, the journey of a tech product isn’t a linear one. In this constantly changing world, founders need a process to manage projects with. A process that can give them the flexibility to pivot, as well as the structure they need to get stuff done.
That’s where the agile methodology comes in. Agile is a really intelligent way of approaching both innovation and the unknown and, for a tech startup, that is crucial.
This blog will discuss some of agile’s key principles and explain how startups can benefit from its methodologies.
Agile – Rigid but Flexible
Using agile is all about sticking to its core principles but finding ways for the individual methodologies to work for you. Sometimes, people tend to implement things like Scrum and Kanban a little too rigorously, and that doesn’t allow much room for the flexibility that is so important in a startup.
At thestartupfactory.tech (tsf.tech), we don’t run a Kanban or Scrum methodology in their purest sense. We found a happy medium that works for us, and that’s what agile is all about.
As a startup, you have to respond to change rather than have a very rigid roadmap. It’s that nimble, interactive and iterative nature of agile, and how it prioritises tasks, that really helps a startup accomplish their projects efficiently.
Constantly improving and adapting
For example, the Startup SprintⒸ we now implement at tsf.tech, originally came from a design sprint that we improved to suit both our needs and the needs of our clients.
When we initially speak with a founder, we’ll have a coffee, discuss their project, introduce them to our Startup SprintⒸ and take them on a process that helps unpack their thinking.
Then, once there is an agreed scope and understanding of their project, we unpack everything into a tool like JIRA where we can start prioritising tasks. We try not to put too much effort into estimating or predicting what will happen far into the future. Over time, we have found that, with startups, these estimations are rather useless.
Let me explain why.
Try not to estimate too much
There are so many unknowns in a startup and we discovered that expectations weren’t being set properly because things kept changing, so instead, we moved to more of a prioritised list process.
The idea here is that everything needs to be done and, if we know roughly how long the project might take, each individual item on the list can flex and move depending on what needs to be done first. Like anything in a startup, it’s important that you have an overall vision but are flexible enough to change – and, sometimes, estimation goes against that.
However, if you are not careful, agile can be too flexible. If you are constantly reprioritising stuff because of new projects, then important tasks can get pushed down to the bottom which can cause problems of its own.
So, how can we use agile to keep us both flexible to change and structured enough to maintain a smooth workflow?
A good project manager keeps everyone focused
That’s what a project manager’s role (like mine!) is all about. A project manager can make a big difference by overseeing everything and helping the product owner understand which tasks need to take priority.
This reordering of tasks keeps everyone’s minds focused on what matters most, and does it in a clear, simple way using the agile methodologies.
One of the best things about agile is that it’s focused on people. Its simplicity helps to secure a strong relationship and engagement between the tech team and the non-tech people because the concepts are made out of clear common sense.
It’s not a complicated process at all. There seems to be a lot of misconception that tools like JIRA are complex programs for the developers, but that’s not the case.
JIRA is more for non-tech people like the founder or a client, so they can look at the product and know exactly what’s going on.
It gives the entire project total transparency and helps them make an informed decision about what needs to be prioritised. This transparency also allows maximum collaboration because the whole team is on the same page.
Here are a couple of examples of how agile can help with total collaboration across a tech startup…
Showcases and retrospectives
Every sprint (a predetermined set of time in Scrum between one and four weeks) starts off with a planning session. This is where you plan what’s going to be done in the next two weeks.
During this period you will have 15-minute meetings every morning where you discuss the following:
- What was done yesterday?
- What’s being done today?
- Is there anything blocking me?
Then, you move into two “ceremonies” (or meetings, if that sounds too grandiose). These are:
- Showcase: A demonstration of what we planned for the last two, three or four weeks. You also showcase what was delivered.
The showcase meeting allows product owners or any of the stakeholders to see what’s going on. These meetings should always take place with working software too so people can look at the flows and the screens and point out anything that needs addressing.
Then, any task that needs doing gets a ticket added to the backlog and is prioritised.
The great thing about this process is that it allows close communication in a structured but informal way. There are times at tsf.tech when we’ve had our meetings over beers and pizza, so there is no reason why it can’t be fun.
It’s also a great way to celebrate successes and provide the tech team with the recognition they deserve.
- Retrospective: This is a meeting we run shortly after the showcase which is all about the process.
This meeting is where we look at what’s working and what isn’t and spot any blocks that keep coming up.
Retrospectives are about making sure the processes you are using work for your team. You can’t force-fit something that doesn’t work, and that’s why having these meetings is so important. They allow for total transparency between everyone in the team, and you can use people’s feedback to build your own tailored process that everyone is on board with.
Build, measure, learn
The thing to remember is that whatever process you use, a tech product is never truly done. Everything in a tech startup is iterative and should have the build, measure, learn mindset applied to it.
You’ve got to learn from your processes and keep adapting them as you grow. That way, you can make sure what needs to be done is delivered, and if any changes occurred, everyone is on the same page as to why they happened.
So, whatever process you like to use, whether it be Scrum, Kanban or anything else, the main thing is that you have a process that’s fit for your purpose.
If you are thinking about adopting the agile approach, I’d always recommend you start with the more rigid process and stick with that first. Then, as you get more experienced, you can use the retrospective meetings to see where you can start to tailor the process to suit your specific needs.
I hope you have found this useful. If you have any questions or would like to hear more about the agile process, check out episode 11 of our podcast “From the Factory Floor”, where myself and Ian go into more detail. Alternatively, feel free to email me at jamesb@thestartupfactory.tech.
