Noice Ways of Working

At Noice, we prioritize agility and team ownership in our development process. Our Head of Production, Eero P?yry , is here to share how our approach to work has evolved. Spoiler: We moved to a POD model recently. What, why and how is that? We go into some detail in this post.

Eero, can you tell us about the development process and principles that guide Noice?

Sure! We follow a minimalist, agile development process and prioritize team ownership for their work. We invest time in continuously improving our methods, focusing on enhancing asynchronous collaboration and fostering transparency across the company in communication and development. While these principles are not new or unique, they are still highly valuable. Many companies claim to implement some – or all of them. I have applied to at least one of them in the past five companies I've worked for.

However, the key to success is not just in the principles themselves but in how they are implemented.

What does this mean in practice at Noice?

A prime example of our continuous improvement approach is our ways of working. To constantly improve, we must be willing to embrace change and let go of practices we may be attached to in favour of potentially better methods. We must also be open to reverting these changes if they prove ineffective.

For most of 2022, we worked with temporary feature teams. We identified the need for them roughly when the team grew too big to act as a single team. We would set up a temporary feature team once we had a good enough idea of the scope and functionality of the feature. Who would join the team depended on who was free from each discipline and who was most interested in it. Developers and designers would focus on this one feature until it was completed.?

After that, we’d break up the team, and the people would form a new team for the next feature. Sometimes the same groups would continue together, but we were not pushing for that. The system was flexible and enabled a good amount of variety for the work. Developers and designers got to work on different areas of the product, which was good in many ways.

What steps did you take to improve the process of working with temporary feature teams?

While working with the temporary feature teams, we kept the principle of continuous improvement in mind and adjusted the process multiple times on the fly. Some examples are:

1. We noticed that starting the feature teams tended to be a bit clumsy, so we devised a minimal kick-off process to start the work.
2. We noticed that we repeated some of the same mistakes across different teams. To fix this, we started having feature retrospectives at the end of the development of a feature and sharing the learnings across the company.?

When I say “we discovered”, I am referring to the team. Practically all adjustments to the process emerged from the team members. Although pre-existing processes were available for most of our needs, we opted for a very light approach and addressed problems as they arose. Even if reinventing the wheel is a potential downside of this approach, it did have a significant upside.

We needed to have a culture where we discuss and adjust the process together. That way, it became ours.

What led to the decision to transition from a temporary feature team system to a POD model, and how does the POD model address the challenges faced with the previous system?

As we approach the launch of Noice in 2023, we noticed that the temporary feature team system is no longer serving us in an ideal manner. Breaking up the teams when a feature is completed does not create longer-term ownership for a team over the customer problem we are trying to solve. As a solution, we are transitioning to a POD model where teams are more stable and focus on a particular area of the product, hence the word ‘pod’. We are letting go of some of the variety in work and simultaneously creating a longer-term focus.

We have only been working with PODs for a few weeks, so it is too early to determine their success. Transitions are never easy, and some friction is inevitable. Despite this, I am confident that we will make it work, not because the POD model is superior but because our team has learned to own the process, try new things, and adjust on the fly.

If you're interested in learning more about our implementation of the POD model or the insights and discoveries we'll uncover along the way, please let us know in the comments.

And, if you want to have a role in shaping Noice and its processes, check out our open jobs , including the Engineering Lead position we just opened last week!