How do we structure our work?

One of our core values is ‘Passionate and Proud’. But, how does that work? What is the process prior to that proud moment? Do our developers actually get a say in the long-term vision of the product, ensuring that proud moment?

In this blog post, we want to share insights on how we structure our work, the Scrum framework, and how we deliver features we’re actually proud of.

Who better to ask about how a product gets built than a Product Owner right? We asked one of our Product Owners Medi about the way we implemented the Scrum framework, the corresponding meetings, and how the development team manages to maintain its momentum. 

Read on to find out more!

First things first: why Scrum?

Transparency is high on our wishlist when it comes to business goals. We want all the Bricks to have a say on the long-term vision for the products we work on. But, you are only able to make well-informed decisions when there is a certain amount of transparency, especially when your playing field is as complex as ours. One of our statements is ‘you are as good as your colleague’s best work’, but how can that work be good when you and your fellow Bricks are in the dark about the current status of a project?

Exactly.

This is why we work with the Scrum framework and emphasize the first two steps of the Scrum framework process when it comes to transparency:

Step 1. Inspect: With our knowledge, we establish the status of the project. (Sprint Review Meetings and Sprint Retrospective Meetings)

Step 2. Adapt: After inspecting we define the direction and next steps to get to our Sprint goal. (Sprint Planning Meetings and Backlog Refinement Meetings)

Step 3. Learn: Every day we inform each other what we work on and what holds us back or sets the wind in our sails. (Daily Scrum Meetings)

Step 4. Restart: Start over.  (We close the current sprint and start the next)

What is a Sprint?

We work with two-week cycles called ‘Sprints’. The teams are self-managing which means there’s no hierarchy within the teams and they decide individually how they work. The ‘Scrum master’ is the facilitator between the team and the Product Owner and makes sure all team members understand the Scrum methodology and can put this into practice. The Scrum Master can also be a coach that helps the teams to decide which technologies can be used to achieve the stories. Together the teams work on a project in which they have equal responsibilities and say (most of the time). The Product Owner gets to prioritize the projects together with the developers (‘Stories’) in the backlog decides which story is next in line to work on and adds these into a ‘Sprint’.

How do we plan a Sprint?

The PO (Product Owner) is the one who informs the teams on how the product could increase its value. Together with the Scrum team, he determines the Sprint goal which should reflect why this goal needs to be reached so stakeholders understand how this Sprint adds value to the product and why the stories of that particular Sprint are prioritized. Together with the PO, the developers decide which stories should be included in the Sprint to reach this goal and which stories can stay ‘on hold’ in the backlog. The work is determined together with the different teams. For Clay: DevOps, Core, IQ, Connect, Larry, Frontend/Mobile, CDP, and ACA. When an event occurs, where we need to change priorities, the Scrum master determines whether to deviate from the planning. 

Why is the Sprint a two-week cycle?

We initially started with a three-week cycle so we could comprehend unforeseen circumstances, but it turned out two weeks has a more compact scope that helps us avoid unexpected situations that force us to prioritize another story. If we would shorten the Sprint to a week the planning would be a mess: With a one-hour meeting per team, a weekly retrospective meeting, and a Sprint review meeting once a week, the Sprint would be very inefficient and nearly impossible. A two-week Sprint works best for us at this moment.

How do you prioritize your stories?

Prior to each quarter, we define our roadmap for that quarter. This is done by carefully weighting newly requested features against work that needs to be done in order to cope with the growth and demands of our customers. This is the baseline for our sprints. At the end of the day, our main concern is to deliver a high-quality product, so this is always our ‘dot on the horizon’ while determining the product roadmap.

How do you announce an upcoming Sprint to the team?

We do not announce the upcoming Sprints. During the Sprint planning meeting, the exact scope of the Sprint is defined based on the prioritized items in the backlog of the team. The Sprint starts once everyone in the team is comfortable with the established goals and feasibility. The Sprints are numbered and named sequentially. We are, however, very transparent in terms of sharing the product roadmap to our multiple teams: DevOps, CORE, IQ, Connect, Larry, Frontend/Mobile, CDP, and ACA.

What happens when a story is too large to finalize in two weeks?

That is the beauty of Scrum: It’s such a flexible framework. We define how complex a story is by determining story points. If a story can’t be completed because we underestimated the amount of work, we prioritize which story is up next. The Sprint enables us to stay as close to the story as can be. The retrospective at the end of the two weeks gives us a chance to gain insightful feedback on the process: What made us lose momentum and why? Could we’ve done something to prevent this? We also try to see what worked really well and what increased the team’s productivity.

To plan and maintain the Sprint there are some necessary meetings that need to be executed:

Daily Scrum:

Or as we like to call it the ‘stand-up’ is a meeting of 15 minutes max with the team to briefly go through the tasks of the day per person so we are all in sync with what we are working on. Fun fact: The stand-up may not be executed sitting down to ensure the meeting will be as short and efficient as possible.

Sprint review meeting:

The Sprint review meeting is a great example of why we have chosen to work with the Scrum methodology: transparency and collaboration. Two things we have high. It is an engaging moment where the engineers explain what went well, what didn't go well, and what the results were. The engineers get to demonstrate what they have worked on, what they have struggled with and give their feedback. It’s the meeting where the whole company from developers to marketing learns the most about the product and why we build it. It’s a moment where everyone gets to pitch in and get to say how they see the product going long-term and their vision for the future.

Retrospective:

A frequently hosted Agile retrospective meeting will turn a group of individuals into an effective team. After the Sprint Review, we discuss how the two-week sprint process went during the Sprint retrospective: How can we make the previous two-week process more efficient or improve our work? How are we planning to do this? What worked well in the previous Sprint?

Backlog, prospects & Sprint status:

The Scrum master, product owner, and most important stakeholders discuss the status of the stories in the backlog. What is the status of the stories and how do we prioritize them are the main bullet points of this meeting. Our Product Owners Medi, Hugo, Kosta, Simon, Milan, and Kalin are in charge of the Sprints backlog: All the projects that need to be accomplished in order of priority. In the planning meetings, the product owner defines the planning of the sprint together with the team or teams he is responsible for.

Thank you, Medi, for explaining how the development teams structure their work to deliver features and products they are proud of!

Keep an eye on the blog to read more about how we work and why. Do you have any suggestions? Head over to our contact page, Instagram or LinkedIN and let us know! 

– 

Clay Solutions - A SALTO Group company is the daughter company of SALTO Systems. A lock hardware manufacturer based in Oiartzun Spain. While Clay builds the cloud-based software that allows users to tap their locks open with their phone, SALTO provides the hardware, the locks that are enabled to communicate with the software. This website functions as a platform to showcase our company culture in our office in Amsterdam, the way we build our software, and why and who the Bricks are. Feel free to browse around, head over to SALTO to find more about the hardware, or apply if you see a job you think you are just perfect for.

We can’t wait to meet you!