A couple of days ago Gojko Adjic made an awesome comment about Agile. He says,
Before complaining that Agile/Scrum/whatever is dead, consider instead that it's become a norm. It's just in the background. It's no longer innovative, exciting, worthy of keynote talks or passionate meetups. The revolution happened, succeeded and passed.
Now this was in response to the posts/articles that he was seeing with captions like “agile is dead”. However, I feel that these statements are true otherwise as well. Agile is no longer innovative as it was when the Manifesto was established. Teams are not evolving beyond the laid out frameworks or methods. They are not uncovering better ways to deliver software/products. In my experience, I have seen the frameworks, methods become practices to be followed only to showcase a client that the team is doing agile. I once worked for a customer, who had outsourced their software development to 3 different vendors. One vendor was doing only coding, the other was testing and the third vendor was doing deployments. And each of these vendors had “scrum” teams or rather in the words of Michael Kusters “scream” teams.
In Scrum’s perspective, it is the job of the Scrum Master to make the Scrum Teams effective. The big question that I have for Scrum Masters is what are they doing to make their Scrum Teams effective? And if they are not, then are they still relevant?
I ask this questions in my PSM I and PSM-A classes, the most common answers that I receive include but are not limited to:
- I schedule and facilitate team meetings aka planning, review, retrospective, daily scrum.
- I manage the jira board.
- I create reports needed by the management team.
- I capture the MoM for events and maintain.
- I highlight the dependencies and risks at Scrum of Scrums.
- I work with the Software Lead to estimate User Stories.
- I provide and take status updates.
- I do the capacity planning i.e. keep track of the holidays and leaves of team members.
- I assign work to developers.
- I am involved in appraisal discussions of developers.
And then comes the follow up question - what about product development/improving engineering practices/product management? Mostly, the answer is silence or team lead takes care of engineering practices/product owner will manage the product.
So is the Scrum Master role still relevant?
When Scrum Master uses Scrum as a toolkit and focuses too much on the practices that are not even part of Scrum, they become ineffective. Along with this, when Scrum Master starts creating boundaries around what they would do and what they would not; they start promoting the silo culture. This becomes the real problem. The person responsible for improving the effectiveness of Scrum Team, is unaware about their job and many times lacks the skills needed to do so.
In such scenarios the obvious question that comes - Is the Scrum Master role still relevant if they are not helping the teams to become effective? The answer will mostly be NO. And probably the reason why we see a downward trend in open positions for Scrum Masters.
How do you make the Scrum Master relevant?
This question in my humble opinion was answered many years ago when Lyssa Adkins and Michael Spayd came up with the “Agile Coaching Competency Framework”. The framework highlights the various aspects which can help a Scrum Master to remain relevant for their teams. They should dive deeper into it and explore various skills that will help them to become effective themselves and allow them to help their teams.
In my another article, I already have highlighted the areas that a Scrum Master may focus on improving the effectiveness of Scrum Team. Here I want to explore two important aspects from the Agile Coaching Competency Framework that would help the Scrum Master stay relevant.
Technical Mastery:
From my personal experience as a Scrum Master, I can say that a Scrum Master typically spends 80% of their time/capacity with Developers. When these people are having technical conversations and the Scrum Master sits there as they have no clue what’s going on, then it reflects poorly on the abilities of the Scrum Master. Sometimes it might also create an environment of distrust between the developers and the Scrum Master; wherein the developers may completely disconnect the Scrum Master from team discussions.
Acquiring Technical Mastery does not necessarily mean hands-on coding. It is more about having the right understanding of software craftsmanship. Gaining knowledge about the necessary aspects of software development such as “clean code”, “SOLID principles”, “test driven design”, “pair programming” and others would enable the Scrum Master to have meaningful conversations with the developers that can lead them on a journey of engineering excellence.
Technical mastery is more about helping the developers envision what all they can do as individuals and as a team to create a software product that can be considered an epitome of quality and not just a combination of random features.
Business/Product Mastery:
Product Owner is a business oriented role and in order to support Product Owner in their job to maximize value of Product; the Scrum Master will have to explore areas of Product Management and Business Management. I am not hinting that the Scrum Master has to go and get an MBA or some course in Product Leadership (although if it helps, why not). All I am saying is, to improve the effectiveness of the Product Owner, the Scrum Master should deeply understand the work of the Product Owner and assist them as and when required or requested.
The Scrum Master may start very small by understanding concepts like writing better requirements or splitting them into smaller granular byte sized chunks. Product Backlog Refinement could be a very good starting point which the Scrum Master can facilitate and lead the Scrum Team to have well understood Product Backlog Items.
Scrum Master can also start learning about other concepts from the day-to-day life of the Product Owner such as
- Stakeholder Engagement
- User/Market Research
- Competitor Analysis
- Identifying and Understanding User Personas
- Learning how to create Product Roadmaps
- Approaches to create Business Strategy
- Pricing Strategies
- Measuring what matters to the end users i.e Value
- And beyond.
Having such knowledge will make the Scrum Master an indispensable ally to the Product Owner and improve the relevance of the Scrum Master in the Scrum Team.
Conclusion:
If we have to really showcase the value of using Scrum to our management then it is imperative that the teams evolve beyond just the mechanics of Scrum. They need to continuously find ways to innovate themselves to create valuable products. And if the Scrum Master has to stay relevant in the Scrum Team then they also need to upskill/reskill themselves. They need to grow beyond the obvious areas of facilitation and administrative work (that they are stuck with) and start exploring the realms of technical and business expertise.