Trust, Accountability, and Where Does the Time Go?

As more of my clients transition to agile, many of them have a fascinating question: How do I assess who is doing what on my team? When I ask why they want to know, they say it’s all related to reviews, rewards, and general compensation. They are still discussing individual compensation, not team compensation. When I ask why they want to reward individuals instead of the team, they say, “I am sure some people do more work than others. I want to reward them, and not the other people.” Interesting idea. And, wrong for agile teams. Also wrong for any innovation or learning that you want to happen as a team (regardless of whether you are agile or not). Agile is a team-based approach to work. Why would you want to reward some people more than others? If the team is not sure that they are working well together, they need to learn to provide each other feedback. If the team doesn’t know how to manage team membership, a manager can facilitate that membership discussion and problem-solving. Then, the managers can transition team membership issues to the team, with manager as backup/facilitator. What I see is that the managers want to control team membership. Instead, why not let the team control its membership? I often see that the managers want to control feedback: who provides it and who receives it. Instead, why not train everyone in how to provide and receive feedback? When managers want to reward some people more than others, they imply that some people are less capable than others—something agile is supposed to fix with teamwork....

How Do You Serve Your Organization?

A recent coaching client was concerned about the progress his team was making—or really, the lack of progress his team was making. We spoke about the obstacles he had noticed. “The team doesn’t have time to write automated tests. As soon as they finish developing or testing a feature, people get yanked to another project.” “Are people, developers and testers, working together on features?” I wanted to know. “No, first a developer works on a feature for a few days, then a tester takes it. We don’t have enough testers to pair them with developers. What would a tester do for three or four days, while a developer worked on a story?” “So, to your managers, it looks as if the testers are hanging around, waiting on developers, right?” I wanted to make sure I understood at least one of his problems. “Yes, that’s exactly the problem! But the testers aren’t hanging around. They’re still working on test automation for stories we said were done. We have more technical debt than ever.” He actually moaned. “Would you like some ideas? It sounds as if you are out of ideas here.” I checked with him. “Yes, I would!” He sounded grateful. These were the ideas I suggested: Don’t mark stories as done, unless they really are done, including all the automated tests. You might need a kanban board instead of a Scrum board, to show your workflow to yourselves, inside the team. Work as developer-tester pairs, or even better, developer-developer-tester triads. Or, add even more developers, so you have enough developers to complete a story in a day or so. When the developers...

Do You Encourage People to Bring You Problems?

One of the familiar tensions in management is how you encourage or discourage people from bringing you problems. One of my clients had a favorite saying, “Don’t bring me problems. Bring me solutions.” I could see the problems that saying caused in the organization. He prevented people from bringing him problems until the problems were enormous. He didn’t realize that his belief that he was helping people solve their own problems was the cause of these huge problems. How could I help? I’d only been a consultant for a couple of years. I’d been a manager for several years, and a program manager and project manager for several years before that. I could see the system. This senior manager wasn’t really my client. I was consulting to a project manager, who reported to him, but not him. His belief system was the root cause of many of the problems. What could I do? I tried coaching my project manager, about what to say to his boss. That had some effect, but didn’t work well. My client, the project manager, was so dejected going into the conversation that the conversation was dead before it started. I needed to talk to the manager myself. I thought about this first. I figured I would only get one shot before I was out on my ear. I wasn’t worried about finding more consulting—but I really wanted to help this client. Everyone was suffering. I asked for a one-on-one with the senior manager. I explained that I wanted to discuss the project, and that the project manager was fine with this meeting. I had...

I'm a Management Expert on Twitter

I’ve just been named to one of the 100 top management experts on Twitter. See Keeping Up with #Management:100 Experts on Twitter. You have to page down under “Executive Coaching” to see me. I’ll return to editing my “Design Your Agile Project” series now. It needs serious editing. That’s why you haven’t seen the next post...

Public Workshops March 17, 18, 21, 2014 in London

I’m offering three public workshops this spring in London again. Monday March 17, I’ll lead an Introduction to Agile Project Management. If you are wondering, “Does my company think I’m an agile project manager?” or “What is this agile project stuff?” or “Why is my responsibility as a product owner to get the project to done?” or “Why does my company think a Scrum Master is supposed to drive the project to completion?” or if you have a geographically distributed project team and your company says, “let’s go agile,” and you want an introduction, this workshop is for you. You will learn enough about agile to know what questions to ask your team: Can we work in timeboxes or flow? How do we start if we don’t have all the requirements? How do we start delivering features, not architecture or frameworks? What are our impediments to thinking about transitioning to agile? What do our customers really want first: release date, feature set, low defects, and how can we tell? (This is from Manage It! Your Guide to Modern, Pragmatic Project Management) How do we work with product management/product owners? How do we move from silos to cross-functional teams? And much more It’s an experiential workshop. That means we work by simulation and debrief. It’s fun to work that way, and you will learn a lot. This page has the details about Introduction to Agile Project Management. Tuesday, March 18, I’m offering my Coaching Master class. If you have been a technical leader, a manager, an agile coach, or even worked on an agile team, you have coached people. And,...