When talking about roles in an Agile team, we’re generally discouraged from making explicit roles on people, as we expect everyone to ‘be a team’ and be cross functional, t-shaped individuals (or simply, ‘team members’). We also have defined roles which are difficult to define, particularly here at Spotify, we have roles like Product Owner & Agile Coach… But what does one expect of a Product Owner? What does my team expect of me, the Agile Coach? Particularly at Spotify, we have pretty fuzzy roles because we believe that if we constrain them, we will potentially constrain our capacity to add value in our roles. That is, if I tightly define my role, then I will feel constrained by these rules and won’t think outside the box about ways I can add value to the business.
This thought process happened recently when I was planning an offsite for my Product Owner on one of my teams. I asked him what he would like to get out of the offsite and one of his responses was that he would like to know what his team expects of him. Our previous Product Owner had gone on parental leave and an engineer from the team had stepped up to take over in his place. He is new to the role and whilst he had a reasonable understanding of what he expects of himself in the role, what mattered to him was what the people around him expect. He had many questions… “Should I still be writing code? Should I be helping with code reviews? What about if I’m away from my desk for a while, what will they think?”
For me, this got me thinking about one of the biggest ideological questions that gets discussed amongst the Agile Coaches here… “Am I a member of the team?” This was a new team for me and besides the PO, no-one was really crying out for an Agile Coach… “Oh wow, what will they expect of me? Do they even want an Agile Coach?” This became a really interesting thought process. (At Spotify, teams own their own process and its up to them & the coach whether they want to work together. Some teams explicitly ask for a coach, some have someone come and help in an implicit way and others are resistant. For me, I hadn’t talked to this team about whether they want a coach or not, but I did want to help them)
So, armed with a desire to answer these questions and a pocketful of curiosity, I decided to design a workshop around answering these questions. I ensured that the team knew that this workshop was going to happen during the offsite and they had the opportunity to challenge it. I also purposefully omitted another role from the exercise, the Chapter Lead, or line manager if you will. (If you want to know more about this role, check out this article: Scaling Agile @ Spotify) I did this as there wasn’t a lot of time to do the exercise and it would have increased the time significantly, plus the CL wasn’t attending the offsite, so it felt a bit overkill. In hindsight it would have been very interesting, as the Chapter Lead role here is also extremely vague.
Expectations Workshop Guide
- Write up 3 columns / 3 rows for the 3 roles (see pic)
- Provide sticky notes, sharpies
- I provided a sample list of responsibilities to get people thinking outside the box (click here to see some examples)
- For each column, everyone writes on stickies what they expect of that role
- For the first column (PO), we start with what the team expects, then the AC, then finally the role in question, the PO. Each person(s) goes up and explains their sticky note then puts it on the wall.
- Discussion. Facilitator (myself) asks the question “How does their expectations match your reality? What is similar? What is different? Do we need to change anything about how we work?”
** Do this for each column, this took 60 mins in total (i.e. 20mins x 3 roles, you could do this with other roles too, just be conscious of the time it takes)
10 – 15mins
- Final wrap-up & discussion. What did we learn? Is there anything we’re going to do differently now? How do we feel about these expectations?
Results and Insights
First off we started with the Product Owner. The team members and I placed stickies and described what it was we expected from our product owner. (I had mine pre-written so that I could also facilitate) Finally the PO put his up. The big insight for the PO was that his team did not expect him to code and also didn’t expect him to do code reviews, but it does help out when he does. He also found that there were many stickies around stakeholder relationships & had the realisation that this is something that he needs to spend more time doing. I personally found it great that the team had a good understanding of the Product Owner role & it felt great knowing that the PO was now more empowered to truly feel purpose in his role.
Here there were some pretty obvious sticky notes like develop, system design, quality etc. What surprised me and made me smile was to see the team write stuff like “Vision, learn/improve, teach, helping each other”.
Agile Coach (yep, thats me!)
This not only blew me away, but helped me understand one of our biggest critics, which in turn contributed to a great beginning of us working together (the team & I). I honestly had no idea what they were going to write, its not often that I talk about my role & myself to the team as I’m always talking & thinking about others. (doing so almost feels kind of selfish)
So what blew me away? Seeing sticky notes like “behaviour(al) understanding”, “teach / drive soft issues” was really amazing, this is something that is not covered in your stock-standard definition of a process driver but also hugely important. Really, all of the sticky notes were great, they really summed up the sheer breadth of our role, but there were 2 rather ambiguous notes here: “Not go wild” and “Not get in the way”.
I found this interesting and took the time to discuss what this means with a member of the team. After a bit of a rant, I felt like I understood what he meant, he expected me to provide context and reasoning behind the things I do, particularly when involving their time. There have been many ‘initiatives’ or ‘workshops’ that have been pushed on him in the past with little opportunity to understand or challenge it before hand, which is frustrating. I summed this up to him to confirm that was what he was talking about and indeed it was, this was a hugely beneficial discussion and allowed me to get to know him better.
Finally, after having this discussion, I felt extremely empowered to do these things, because thats what they expect of me. I now have the confidence to do these things and not hold back and thats a great feeling.
All in all, this was a great discussion and I’m so glad I had it. (and so is the PO!) I now consider this a useful tool I can bring to a new team, or even an existing team that have a lot of implied expectations. I am especially looking forward to doing this with the Chapter Lead role (our definition of an engineering line manager).
I’m keen to hear if you feel this will work for you? Have you tried something similar? Drop a note in the comments 🙂