People want to know the “secret sauce” for hiring Scrum Masters and agile coaches. I wish it was easy to provide a standard set of questions.
Because your agile team is unique, your questions should be different. However, there are some common qualities, preferences, and non-technical skills among Scrum Masters.
First, do a job analysis for your Scrum Master. I have met teams who needed an agile project manager because no one was in the same place. I have met teams who needed an account manager, because they were consultants. I wrote about this problem in Which “Scrum Master” Are You Hiring? I also did a potential job analysis for a servant leader/Scrum Master in What Do You Look for in a Servant Leader or a Scrum Master? The chances of this being the correct job analysis for your Scrum Master are not so good, given what I see in organizations.
Since every team and organization I work with is unique, you need to do your own job analysis. You do. For the sake of argument, let’s assume the Scrum Master has these deliverables:
You are not going to ask questions about each of these deliverables. However, you would use these deliverables to create an audition.
Note that I said the essential qualities, preferences, and non-technical skills. Maybe your Scrum Master needs fewer than what I have below. Maybe you are starting a transition and your Scrum Master needs more. Maybe you need something different.
You would use the essential qualities, preferences, and non-technical skills to create behavior-description questions:
Notice that these are all interpersonal skills. A Scrum Master works with people—people in the team, people in management, people across the organization. It’s all about the people.
If you have desirable qualities, preferences, and non-technical skills, note them. If you have two candidates who are “equal,” you may decide to use the desirables to decide between the candidates.
I have trouble with with teams who need a Scrum Master who understands tools and technology. That’s missing the point of a servant leader. I understand Scrum Masters who understand the domain—that’s understanding the risks and helping management understand why they need to remove obstacles. But, if the Scrum Master is getting involved in the coding or the testing or the UX design (or whatever), the SM is not facilitating the entire team.
If you define too many technical skills, the Scrum Master is not making sure the Product Owner is available to see the team’s progress on stories. The SM is not making sure the PO is making stories small. The SM is not making sure the team is delivering something of value every single day, or more often. The SM is not helping the team review their process if the SM is doing the technical work of the team.
Be very careful if you have a SM who is a working member of the team. I say this in Hiring Geeks That Fit:
Don’t ask people—managers or not—to work at the strategic and tactical levels. No one can. The tactical, day-to-day issues win. Always. Or, the strategic work wins. But they can’t both win. Never.
A Scrum Master takes a more strategic look at the team’s work than a team member does. That’s because the SM facilitates the process. That’s by design.
Okay, I’ll post Part 2 tomorrow.
We often think about a succession plan for managers. But, if you’re not thinking about a succession plan for your technical team, you’re falling prey to local shortages, and hiring the same old kinds of people. You’re not getting diverse people. That means you may not be able to create innovative, great products. It also means your people might be stuck. As soon as they can, they might leave.
Sometimes, when I coach people on their hiring process, I discover that they have all one kind of person. Everyone has five years of experience in one domain. Or, everyone has fifteen years. Or, everyone has the same background. Everyone all looks alike. Everyone—even though they were hired at different times—has exactly the same demographics.
This is not good.
You want a mixture of experience on your team. You want some people with less experience and some people with more.
I once had a client who, through their hiring practices and attrition, ended up with people who had no less than 25 years of experience. Every single person had at least 25 years of experience in this particular domain. It was very interesting introducing change to that organization, especially to the managers. The technical staff had no problem with change. But the managers? Oh boy. They had worked in a particular way for so long they had problems thinking in any other way.
That was a problem.
It’s not that less or more experience leads to easier or more difficult change. It’s that heterogeneity in a team tends leads to more innovation and more acceptance of change.
So, what can you do to create a succession plan for your team?
Now, you have data. You have information about how people are performing against what you need. You have information about how you could “slot” people into the HR ranges, if you need to do so. And, if you need to hire people, you have the opportunity to hire people where you need to do so.
I did this when I was a manager. I needed the data to bring one person to parity. I needed the data later to bring an entire testing team to parity with the developers. This is a ton of work. You can do it. It’s worth it.
If you’re a hiring manager, you might think that once you’ve made the offer you’re home free. Not quite. Maybe you think that once your new hire starts, you’re home free. Nope.
You don’t get to see the results of your new hire until your new hire is integrated into the day-to-day work of the team. How long does that take? “It depends.”
I know, I hate it when I have to give an answer like that. Just as much as when you hear an answer like that. The problem is that when you integrate a new person into your team, everyone’s productivity goes down. Ouch.
This graphic explains what happens. Your team is running to keep up at the beginning of the hiring. That’s why you have to hire someone. They take time to interview. By the time the new hire starts, they are ragged. Now, everyone takes time to answer questions and explain how the products work and what’s going on with this project with the new hire. Oh, boy. That’s why the answer above is “It depends.”
If no one spends time with the new hire, the new person takes foreverrrr to learn how to do anything. That’s why it takes 6-9 months. Everyone else is running to keep up with all their work. It’s understandable, but it’s difficult for everyone.
Contrast that curve when you use a buddy system.
I can’t guarantee that you’ll have new hires at two or three months who will be as effective as the people who have been there for years. I only know what my experience has been.
I’ve used a buddy system for years. When I have a buddy, which looks a lot like pairing for a few weeks to a month, I can reduce the on-boarding cost substantially. My new hire is productive inside of a month, and is working like someone who’s been there for a year inside of three months.
If you swarm or pair regularly, you see this too. That’s because you’re integrating the new hire into the team from the start.
The next time you have a new hire, consider using a buddy system. Or, consider pairing, trading off who the new hire pairs with, but pairing with everyone every day. Or, transition to swarming or mobbing as a team.
(I talk about how to buddy and successfully onboard in detail in Hiring Geeks That Fit.)
I gave a talk at a networking group recently about Manage Your Job Search. When the members checked in at the beginning they gave themselves points for their activity the week before. They only got one point for applying for a job. They got 15 points for going on an informational interview, and 15 points for networking at an event.
I loved it. When they went out to meet people, they got more points. Meeting people, in person, is key to a successful job search. Why? It’s all about the loose connection.
Loose connections is how you will find people to introduce you to people who will help you meet people on your target list. Loose connections will say, “Oh, I heard about that developer job (or tester job or project manager job or engineering job or whatever job) in that company last week. Here is the name I know.”
You can search job boards. It’s difficult, time-demanding, and the job descriptions are shopping lists/laundry lists of jargon, ridiculous numbers of years of technical skills, and something masquerading as cultural fit. What passes for job descriptions these days is a horror show. The descriptions are written for the ATS, not for the people.
If you’re looking for a job, go meet people. I know this might be the hardest thing you’ve ever done, if you are a technical person. Even if you are extroverted, walking into a group of people where you don’t know anyone? Oh boy. Not the way you want to spend an evening, is it?
I have many tips about networking for shy people in Manage Your Job Search. Here are three:
If it’s not a dinner meeting, talk to someone for 5-10 minutes—enough to get to know enough about them. If the conversation lags, you can say, “Thank you, I’ll refresh my soda now.” You can get more club soda or whatever. What, you thought you would drink an alcoholic drink while you were looking for a job? Start with a clear head. At the end of the evening, feel free to indulge. This way, you always have a way to end the conversation. Because what goes in must go out, too.
Don’t sit behind your computer and network that way. Go out and meet people. Your job search will be more productive and faster because of it.