Four Tips for Managing Performance in Agile Teams

I’ve been talking with clients recently about their managers’ and HR’s transition to agile. I hear this common question: “How do we manage performance of the people on our agile teams?” Reframe “manage performance” to “career development.” People on agile teams don’t need a manager to manage their performance. If they are retrospecting at reasonable intervals, they will inspect-and-adapt to work better together. Well, they will if managers don’t interfere with their work by creating experts or moving people off project teams. The manager creates a trusting relationship with each person on the team. That means having a one-on-one weekly or bi-weekly with each person. At the one-on-one, the manager provides tips for feedback and offers coaching.  (If the person needs it or wants it from the manager.) The person might want to know where else he or she can receive coaching. The manager removes obstacles if the person has them. They discuss career development. When managers discuss career development, each person needs to see an accurate view of the value they bring to the organization. That means each person has to know how to give and receive feedback. They each have to know how to ask for and accept coaching. The manager provides meta-feedback and meta-coaching. If you, as a manager, meet with each person at least once every two weeks, no problem is a problem for too long. The people in the team have another person to discuss issues with. The manager sees the system and can change it to help the people on the team. Now, what does this mean for raises? I like to separate the...

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

Scaling Agile? Think Out, Not Up

I taught the Influential Agile Leader workshop with Gil Broza last week in Edinburgh. (That’s why I was quiet. I was traveling and teaching. No time for writing, blogging or tweeting.) One of the participants asked me what I thought about scaling agile. Before I could explain about small-world networks, not hierarchies, he said, “I am sure the way you scale agile is out, not up. Well, blow me over with a feather. He said it more simply than I did. If you look at my picture of a technical program team, you can see that’s how it works. The technical program team has feature teams alone, if they can be alone. Joe, Tim, and Henry all have stand-alone feature teams. If they need to be “collected” because they work on related features, they collect themselves. Sally has collected feature teams. The teams scale out, at the technical level, not up. The technical program team does not have to get to bigger. When I ran programs in the past, I emailed the program team meeting agenda (it was a problem solving meeting) to everyone, and say, “Here are the people I need to attend. Everyone else: let me know if you are attending.” Now, there’s a limit to how big a program can get for the software program or the hardware program. At some point, the it’s so hard to coordinate the interdependencies, it’s not worth the bigness. If the teams are delivering small features all the time, you don’t need as many people as you think you do. The smaller the batch size, the fewer the people required....

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