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

Need to Learn More About the Work You’re Doing? Spike It!

In a recent estimation workshop, one of the participants asked, “How do we estimate something we’ve never done before?” “Is it a feature or a project?” I asked. “A feature,” she said. “How do you do things now?” Based on her previous comments in the workshop, I suspected she was pretty good at what she did. “I take a little time, do a proof of concept, and then I know how long the rest of the work will take.” That’s the general idea of a spike. You timebox a little work, do some research—just enough to know how long it will take to finish the rest of the work—and then you can estimate the rest of the work. How Does a Spike Work? I like to timebox the spike for these reasons: You don’t want this to become a research project that never ends. If you can’t gain some answer in a reasonable amount of time, that’s data, too. If you learn enough before the timebox is up, you can stop early. And you might want to explore in a different direction if you have extra time. Maybe you’ve only one tried one design and you want to try another. But that leads me to my second point about spikes. When you have multiple people work on spikes together, you have options to explore multiple designs. You don’t waste time, and you learn together. Spikes are for learning. There’s always a tradeoff between the time you spend learning and actually completing the work. The more time you spend learning, the closer you are to completing the work, so it’s...

Keys to Chartering an Agile Project

When you’re a project manager for a traditional project, it’s easy to write a project charter. You can sit in your office and write it alone, if necessary. You don’t have to involve the team. On an agile project, is that the right thing to do? Should you even use the same template? Agile projects are collaborative. You might not have an agile project manager for your team. You might have a ScrumMaster or a coach, neither of whom is a project manager. You might not have anyone who fills exactly the same role the project manager used to fill. But you still need a charter–it helps the team see the vision and the release criteria, among other potential other valuable information. How do you charter an agile project? Do you know where you’re headed? The first question I ask teams is this: Do you know where this project is headed? I don’t want to know about this iteration. The team might have an iteration goal. I want to know if they have a vision for the entire project. If you are transitioning to agile, you might have a project that has to fix some technical debt and a number of defects. Do you want to call that vision “Fix the debt project”? I don’t think so. It’s true, but it doesn’t “wow” anyone. It doesn’t explain why you are doing the project and why anyone should care about doing the project. Instead, a vision such as, “Technical debt payoff to make everyone’s lives easier by 10 hours a week” does have a wow factor. If you add a...

Management Myth 25: Performance Reviews Are Useful

Bill popped his head into Jan’s office as he was leaving for the evening. “Jan, do you have a minute? I have to do performance reviews tonight. I was going to drink Scotch and work my way through all of them.” Jan laughed and said, “Sure. Scotch might make you feel good, but it will definitely not solve your performance review problem. “Why are you still doing performance reviews? I stopped doing them. I worked with HR and convinced them performance reviews were a useless relic of the past. What do you want to get out of performance reviews?” “Me, I don’t want anything out of them. I do them for HR.” Bill was as sure of this as he was of the fact that he needed liquid courage to write them. “That’s nonsense. You have one-on-ones, right?” “Well, I mostly have them. I mostly have them every other week.” Jan gave him the what-are-you-thinking? look. “That’s a problem. If you don’t have regular one-on-ones, you can’t do performance reviews. But the problem isn’t the review. The problem is feedback and building a trusting relationship, isn’t it? She explained more. “The idea behind a performance review is that you provide feedback to your employee. Now that we are agile, do you have any idea what your people are doing on a daily basis?” “Uh, no. They work independently. Sure, if they need me, I help. But I don’t help much anymore.” “OK, so why would you do performance reviews?” “I guess I can’t,” Bill responded. “Exactly. You need the team to provide feedback to each other. Do they know...

Management Myth 26: It’s Fine to Micromanage

Sharon poked her head into Heath’s cubicle. “Hey, Heath, are you done yet with that fix?” Heath turned around. “Sharon, you asked me that less than an hour ago. I’m not done yet.” “Well, I need to know when you will be done. Oh, and I need to know if you’re using the design we discussed.” Heath started to turn red. “We didn’t discuss any design at all. You told me a design to use. Because you used that design back in the day, back when you were a developer. So you want me to use it now. Are you delegating this fix to me or not? Do you want to do it?” Damon tapped Sharon on the shoulder before she could reply. “Sharon, it sounds as if you need information. It also sounds as if Heath needs time to finish that fix. How about I help?” Sharon looked relieved. So did Heath. “That would be great,” she replied. “I have another Ops meeting in fifteen minutes where everyone is going to ask me when the fix will be done. I’d really like to know the answer.” She took off down the hall, texting on her phone as she went. Damon sat down next to Heath. “OK, tell me what’s going on. You sound as if you’re at the end of your rope.” “I know this is a critical fix. But Sharon won’t let me do my job,” Heath said. “It’s not just this fix; it’s anything. She wants to design this fix for me. She’s come over here five times this morning, and its not even noon. OK,...