I got asked earlier which role do I have when doing scrumlife. The answer is: all of them.

Scrum needs a team. Scum team, to be precise. The team includes a scrum master, a product owner and developers. Developers are the ones doing the actual building. They might be coders and testers and designers but also bakers or masons or musicians. The relevant part is that the team should include all the relevant skills needed to build the product that you are trying to complete using Scrum.

What we mean in this case by you is the product owner. Product owner maximises the value the Scrum team produces by focusing the effort using the (product goal)[https://scrumlife.fi/product-goal] and the (product backlog)[https://scrumlife.fi/backlogs-of-life]. They act as a proxy for all the stakeholders and customers and create a synthesis from all the requirements, opinions and limitations that exist about the project. Product goal and the product backlog are the results of this synthesising work.

Scrum master is the personal coach of the whole team (and the surrounding organisation). they make sure that Scrum is used well and that the team keeps improving. They do it by coaching the the team to self-manage better and better and by working to remove impediments that are outside of the things that the team can solve by themselves. Example might be working with the management to change company policies to enable the teams to focus on just one product instead of every team spreading themselves between multiple products and backlogs.

Developers do the work. They take the goals and the backlog items, make a plan based on them on how to best make the product turn into reality and then do it.

How do these work with scrumlife? What do I do or what do I think when acting as the P0, the SM or the developers?

Being the developers is pretty easy. I just do the things. In this Scrum project I actually know exactly what the product owner was thinking when he requested the thing, which makes everything easier. If I need to clarify something, it's enough to do the clarifying once. I don't need to transmit the clarified info separately from the PO to the developers.

Being the scrum master is both easy and hard. In principle I can know instantly when there's an anti-pattern anywhere but I'm also completely limited by my own ability to spot them. Keeping yourself accountable is hard, but I'm at least helped by writing this blog. Being transparent to the outside world helps you to catch situations that you aren't completely sure about. If you don't want to write about it, it's a sure sign that scrum master's help is required somewhere nearby. In practice I try to self-coach and teach myself to be better at Scrum every day: read more, think about routines and structures and have discussions (with other people too!) about Scrum and agility in general.

Product owner role is the hardest one. I have never been naturally great at setting goals about life. I just like to stumble to the general direction of good things. In that sense doing this project is great practise for me.

As PO I actually have to think what I want to achieve and where I want to end up at. I did this earlier and found a pretty exciting way to form a product goal. I'm pretty happy with the goal I set, but finding the most effective ways to reach it is a weekly challenge. In practise I just take time to work on my goals every once in a while. I look at my product goal and my backlog in my to-do system and add in new stuff, remove old ones and refine the ones that can be somehow refined and made more actionable. (Note for myself: write a separate post about backlog refinement soon!)

The most interesting observation has been to see how the product owner and the rest of the team "interact". The PO would love to see much more progress every week: more backlog items done, more things achieved. On the other hand the developers and the scrum master know there are hand limits on how much "we" can do per week. It's interesting to feel a bit disappointed when some things I picked for the sprint are left undone and at the same time being very confident that it was the right call to not try to force something to happen that obviously was too much to fit into this sprint.

It's another example of how Scrum helps me to keep the pace sustainable and to give more power to the scrum master and developer side of my personality.

Another great and unexpected benefit. Scrum is great!