Joining a company without a Scrum Master
I'm soon going to start as Scrum Master at a company, where they consider themselves to be working to Scrum, but they don't currently have anyone in the Scrum Master role.
I don't want to get in to a discussion about the company, but from preliminary discussions I've had, it seems that there is an intent to do well, and a foundation of teams trying to work in a Scrum way. From what I've heard during my interviews, I think it's close to (but not exactly) what is defined in the Scrum Guide.
I think it would be good to have a session with each of the teams (there are 3), to see what they think Scrum is, and what they expect a Scrum Master to do.
I am planning to ask everyone to jot down their thoughts (I'll join in), so that we can then discuss the differences.
I expect this will help me understand where to focus my efforts, and what the existing expectations are; so I would like to do this fairly early on (perhaps during the first week).
Does anyone have experience of performing a similar or alternative exercise when joining a team/organization?
I'd welcome any advice you're willing to share.
How involved are senior management in sponsoring and improving agile practice across their organization? For example was the MD or CEO keen to engage with you, as a prospective agile change agent, during the interview process?
Even though the first sprints will be revealing, the sooner the SM detects problems or areas of improvement, the better.
I think it would be good to have a session with each of the teams (there are 3), to see what they think Scrum is, and what they expect a Scrum Master to do.
I think so too. I will even use the scrum guide to go over the important rules, artifacts, events, etc. I don't mean going deep into the scrum theory but touching on topics in a very quick/interactive way, then stopping on the areas where discussion/questions/conversation arise. You may even provoke reaction asking questions like "Ok, this is how planning is done. Do you guys do it this way? Why not?" or (after explaining the scrum retrospective) "Do you have some list of improvements yet from previous sprints? Why?" and the like. Stop where conversation occurs and ask back if needed. You'll inmediatly know if you hit the bull's eye and, if too much discussion is generated, I'll consider asking them to work in pairs to analize the topic briefly. Keep an eye on the meeting timebox however.
Other powerful questions are "How scrum has helped you so far", "Why do you think scrum is the solution for you?", "Where have you noticed that scrum hasn't helped you with your work?", "Have you ever abandoned scrum for a while? like there was no time left for events or similar?", "What are your biggests frustrations in your work? is scrum helping?" "At what level of scrum do you think you are?","Any areas where you have missed a scrum master's aid?" "Why do you think that a scrum master (me) is going to help you?"...
I'd try to get advantage of them from the beginning. It is easier to set several nice key practices from the very first minute than maybe following development of the team on a daily basis, and also sets a precedent on you as a scrum master willing to change things up for the sake of productivity, agility and teamwork. Another nice technique might be to have the team mapping themselves against the 12 agile principles over time (Example) (or whatever measures you wanna focus on)
On the other hand, I'd also keep a keen eye on the company. The three scrum teams could be the best scrum teams ever but they'll need the support of the company as well. Most of the impediments may come from other people in the company who are not doing real agile. One way to foster relationships with them is to take advantage of presentations. Two quick questions may assess whether this person understand agility or not. Do not battle them at that point, just sense them as a first contact and then prepare for a future conversation. (For further study read battle mappings)
Hope you the best, and please, keep us informed of your findings!
Well, if they have teams that are already productive and both happy and making the organisation happy, I would be careful with introducing change, just for the sake of pure Scrum. If the company suddenly employs a SM, what is the rationale? What is the goal? I do not believe it is to make Scrum purer... So I agree with you, maybe it would make sense to actually focus on this discussion with the teams.
How involved are senior management in sponsoring and improving agile practice across their organization? For example was the MD or CEO keen to engage with you, as a prospective agile change agent, during the interview process?
True to form, that's a good challenge, Ian.
I'll decline to answer, because this is my future employer, and I'm not sure how sensitive it would be to have that sort of discussion in public. However you have helped me consider some of the conversations I should have with management, so thanks!
Other powerful questions are "How scrum has helped you so far", "Why do you think scrum is the solution for you?", "Where have you noticed that scrum hasn't helped you with your work?", "Have you ever abandoned scrum for a while? like there was no time left for events or similar?", "What are your biggests frustrations in your work? is scrum helping?" "At what level of scrum do you think you are?","Any areas where you have missed a scrum master's aid?" "Why do you think that a scrum master (me) is going to help you?"...
Those are some helpful questions, Juan; and some good tips in general. I'm not sure whether it will be helpful to base my early conversations with the teams around the contents of the Scrum Guide or agile manifesto. In the past, I've found it can be disruptive or uninspiring if done in the wrong way or at the wrong time; but I may try that approach in response to specific issues as they become apparent.
If the company suddenly employs a SM, what is the rationale? What is the goal? I do not believe it is to make Scrum purer...
Filip, indeed, that's how I see it. It will be interesting to find out the opinions of my colleagues.
Without knowing much more than you are saying you may be going down a rabbit hole.
I have been there done that where a CTO interviewed me saying yea we are "agile" and once I started I had to have a sit down with him.
I went the route of asking how this was mandated, communicated, and what was the training before I got there. It was a real mess, but I got it turned around.
Maybe you can to once you figure out the eco system and what you are dealing with.
Good luck.
I would focus on the rest of the Scrum framework. The Development team, Product Owner and then management buy in. One of the biggest concern for me is how organizations think just one of the three equally important roles of scrum framework can make scrum happen. They often ignore the importance of a self organized Scrum development team that understand Scrum and a seasoned Product Owner. I would convince the management the importance and necessity for the following
1) Deep rooted understanding of scrum principles in the team (look for certified scrum development team members for any future hires). Consider and value the ramp up time spent by you and the team in the agile exercises to cover this knowledge gap. Many times management assumes presence of scrum master will immediately produce change without considering the time it takes for a team to mature and accept the new Scrum Master and the principles and rules he introduces to the team (2-3 sprints is my experience)
2) Product owner should be certified and/or willing to spend time with you to learn the scrum rules of engagement. Either ways you will be spending a lot of time to coach and introduce him to the team and his responsibilities. Many organizations do not give importance or care to learn what Product Owner responsibilities are. Make sure they won't think a SM is all it takes to make scrum happen!
3) Management should not take it lightly when you bring up concerns regarding the team working environment, collocated teams, time zones, interference from existing anti agile patterns etc.
I usually mention them in the interview itself so that there is no surprise when I join. It allows a fair idea of what to expect from each party and helps for a smooth transition.