Have you ever wondered what it really means to be a leader in an agile / Scrum environment? I know I have, and It took me a while to figure out that I had a lot of room for improvement, and maybe you do too. If you have read any of the hundreds of Scrum books or blog posts out there, then you should know that your team(s) needs to be “Cross-Functional” and “Self-Organizing”. If they are, you will have implicitly let go of the reigns of control, and delegated a lot more autonomy and trusted authority to your team(s).
Let’s review this, so you can find out if you really are doing what you think you are, according to the experts like Mike Cohn, Jeff Sutherland, Ken Schwaber, and many more.
This team structure is something that I have seen many leaders and organizations struggle with. I used to wonder myself, with the transformation to cross-functional and self-organizing teams, smaller iterations, continuous deployment, etc… where does the leader fit in all of this, and not just get in the way? Once you see the “Scrum light”, you will understand that this role has drastically changed from the antiquated, but still familiar “command and control”, to more of a (here we go… the most overused phrase on LinkedIn right now) “servant leadership” role. I’m now having flashbacks of the early 2000s and the overused and worn out terms such as “synergy” and “convergence”.
So, what about the Scrum Master and Product Owner, what’s their role in all of this? A Scrum Master is the one that facilitates the process of keeping the team productive, promoting a sustainable paced work environment, and acting as the layer of abstraction between the development team and anyone else outside of that team that could cause them to slow down or lose focus. This is a cursory overview, but I’m not writing this to detail out the role of the Scrum Master. The Product Owner is someone(s) (recommended to have just 1) that will focus on the product road-map, vision, backlog, budget, and the priorities of the feature development (again cursory overview here).
The leader should focus on the strategic level, and less on the day-to-day tactics and what happens within the development team. Typically as a leader, your tasks would focus on some of the following:
- Establish or influence corporate culture
- Advocate for the team on training, resources, and more
- Simply put, trust the team to do the job you hired them to do
- Cultivate an environment that embraces calculated experimentation, and continual learning
- Partner and build alliances with other leaders and stakeholders across the organization
- Give executive level push-back when needed to protect your team
- Work with senior stakeholders on road map development
- Create strategic alliances and technology partnerships
- And more…
They should also facilitate the “what, but not the how”. This last statement is a real mind blower for some in a leadership role. Do you really want to tell someone how to do the job you hired them for? No, it spreads a culture of distrust and micro-management among other things. Instead, you should be coaching and mentoring, helping them see obstacles they may be overlooking when making decisions, and overall provide an environment of trust and respect. These leaders find themselves unknowingly too ingrained in the technical stack, architecture, etc… instead of defining the problem, objective, solution, goals, milestones, outcomes, etc.. that are essential to successful product development. The latter would then allow the team to collectively define optimal solutions, and select what it believes to be the best approach given all considerations, then evaluate and improve continuously.
Of course, there are always those leaders who manage to find time for both roles, and occasionally jump into the technological trenches, as well as fulfill leadership responsibilities. If you are one of these rarities, you definitely have the opportunity to work with the team at a more technical level and provide input, as does any other team member. I don’t see this too often, and it’s usually with smaller companies where the leadership roles have fewer responsibilities. Otherwise, there is just too much to effectively and efficiently manage, without losing respect and credibility, or suffering in other areas of responsibility. Don’t forget, if you log into the AWS console only once every 2 weeks your bound to see almost an entirely new menu of new services, or features added to existing ones. Whether it’s AWS or something else, this still applies.
Thanks for reading, and hopefully it was a useful read.