How alternating between focused and flexible development helps us move faster

Lisa Maurer
Oda Product & Tech
Published in
7 min readFeb 22, 2021

--

This post is part of a series introducing Flow — our latest iteration of how we are working in and across development teams to create value. Development teams are cross-functional teams which work in the field of product development, growth development and logistics development. You find the introduction to Flow here. In this post we share how we are balancing strategic development with all the other tasks and activities necessary to align & cooperate across teams as well as solve critical issues and allocate time for tactical development.

Balancing strategic development, maintenance, alignment and everything else

Our development teams continuously develop and improve the product, logistics and growth loops, align their plans and ambitions with stakeholders, maintain a solid product experience & operations and build efficient, strong and thriving teams. In detail this means that we want to allocate time for:

  • Uninterrupted periods with high focus on solving complex problems
  • Solving sudden critical issues that have potential to harm our business instantly
  • Tactical development and maintenance
  • Individual growth, knowledge sharing sessions, best practice development with colleagues
  • Team building activities as well as team retrospectives
  • Alignment as well as planning cross-team projects which became more pressing with a growing number of teams

If every team is balancing these activities on their own schedule, they interrupt the flow of other teams and colleagues and it becomes increasingly difficult to efficiently work towards our goals. We therefore, introduced a joint rhythm which allows us to balance all activities.

A joint rhythm

A joint rhythm, alternating between focus and flex

By separating Flow into two different phases we aim to strike the right balance between time spent on working towards our strategic goals — focus and time spent doing everything else -flex. All development teams are following this joint rhythm which means that everyone is alternating between the two modes in parallel.

This predictable rhythm enables us to reach bigger goals faster and more consistently over time. It makes it easy for teams to be mindful about other team’s flow and to know when and how they can more meaningfully collaborate and align with each other vs. remain focused on bigger achievements. Another fun part is that this rhythm allows us to celebrate successes together and share learnings with other teams as part of our demos at the end of a focus period.

As a result, a team’s calendar looks a lot like this:

Calendar view during focus and flex

During the focus period, the team has a few team syncs during the week and blocks most time to solve complex problems as opposed to the flex periods in which we for instance block full days for discipline deep dives and make room for meetings with other teams and stakeholder check-ins as well as team retrospectives and the like.

Let’s have a closer look at what we are doing during focus & flex periods:

💡Focus — increased focus, reduced time to impact

Focus periods consist of 6 weeks dedicated to achieving progress on strategic goals, whatever that may entail for the team — be it deep work building new features, collaboratively designing or strategising on the next big thing, releasing experiments and analysing results, removing large chunks of technical debt, — or anything in between.

The essence of focus weeks:

  • To get uninterrupted time. We need longer periods of uninterrupted time to make progress on our strategic goals and make room for planned collaboration with other teams. When you pull someone away for one day to fix a bug or help a different team, you don’t lose a day. You lose the momentum they’ve built up and the time it will take to gain it back. Losing the wrong hour can kill a day. Losing a day can kill a week.
  • Commit to producing something strategically meaningful. This requires both planning and alignment, and teams are expected to commit to plans in advance of each focus period — instead of constantly having to second guess whether they are doing the right thing.
  • To have a deadline. We believe in fixed time variable scope. We don’t want projects to stretch out indefinitely. A fixed time of six weeks gives us a natural deadline. We don’t expect to have completed larger projects (e.g. planning and developing a new fulfilment site or building a recommendation engine) within this period but we expect it to be instalments towards larger goals. The fixed time ensures that we assess the results of each focus period and decide if we can continue as planned or need to course correct and adjust our path forward. This pushes us to make concrete steps along the way and prioritise how we spend our time within the focus weeks.
  • Be prepared to demo your work and share insights with your colleagues. It doesn’t have to be flashy, but even removing stuff can be a cause for celebration deserving of a hype video.

It is ultimately up to the team how they design their development process but we created a plain vanilla recipe for going from strategy to action which can serve as a guideline. We will share our thoughts in a separate post, coming up soon.

Activities during focus weeks

💆‍♀️ Flex — dedicated time for miscellaneous activities to keep us going in the right direction

After 6 weeks of focus, all development teams switch into 2–3 weeks of flex which consists of miscellaneous activities. Some of these activities are expected while others are guidelines which are optional for the team and individual team members.

The essence of flex weeks:

  • To take a break from focus: It is not necessarily a break from coding, designing etc., but it’s a break from total focus (strategic development) and allows us to take care of issues which are crucial for Kolonial.no at large and weren’t addressed in the focus weeks, i.e. tactical development and maintenance.
  • To assess progress and plans and evaluate whether the team requires a course correction or can continue as planned.
  • To enable collaboration with the rest of the company while reduce overhead over time.

In detail, all teams are expected to conduct the following activities during flex weeks:

  • Team retrospective: Reflect on the workflow in your team and detect areas which require improvements, but also use this opportunity to give kudos to your colleagues and highlight special efforts of the past weeks.
  • Stakeholder check-ins and Flow meetings: Reconnect with your key stakeholders and reflect on your collaboration and workflow during focus weeks and commit to the ambition of the next focus period.
  • Collaboration on tactical development and maintenance: In order to allow us to focus the majority of our time on strategic development, we need to make sure that we spend a large part of the remaining time on tactical development and maintenance. These issues are not critical enough to be fixed immediately but have a high value in solving because they unlock either customer value, business value and/or product/tech value and are not on any team’s roadmap in the foreseeable future.

It is up to each team to decide how to use the remaining time during flex weeks best but we encourage everyone to make time for the following activities in order to start the upcoming focus weeks energised and well prepared:

  • Individual growth: Time to conduct research on a specific topic, technical explorations, hackathons, etc. as well as writing blog posts
  • Discipline deep dives: to share knowledge and best practice with colleagues, evolve the discipline and improve methods as well as introduce and assess new tools.
  • Team building activities
Activities during flex weeks

So far so good.
But you might wonder “and what about solving critical issues?”. Well, we actually solve critical issues immediately when they appear and independent from whether the teams are currently in focus or flex periods. This however brings me to the next point.

Unresolved matters & tricky parts we want to improve

We are treating Flow as one of our products and will continuously improve and iterate on it. In these early days of the implementation we are aware of some topics which require our attention:

Handling and administrating critical issues is one of the key areas which we want to improve going forward. We currently lack a general definition of the term “critical” as well as a proper process of escalating an issue. In addition, with a new team structure and new team mandates, we’ll need to figure out who is responsible for solving a respective critical issue.

Another tricky part is that flex periods can become too busy because we tend to try to solve everything in these 2–3 weeks. This problem might dissolve itself over time since the teams get more used to the rhythm and can balance the flex weeks across several periods. We’ll keep an eye on this development.

Also, we realised that the lines between focus and flex period can be blurred sometimes. An example illustrates this best. At times single team members are blocked by other colleagues or are stuck on a task and need to work on a different topic for a day to tackle the problem from another angle. In these situations it makes perfect sense for instance to pick an issue from the tactical development backlog to ensure seamless flow and value creation. This routine has not been properly implemented yet but we are eager to improve it.

If you have comments or questions to our way of working with development, feel free to reach out! We are hiring (see vacancies), also in product management, in case you find us exciting and want to take part in future iterations!

--

--