Debate #20 – What are the official roles in Agile?

Your job title may be…

So, does this mean you don’t have a place on an Agile team? No – many or all these skills may be necessary. Keep in mind that it’s not about job titles in Agile; it’s more about skills and capabilities. 

Official Scrum Accountabilities (formerly Roles)

There might be a slight variation of the names of roles in different Agile frameworks. Still, if you’re looking at the most prevalent (Scrum), there are only three defined accountabilities (previously known as roles). They are: 

1. Product Owner
2. Scrum Master
3. Developers

(NOTE: I won’t go into the details of the Product Owner or Scrum Master accountabilities in this blog – that would require two more blogs) 

I’m a… Developer (?)

So, if you’re not the Product Owner or Scrum Master, that makes you… what? You guessed it: A Developer. In the previous version of the Scrum Guide, the developers comprised a separate Development Team. However, in the updated version from 2020, the developers are no longer on a different team – they’re all part of the same single Scrum Team. Win as a team, lose as a team. 

Cross-Functional Skills

An Agile team should have all the necessary cross-functional skills to create a done increment at the end of each sprint or iteration. The point is that it doesn’t matter what your job title is. Not having a fancy job title can be challenging to adjust to if you’ve worked hard to climb the corporate ladder, but you need to check your ego at the door if you want to be part of a successful Scrum Team.  

Develop More Skills

Most people have a core capability or strength around which they have built their careers. But a lot of folks also have interests in other areas and exhibit something called T-shaped learning. T-shaped learning means that the person learns other complementary skills that enhance their primary talents.  

I highly recommend that you stretch yourself to learn new things that will make you a more valuable member of your Scrum Team. Do this by volunteering to take on tasks that you might not usually have signed up for — shadow someone else on the team to learn something new. Read books: tinker and experiment. The broader your knowledge is, the more helpful you will be to your team. 

Final Thoughts

This blog is the last one in the series, and like all good things, it must come to an end. I hope you have enjoyed the various topics of debate regarding Agile. If there are any topics you think I missed or would like to debate further with me, drop me a line below! Thank you for reading, and I look forward to hearing from you. 

If you missed any of the other blogs in this series, check them out here: 

1. Can you use a Sprint 0 in Agile?
2. Do you need Documentation in Agile?
3. Is there a “right” way to write User Stories?
4. What’s the best way to write Acceptance Criteria?
5. How long should your Agile sprints be?
6. Should all your Agile teams be run the “same” way?
7. Which “flavor” of Agile is best?
8. Can Agile co-exist with Waterfall?
9. Story Size – What’s an Epic, Theme, Feature…?
10. Can the Scrum Master be a team member, too?
11. Can distributed Agile teams work?
12. How should you estimate in Scrum & Agile?
13. Is it OK to add items to the current Sprint?
14. How should you manage your Agile backlog?
15. Can an Agile team have more than one Product?
16. What is the optimal size for Agile teams?
17. Should Agile teams stay together?
18. How should you handle defects in Agile?
19. Can a hybrid of Waterfall and Agile succeed?
20. What are the official roles on an Agile Team?