What Do You Look for in a Servant Leader or a Scrum Master?

In my article, Which “Scrum Master” Are You Hiring?, I suggested you articulate the type of leader you might be hiring. Why? You might not be hiring a “Scrum Master” at all—but you are likely hiring a servant leader. In this article, let’s discuss the kind of qualities, preferences, and non-technical skills you might need in a servant leader, your potential Scrum Master, agile project manager, potential account manager, or whatever role you need filled. Start With Qualities, Preferences, and Non-Technical Skills Your servant leader has talents that are different from the technical skills. You could lump them all into one bucket called “talents.” But I have found that not so useful. Instead, I like to differentiate those into qualities, the talents that a person exhibits that are culture-sensitive; preferences, innate behaviors that are part of a person’s personality; and non-technical skills, such as interpersonal skills that a person has acquired over the years. No matter what position this person has, let’s start with non-technical qualities, preferences, and non-technical skills. Those are the characteristics that will help a candidate succeed in the position and fit into your organization’s culture. Notice that I am not suggesting you start with a certification. Why not? While this person needs to embody agile values, principles, and of course, practices, a certification is no guarantee of that. However, the non-technical characteristics, the qualities, preferences and non-technical skills that you require in this servant leader role will help you define what you do need. We will discuss certification later. What do you need in your position? Again, it depends on the servant leader you are...

Which “Scrum Master” Are You Hiring?

Have you looked at some of the ads for Scrum Masters lately? Some ads include the need for PMPs or they say they will give you a bonus if you complete the project at a certain time or to someone’s satisfaction. Some talk about hiring the team or about managing the customer’s expectations. Some talk about setting up team members in several countries or worse, several teams in multiple countries. Some talk about significant coaching responsibilities. All these under the guise of “Scrum Master.” One thing I know is that every agile team is different, so I would expect every Scrum Master to be a little different. But that different? Clearly, the context is very different for each of these positions. That’s because although these teams are all hiring someone called a Scrum Master, they are not all hiring the same position. Just because they are all called the same thing, does not mean they are the same thing. How Did We Get Here? Hiring for technical people has always been a little confusing. We have HR people who mean well, and often don’t know a lot about technical jobs. They know that generic job descriptions work well for other roles, so they suggest to hiring managers, “Can’t you create generic job descriptions?” Hiring managers without management training think, “Gee, this HR specialist thinks this is a good idea, so it must be.” Off they go to create generic job descriptions for non-fungible people. Mistake #1. HR people also think that certifications mean something. You and I both know that even the best certifications mean that at one time...

What Traits Are Most Valuable in a Career?

If you read Thomas Friedman’s interview with Laszlo Bock, How to Get a Job at Google, Part 2, you see that these qualities are the things that Bock discusses: Grit, which I refer to as perseverance Adaptability General cognitive ability, the ability to think and solve problems How does Bock look for those skills? He looks for some form of STEM: science, technology, engineering or math degree. Not just courses, degree. Why? They show that a candidate had the perseverance to stick with a difficult undergraduate program, that the candidate has analytical ability (yes, I admit of a certain type), and you can adapt those skills to whatever job you have now. If you read the interview, you can see that liberal arts are important, but not by themselves. BTW, I have an English degree. I read Chaucer. The challenge there was not the same as designing device drivers, two things I did for my undergraduate degrees. If you already have a technical background, great. If you don’t, what now? Take classes, and more importantly, practice. Volunteer on some open source projects. Try something on your own. Go to code.org and see if you like coding. Don’t do something you don’t like. Maybe Google or a place like that is not for you. But I have to tell you, I am not doing what I started doing over 30 years ago. Even if I had continued to write code, I would not be using the same languages, solving the same kinds of problems. I would have changed domains several times over. My adaptability has been key to my career...

InfoQ Interviews Posted

While I was on vacation in early January, there were two interviews posted on InfoQ: Ben Linders interviewed Esther Derby, Don Gray, and me about the Change Artistry book. I’m really pleased about the way the interview came out. Thanks, Ben! Back at Agile 2013, Shane Hastie interviewed me. The interview is here. We spoke about many things: the dangers of multitasking, hiring, and agile program management. We had a great time. I only with you could have seen Shane on camera too. Oh...

Is Offshoring Less Expensive? Exposing Another Management Myth

I was in the midst of an assessment when the CIO came to me, and shut the door. “I have a serious question for you.” I nodded for him to continue. I put aside my papers to show him I was providing him my undivided attention. “I’m thinking of offshoring all the testers. What do you think?” “You can do that. If you do, you will take longer to get a release out the door. Since you brought me in to see why it’s taking you 18 months to get your 9-month releases out, I’m not sure it’s a wise thing to do. Why are you thinking this?” “All the other CIOs I know are doing this.” This was in 2002, just as the offshoring/outsourcing boom was starting. Agile had not yet become an accepted way of working. I had recommended working in feature teams and working in timeboxes, with small(monthly) deliverables, with people working on just one project at a time. Yes, you can see my current thinking in that report. That CIO was not alone. His management and his board was exerting tremendous financial pressure on him to reduce the cost of his projects. At the same time, they were exerting the same pressure to release faster. He was stuck between a rock and hard place. In another assessment, just a few years ago, I encountered the same situation, where senior management had made the decision to hire developers in New York City and testers in Singapore, a 13 hours time difference. I’ve met people in my teaching who have developers all over the US and testers...