If you wish to take one message out of this conversation, here it is “there is no one right way to agile”. Rather there are almost infinite right ways, as many as the number of teams in the world. The challenge lies in identifying the right way for your team and being prepared to iterate

Let me talk about 5 topics on how we identify our agile process and how we try to adapt the process to fit our needs. Very likely our agile way of working will not suit your team and it should not. It’s upto you to define what works for your team!

1. Discover how agile works for your team

I remember the whole team huddled in a meeting room in our Amsterdam office debating how agile should look for our team. Being agile does not always mean following popular frameworks like Scrum or Kanban. Most of us were familiar with working in a Scrum environment and it would have been the path of least resistance. However, the task at hand for us was to build a big data pipeline on the cloud. The initial weeks would be filled with lots of research and lots of MVPs. We felt the tight constraints of scrum would have slowed us down.

In the end, we decided to work on a backlog that was always prioritised. Rather than having weekly or biweekly goals, we decided to have milestones without a timeline in mind. This process had elements of both Scrum and Kanban in it. It did not matter to us what was it called. The sole aim was to build an environment that enables the team to set up a working infrastructure asap. We hit numerous roadblocks along the way, and I believe we were able to pivot immediately and move on no matter what.

We also made the point to come back and iterate the process in the future if we see it not working for us, and this we did.

2. Iterations on the product (and processes)

We had a working infrastructure set in few months and hit our initial milestones. Now was the time to iterate and improve. We wanted to make it more flexible, improve monitoring, improve reporting and so on. When we started to iterate the product, we realised that the team was missing a clear direction. It was time to adapt our agile framework to fit this need.

We decided to start with weekly goals. So, at the start of every week, we would go through the backlog and decide on a goal together. In my earlier teams when we worked on Scrum, the product owner set the scrum goals with input from the engineers. But, for us, the goal came from the engineers with some feedback from the product owner. For this, the whole team has to be on the same page in terms of priorities and context. The team needs to be self-organised.

3. Being self-organised

For me, it’s supercritical that a team is self-organised. Here’s the premise: If the product owner or the engineering manager were to stay away for a week without prior notice, there should be absolutely no change in how the team performs. Every engineer in the team should be aware of the team’s priorities and this makes them capable to make decisions.

This is an often overlooked aspect of being agile. Agile comes from the lean movement, which is about removing waste in processes. Waste is defined as that which does not add value. I, the engineering manager or our product owner being the sole decision-maker is the most toxic situation the team can be in. Aim for collective responsibility where every member of the team is responsible and has all the context and opportunity to make decisions.

With a self organised team, topics like goal setting and iterations on the product happens naturally. The best architectures, requirements, and designs emerge from self-organizing teams.

4. On Estimations

Estimations are a topic where we have iterated a lot. When we were working on research-heavy tasks, we estimated with time boxes, i.e n engineers for m days. This helped the team maintain focus and avoided going down rabbit holes. This also helped us make decisions on the number of engineers who would look at a particular problem. ex: If we are comparing two solutions, we let two engineers work on it and then compare the results.

While we were working on enhancements to our big data pipelines, we estimated using story points. Since we did not follow scrum, the velocity or the burn-down charts using the story points did not make sense. The biggest benefit we saw out of this was to ensure the whole team was on the same page. It’s quite common that we notice our scrum poker scores are way off. This leads us to a discussion and eventually the whole team uncovering complexities and sharing the same understanding of the task.

5. Breaking taboo on ceremonies

What did I work on yesterday, what will I work on today and are there any blockers. This is the textbook definition of a stand-up. We do this in our stand up, but not limited to this. Does my teammate feel like taking 5 minutes to explain a very annoying bug? sure, we are all ears. We also encourage everyone to actively listen to each other.

Since we have data engineers, data scientists and project managers in our stand up, it’s easy to get a new perspective on the problem you are stuck at. Our stand-ups take usually 30 minutes and we never found this to be a problem. It’s also about iterations (point 3). Maybe next month, we realise it’s not the best use of our time and we change the process. We follow the same approach to other ceremonies as well.