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

One Experimental Possibility: Self-Organization from Component Teams to Feature Teams

If you are organized as platform team, middleware, and front-end teams, you have a  component team organization. That made sense at one point in your history. But if you are transitioning to agile or have transitioned, and if you want to use agile on a program, that might not make much sense now. If you have a program,  you  have many people in your teams. Your platform team might not be 7 people, but several teams, maybe 50 people, if you are large enough for a program. Your middleware teams could be another 100 people, and your front-end teams could be another 100 people. You have lots of people and lots of teams. I bet you do not have an even ratio of platform, middleware, and front-end teams. You have experts, here, there, and everywhere. And, if you are anything like my clients, you have trouble releasing features in an agile program. What are the problems? You have experts embedded in a wide variety of teams The experts need to multitask to serve a variety of projects, so you incur a cost of delay to multitasking and queues You are not releasing features. You have trouble when the components come together. Even if the teams are agile, your program, the collection of projects is not agile. What can you do? You can ask the organization to try this as an experiment, for no longer than 2 weeks: The only measure of success is running tested features. And, no one, especially no manager, gets to compare teams. This is an experiment that the organization is going to learn from. Some teams...

Capacity Planning and the Project Portfolio

I was problem-solving with a potential client the other day. They want to manage their project portfolio. They use Jira, so they think they can see everything everyone is doing. (I’m a little skeptical, but, okay.) They want to know how much the teams can do, so they can do capacity planning based on what the teams can do. (Red flag #1) The worst part? They don’t have feature teams. They have component teams: front end, middleware, back end. You might, too. (Red flag #2) Problem #1: They have a very large program, not a series of unrelated projects. They also have projects. Problem #2: They want to use capacity planning, instead of flowing work through teams. They are setting themselves up to optimize at the lowest level, instead of optimizing at the highest level of the organization. If you read Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects, you understand this problem. A program is a strategic collection of projects where the business value of the all of the projects is greater than any one of the projects itself. Each project has value. Yes. But all together, the program, has much more value. You have to consider the program has a whole. Don’t Predict the Project Portfolio Based on Capacity If you are considering doing capacity planning on what the teams can do based on their estimation or previous capacity, don’t do it. First, you can’t possibly know based on previous data. Why? Because the teams are interconnected in interesting ways. When you have component teams, not feature teams, their interdependencies are significant and unpredictable....

Deliver What the Business Needs Using Agile and Lean Project Management

Workshop: Deliver What the Business Needs Using Agile and Lean Project Management Workshop Objective: After this interactive and experiential workshop, you will be able to work together as a team toward a common goal, steering toward a successful conclusion as you learn new information. You will learn how to deliver a product, using agile and/or lean as your approach. Workshop Overview: This interactive and experiential workshop teaches you how to envision the project goal and develop a path toward delivering it. You will learn how to start with a roadmap, elaborate that into a product backlog, break the work down into small observable slices at appropriate times. You will learn how to get these to done and measure progress in an to ensure delivery. You will learn about the ways to limit work in progress: agile and lean, when each is useful, and how to combine them so you can deliver your work regularly. You’ll have a chance to practice on several projects, to see how agile and lean can work for you. We’ll discuss what and how to measure. And, because so few projects proceed according to plan, we will address how to replan when you know more. This is an experiential workshop. We will work on your projects and implement your features. Target Audience: Project managers, program managers, functional managers, technical leads, product owners, project staff. Prerequisites: Experience on a project. Workshop Duration: 2 or 3 days. We address the outline based on the number of days you decide. Workshop Outline Introduction Do a short simulation to level-set everyone  Define agile and lean Explain why agile and...