Achieving FLOW with Scrum

Introduction

I struggled for a long time with the idea of starting a blog. Not just to have a blog but to be able to share my perspective on certain subjects with anyone who finds it useful. This is my first attempt to explain my way of thinking and working.

The idea to explain how we at 333travel are achieving FLOW triggered me while reading the book Applying Scrum with kanban. As I started reading, I realized that many of the ideas presented in this book were ones that we were already using. Reading about these ideas gave me the courage to write this from my own perspective.

I am writing this post halfway in the book. Where Katie is exploring positive FLOW with her team where she acts as a Scrum Master. When the book started talking about FLOW, something deep inside of me got triggered.

I got the chills reading this chapter because I just realized that we already implemented a lot of the ideas in the book. Not knowing what Scrum or Kanban was in my early days. Just by trying what felt like a natural and good way to work, back in 2017 using agile methods.

Outcomes

We have made a lot of progress since then. I can already say we are practicing a lot of the outcomes that the book uncovers.

We started working with Jira in 2017 using a modified version of swim lanes.

Having a board with swimming lanes that cover the topics of issues.

Scrapping some swimming lanes since maintenance needs to be controllable and there has to be a use for them.

During the years that followed and when we really wanted to professionalize our way of working the following subjects entered our workflow. These insights are in no particular order.

Writing a definition of done (DOD) for each of the swimming lane states.

Having the sprint goal represented on our physical whiteboard.

Using a physical whiteboard that is the single source of truth over Jira.

Having specific colors on the stories we pick up within a sprint, with a special color (green) for the stories that contribute the most to the sprint goal.

Using specific colors for other tasks, hotfixes, and such.

Blocked issues aren't a state where they can reside. Blocked issues need to get unblocked as soon as possible or rolled back after confirming that we can't work further.

Working from a feeling that we need to finish off every task/story that is swimming through the lanes as a collective to the far right before we decide to start new work (stories).

For an visual insight on our current Scrum board i refer you to the bookmark at the end of this post.

Get a FLOW going!

Why i got triggered kept me busy for a long time. Thinking about it now, I understand that they were the catalysts to get our flow going. What I saw in my team was that only when people started really working together. (As in working on the same stories and picking up their subtasks within it.) Only then we really opened the way for conversations about the stories we are working on.

But in order to be able to do that we had to create a certain way of working first, covering all of the items listed above to foster transparency and focus.

Scrum is a talk-facilitating framework. To get a flow going you need to collaborate. Working on the same stories with all developers towards the sprint goal. Ideally, you should finish something before moving on to something new.

Developers often try to avoid really working together, thinking it creates more work. They often prefer to split stories further so they can work solo on stories. Instead of working on subtasks within the same story. This small change in behavior takes some getting used to for developers. But when they start operating as a team, they can enter a state of positive flow in which everything works.

If you keep doing this solo Scrum within a sprint, you'll lose many of the benefits Scrum can provide. You can of course say you are doing Scrum. But do you want to say you're doing Scrum? Or do you want to get in an epic flow together and forever change the way you work! (who cares what the name is, right)?

It's our standard behavior to start working on tasks we already know best within a sprint (it's quicker to finish that way, right?). I also challenge my developers to work on things they haven't worked on yet within our projects. We need to get better as a Scrum team. This won't happen if we keep working in our own knowledge bubbles. Developers need to be challenged to work together towards the product goal. This will give each developer more autonomy and confidence.

Scrum isn't about the speed of development. this is merely a benefit when you reach a certain state of flow with your team.

Instill a vision

Instilling a vision is also crucial for FLOW. Having a idea of why you are building this product is one of the most important things to start with. A product vision or goal and a clear sprint goal to start from are a must. You need to be able to communicate your goal. This way you know what we are working on and what we need to do next to achieve that goal.

Defining technical debt is heavily relying on your product vision/goal. This enables you to compare your current product state to where you want it to be. And what technical debt we need to solve to get there.

A product vision isn't concrete, and it doesn't have to be long. It will evolve over time as you discover more about what the product will do and what the market wants. But it all starts with a vision you're working towards. There needs to be something to explain WHY.

Conclusion

I hope i shared some useful insights in how we were able to achieve FLOW in our Scrum team. We are merely scratching the surface in my opinion, and a lot more optimizing still has to be addressed in our team. But we are are for sure on the right track.

Especially since our whole Scrum team has the feeling that we are operating in a FLOW. This is a pretty darn good feeling to work in!