At Thinknear, we have used the Agile methodology since the inception of the company. But a few months ago we made some changes to our process to help improve out team. Some were changes to the parameters of the methodology and some were changes to follow the Agile methodology more strictly. Some of the changes also coincided with our engineering team splitting into two teams, which should give you a sense of our size (~14 engineers now). As your team grows it is vital to adapt your processes. Things that worked with 3 engineers, fall apart at 10 engineers. Things that work at 10 engineers I am sure fall part when you get to 25 engineers. I believe engineers who are adaptable and problem-solvers (not just code problems) should be sought after in startups. It can be overwhelming to engineers who are used to the big company pace.
I wanted to share some of the changes we implemented at Thinknear, and discuss the impact of them.
One Week Iterations
We moved to one week iterations from 2 week iterations. I would recommend this to any group that faces a lot of change or uncertainty (e.g. early startup). It allows your team to evaluate what they are doing much quicker. It is a bit ironic that our engineering org is maturing yet we decided to shorten our sprints.
But I would argue there are a lot of other benefits as well. When you have a week of work, you work even harder to break down your stories into smaller pieces. You only have a week of work, so if you have stories that take you 3-4 days, it feels like you get nothing done. Smaller stories are great for many reasons; they make us feel more productive, they make us more thoughtful in our planning and our estimates are more accurate.
Another benefit is that if some unexpected work comes up that can wait a few days, we don’t have to bother re-arranging the current sprint and working it out with the PM/PO. Because the next sprint is “not that far away”, it gives stakeholders comfort when some of their work cannot be prioritized for the current sprint. This reduces the amount of negotiating that needs to be done.
Drawbacks. It can feel like you have 2x the meetings. This is something we are improving on. Be sure to change the cadence of activities that don’t need to be done weekly (e.g. backlog grooming). The goal is to make the meetings more productive and ideally shorter. If we finish some pre-planning meeting early, we will try to do a high-level and quick pass at what might be in the pipeline two sprints from then. It helps cut-down on future meeting time.
Team Based Sprints
We used to assign stories to each team member before the sprint started. We now prioritize all the work and let team members pick off the work in the order that they are prioritized. If two stories have a strong dependency, the same person will usually take both to improve productivity.
This approach gives the chance for engineers to have some choice in what they work on in each sprint. Many claim the benefit in a team based approach is that team members are more willing to help each other. This was never a problem in our case, so I can’t speak to that. But I do believe it is important to incentivize the right behaviour in a team. Thus, if an engineer has a choice to do their “own” work or help a co-worker with their work, they should be free to help the co-worker in hopes of increasing the velocity of the team in general.
Having engineers select work promotes learning of the systems, since we don’t preselect “the expert” for the story/component/system. I think the biggest positive is the pressure to not let your teammates down since everyone is expected to pull their own share.
I can’t think of any drawbacks of this approach. You might sacrifice some velocity by not having the most knowledgeable (at the time) work on the ticket, but the gain to sharing of knowledge outweighs this drawback IMHO.
Story points vs Time estimates
We decided to move to story points in the estimating of stories. We use the Fibonacci sequence with a maximum story point size of 5. If it is larger, we will break up the story into multiple stories. This change has allowed us to estimate quicker. Measuring relative size is easier for us, instead of thinking of all the components that need to be built for a story and how long each will take. We instead think about questions like:
- what are the unknowns?
- have we done this before?
- how many pieces is this touching?
- will we need to do any refactoring?
We ask these questions because they usually uncover the hidden complexities.
Everyone will try to relate story points to actual work productivity. It is an urge that you need to fight because you will lose the benefits of using story points. Also at the start of our process, we didn’t know our velocity so we didn’t know what we could accomplish in a sprint. This takes a few weeks to get used to. This approach won’t work well if a team’s membership is highly variable from sprint to sprint, since you need to establish a baseline for work.
Sprint Retrospectives
I am a big believer in retrospectives as long as the focus is on improving (future) instead of blaming (past). If you are a team that is moving fast and constantly dealing with change, retrospectives are a perfect chance to take a breather and reflect.
We started to do sprint retrospectives at the beginning of each sprint planning meeting. This process has helped our improve team communication in various ways. These meetings gives team members a opportunity to bring up anything they liked or disliked during the previous sprint. We record all ideas and form action items for them. The team should agree on the process of dealing with the action items as well.
Some common things we bring up:
- Did someone do an awesome job at something?
- Was a particular task unnecessarily painful to do? How can we make it easier? It is worth it to do so?
- Did we mess up something up? How can we prevent it from happening again?
The list goes on…
Sort of ironically (because people view retros as a finger pointing exercise), I have seen the biggest increase in praise for other team members’ work in these meetings. I don’t think there is enough of positive feedback in engineering organizations in general and this has been a welcome surprise.
It has been all positives on our side. You need to encourage everyone to participate in bringing their ideas to the table. The goal is to have productive discussions. Sometimes people vent through this channel, which isn’t necessarily a bad thing, but you want to keep the goal in mind of improving the team.
An engineering team is like a garden that needs constant maintenance. Retrospectives give us a process around dealing with the changing environment.
Research vs Design vs Implementation
For more complicated stories we have started to create research stories before we start implementation. This approach has allowed us to be more thoughtful in building components. In the old system, research, design and implementation often would be in the same story. This allowed us to move quicker when we were a smaller team. It worked well when our system was simpler. This started to break in our more complex system because the design became a larger chunk of the work and engineers would be prone to rushing through it. It also made it harder to scope these stories because of the hidden complexities that would come out once an engineer would dive into the task.
Separate research and design stories set aside some time for the engineer to properly plan the work. In a startup this might slow you down, but in more complex systems it leads to higher quality work. The engineer doesn’t need to rush through the work. Allocating the time also allows us to document the decisions made and knowledge gained, whereas in the old system it might have been skipped. This is extremely helpful as a future reference. You should aim to still have deliverables for these stories, such as presenting to the team or documentation.
This approach might not work in a very small startup as you need to move quicker. Regardless I always recommend having at least 2 engineers look at a design before implementation starts. The 2nd pair of eyes has saved countless hours implementing subpar solutions.
Those are the bigger changes we have made to our process over the last few months. So far they have been all positive changes. Our process will continue to evolve as we mature. The key is to have everyone on the team thinking about how things could be done better.
Kamil Mroczek 