Laimonas Vainoris, Business Operations Manager at Adroiti, shares his insights on how it looks in practice and says that it is not worth pretending to be a startup if you are not.
"I don't want my developers to be drones just carrying things from point A to point B. I want them to think independently and own their stuff," one of our lead engineers working in a 12-person startup team once said. This idea perfectly illustrates the mistakes often made by managers when choosing the operating approach. People's independence and creativity can be destroyed if they are squeezed into a framework too early. At the same time, achieving the result can become too difficult if they are not provided with one in time," says Laimonas.
Laimonas singles out 4 essential things that should be evaluated when choosing the relevant methodology: team structure, clarity, experience, and organizational realities.
TEAM STRUCTURE. How to facilitate communication?
New team. I do not believe in the usefulness of pure SCRUM when it comes to tiny teams, and I think this methodology needs to be adapted. For a small team with experienced and motivated members who know what to do, SCRUM is not needed. However, if a completely new small team is formed, people in the team don't know each other and need help knowing what to do, then SCRUM could come to the rescue. It provides a structured operating framework to make everyone's life easier. Later such a team may well grow out of SCRUM because people gain experience and trust in each other.
A growing team. As the team grows, so does the need for communication, which affects the choice of methodology. For example, five people can work well, and it is easy for them to communicate, but twelve people are already looking for ways to improve communication. At Adroiti, more often, we choose the option in between - Scrumban - that has adapted scrum ceremonies but is fundamentally a kanban delivery instead of sprints.
A big team. If the team grows to 30 people, it means that we have roughly 6 smaller teams. Not all the people in them are seniors, and not all of them are equally motivated. Then, the possibility of switching to the SCRUM and scaled agile methodology makes more sense.
CLARITY. When should improvisation be allowed?
If the project scope is clear and the steps to implement it are known, SCRUM will work perfectly. However, if there is a lack of clarity, SCRUM will not give a good result because it will force people to strict frames and will not allow enough space for creativity and improvisation. After all, when you don't know something, that's exactly what you focus on – your R&D.
EXPERIENCE. When is control necessary?
The more independent people become and start occupying senior positions, the less suitable SCRUM is for them. It's the opposite with the junior positions, where you need clearer frameworks and instructions on what to do. For example, a less experienced project manager will need more guidance and structure before he/she gets in and starts working independently.
ORGANIZATIONAL REALITIES. Why is it not worth pretending to be a startup?
The Lean philosophy prevails in startup projects, as the aim here is to get the best result while taking the shortest route and failing fast if needed. In such projects, it is not yet clear what exactly is needed, whether the ideas will work, and whether your product is not paying for its own development yet. As a result - no one knows how much funding will be needed in the end, so Lean principles are fundamental here. One of the main ones is that the highest value work should be done and market-tested first, and any waste / unnecessary rework be brutally minimized.
In startup teams, SCRUM is not needed at all because this is where people think independently, making decisions on what they need to do. Improvisation and creativity are necessary here. Except when the team is growing rapidly - then SCRUM within a scaled agile framework could help as a starting point for developing your own delivery model.
I recently came upon a case where a team of 30 people in engineering still considered themselves to be a startup, even though they had grown out of it a long time ago. Instead of giving the team clarity and frameworks that would facilitate the projects, the engineers still operated in a loose Kanban. This meant perpetually being on a back foot with communication and planning, more legacy code, and eventually - rework. It is crucial to understand that the team itself must grow and change, and one must change the methods that work best accordingly.
What form of Agile methodology fits best for your team? Share your experience on Adroiti Linkedin!