Often these days you see a job posting looking specifically for a SCRUM master. Even more frequently companies are facing a situation where they would like to move to Agile with their existing team – without hiring a new person to take the SCRUM master role. The suspects are usually Project Managers, Product Owners (Managers), Functional Managers, or Team Leads.
Agile theory frowns on Product Owners becoming SCRUM masters. Project Managers are ok according to Agile (as they would lose their job otherwise). The last two roles are a bit more interesting, Agile is good with someone combining managerial and SCRUM master responsibilities as long as they are able to do both effectively. Recently I have added SCRUM mastery to my role, some of my lessons from the last 6 months are covered in this post.
What is the first rule of combining two duties effectively? – Making sure the responsibilities of the two are not in conflict, this is why Product Managers are not good SCRUM masters – the constant internal struggle for completing an effective sprint and adding more stuff would drive anyone to a nut house. With functional managers it is not as extreme, but it is not all that clean either. Let’s take a look at the Principles behind the Agile Manifesto to see why:
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity–the art of maximizing the amount of work not done–is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
In my opinion, a potential functional manager/scum master needs to pay a particular attention to 5, 11 and 12. Our job as managers could be interpreted as precisely that – MANAGING – telling people what to do and how to do it. I am not talking about micro managing, even regular “good” managers are expected to make a lot of decisions both by their superiors and the people who report to them. Your superiors might be looking to you to pick the best technology for the company, coordinate development with two internal and one external team as well show them the latest features that were implemented; while your reports could be expecting you to assign them their next task or decide if we are going with v1.2 or v1.3 of a particular library.
Now, Monday morning we are starting SCRUM and all of a sudden the self organizing the team is expected to make many of these decisions, and you are expected to sit idly by and let them shoot themselves by making their own choices! Sorry, got carried away with the exclamation mark. Chances are you have a good team, and they are quite capable and probably better than you at making these choices. What is not so straightforward is how to actually get people to make the choices – previously it was your job and your team might not be comfortable making these decisions just because SCRUM says so.
Why, do you ask, are they not comfortable and why are you not talking about principle 12, having mentioned it 2 paragraphs ago. I have not talked about 12 because (besides being not a very good writer) I was waiting to say – “You are still their manager” – which also answers why people are not comfortable. The situation is such that – you are sitting there in your nice SCRUM master chair, watching everyone making decisions, discussing their achievements and mistakes, while you are deciding on the size of their raise (or the date of their dismissal). Again – maybe not so, but why should anyone think that this is not the case?
So we basically need to get the team comfortable with making decisions and talking while not thinking of their SCRUM master as their manager. I think the approach here should consist of two actions. The first is to tell the team exactly what you will not be doing, no need for for anyone to remember what SCRUM says, repeat that you are no longer responsible for deciding A, the team needs to pick how A will happen and you will happily accept the decision. The second is base all the promotion, bonus, etc. decisions on criteria that does not get affected by anyone doing something stupid/wrong/unexpected during a sprint and then openly talking about it during a retrospective and you finding out. My preference is to base the evaluation on what other people on the team think, this way the SCRUM master is just another member of the team and not the spying manager. The conflict of interest for a functional manager exists, but it is more subtle than for a PO, it is based on perception of the team itself. Successfully implementing the approach in this paragraph should go a long way towards reducing this perception.
My SCRUM master experience has been mostly positive thus far. I did end up making a lot fewer decisions and being much happier for it. At the same time I don’t think the role took too much away from my Development Manager responsibilities. There is still plenty to be done in this role as well, even when working under Agile. I’ll leave this for another post.