Click here to read this mailing online.

Your email updates, powered by FeedBlitz

Click here to read this mailing online.

Here is a sample subscription for you. Click here to start your FREE subscription

"Hiring Technical People" - 5 new articles

  1. Six Tips for Interviewing Scrum Masters, Part 2
  2. Six Tips for Interviewing Scrum Masters, Part 1
  3. Creating a Succession Plan for Your Technical Team
  4. An Agile Approach From Job Offer to Start to Success
  5. Job Search Trap: I Can Network Only By Computer
  6. More Recent Articles
  7. Search Hiring Technical People
  8. Prior Mailing Archive

Six Tips for Interviewing Scrum Masters, Part 2

Now that you know what you expect from your Scrum Master’s job (the deliverables), and you know the essential and desirable skills (the first three tips), you can focus on creating the interview questions and audition. (If you have not yet read Six Tips for Interviewing Scrum Masters, Part 1 for the first three tips, please do so now.)

Tip 4: Create Behavior-Description Questions for Your Scrum Master Based on Essential Qualities, Preferences, and Non-Technical Skills

For initiative, you might ask behavior-description questions like these:

  • Give me an example of a recent time you thought the team was stuck. How did you know the team was stuck and what did you do? (You want to know if the SM was command-and-control, interfering or helpful.)
  • Tell me about a time when your Product Owner was convinced the story was as small as possible, but the story was a month long. Have you encountered something like this? (Maybe a month is longer than what the candidate encountered. Maybe it wasn’t the PO. Listen to their experience.) What happened? (Listen for what the SM did or did not do. Different Scrum Masters facilitate differently. There Is No Right Answer.)
  • Tell me about a recent time the team had many stories in progress and didn’t finish at the end of a sprint. What happened? (Listen for what the SM did or did not do. Different Scrum Masters facilitate differently. There Is No Right Answer.)

For flexibility, consider these questions:

  • What do you consider negotiable in a Scrum team? Why? Give me a recent example of that flexibility.
  • Give me an example of a time you and the team were stymied by something. What happened?
  • Have you ever needed to compromise as a Scrum Master? Tell me about it.

Again, you have to listen for the context and what the Scrum Master did in the different context for the project and the organization. There is no right answer. There are answers that don’t fit your context. Make sure you keep reading down to see my question about learning from past experiences.

For perseverance, you might like these questions:

  • Tell me about a time you advocated for something you wanted.
  • Tell me about a work obstacle you had to overcome.
  • Tell me about a time you had to maintain focus when it seemed everyone else was losing their focus.

Do you see the pattern? Apply behavior-description questions to your essential qualities, preferences and non-technical skills.

Tip 5: Create at Least One Audition Based on Deliverables

Back in Six Tips for Interviewing Scrum Masters, Part 1, I said that you needed to define deliverables. I suggested a potential list of 10 deliverables. You might have these candidate auditions:

  • Facilitate a standup
  • Facilitate a retrospective
  • Look at a Scrum board and tell you what it means
  • Look at a team’s measurements and tell you what they mean

I’m not saying these are the best auditions, because I don’t know what you need Your Scrum Master to do. These are candidate auditions. I have a lot more about how to create auditions in Hiring Geeks That Fit.

Tip 6: Ignore Certifications and Look for the Growth Mindset

I have never been a fan of certifications. If I have to choose between a candidate with a certification and a candidate with a growth mindset, I’ll select the candidate with the growth mindset. (Remember, you can buy a certification by taking a class. That’s it.) Certifications are good for learning. They are not good for helping people prove they have executed anything successfully.

When you interview for the growth mindset, you ask behavior-description questions. When they answer in a way that intrigues you, you ask, “What did you learn from that?” (a reflective hypothetical question). Then ask, “How have you put that learning into practice?” (a behavior-description question). Now, you have yourself a terrific conversation, which is the basis for a great interview.

Okay, there are my six tips for hiring a Scrum Master. If you want to understand how to hire without fear, read Hiring Geeks That Fit.


Six Tips for Interviewing Scrum Masters, Part 1

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.

Tip 1: Define Your Scrum Master’s Deliverables

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:

  1. Coach team(s). (If you want to be a great Scrum Master, look at Michael James’ Scrum Master checklist. A great Scrum Master coaches one team.)
  2. Facilitate team meetings and Scrum rituals.
  3. Ensure information radiators are up to date.
  4. Looks at the team’s process and sees if the team need other radiators.
  5. Advocates for the team.
  6. Identifies and removes team impediments.
  7. Coaches on agile practices.
  8. Helps team see what they are doing to see how they can improve.
  9. Coaches on technical practices.
  10. Helps the team become self-sufficient.

You are not going to ask questions about each of these deliverables. However, you would use these deliverables to create an audition.

Tip 2: Define Your Scrum Master’s Essential Qualities, Preferences, and Non-Technical Skills

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:

  • Initiative
  • Flexibility
  • Communications
  • Resilience
  • Determination
  • Perseverance
  • Ability to find another option
  • Recognition of management power, but not intimidated by it
  • Ability to use that power

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.

Tip 3: Define Your Scrum Master’s Essential Technical Skills

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.


Creating a Succession Plan for Your Technical Team

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?

  1. Assess the number of entry-level, mid-level, senior, and principal technical staff you have. I think of entry-level as 0-2 years, mid-level as about 2-10 years, senior as about 10-20 years, principal as about 20 years and on. Your ranges may vary. If you have narrower ranges, ask yourself why. If you start senior engineers at 5 years of experience, I want to know how the heck you can. You can call them anything you want. Are they really senior? Or, do you have title inflation?
  2. If you don’t already have one, create an expertise criteria chart. That’s a chart that shows what the criteria are for each level. Because your people might just have a year of experience every year, and not really have acquired any valuable experience. You and I both know people like that, right? Take the qualities, preferences and non-technical skills that you value the most when you hire. Explain what you want in each level, and that’s how you create an expertise criteria chart for your team.
  3. Resolve the criteria across the organization, so that your team is on par with the rest of the organization.
  4. In your one-on-ones, have a conversation with each person about their career goals and how you see their career over time. Provide feedback. If they want coaching, provide that.

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.


An Agile Approach From Job Offer to Start to Success

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.”

Hiring curve with no buddyI 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.

Hiring curve with a buddyContrast 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.)


Job Search Trap: I Can Network Only By Computer

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:

  1. Find someone to go to a meeting with. That way you have a familiar face as a backup.
  2. Decide to meet just two or three people. You do not have to meet everyone in the room. If you have an in-depth conversation with those two or three people, that might be enough. You can always meet more people. Start small.
  3. If this is a dinner meeting, sit with people you don’t know. If you are with your friend, sit at opposite sides of the table. At a table of eight, space yourselves four apart. That way, you each get to talk to a different two or three people.

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.


More Recent Articles

Click here to safely unsubscribe from "Hiring Technical People." Click here to view mailing archives, here to change your preferences, or here to subscribePrivacy