In more traditional projects, the Project Management Institute has a notion that you can “control” a project. I have never found that to be true. Of course, I never quite used a waterfall approach–I have used feature-driven approaches more often than I used a serial approach.
But the idea that I could somehow control a project? I never bought that. Which brings us to the idea of what an agile project manager might do.
Here are three examples of servant leadership in action with respect to the team, the product owner and management.
Agile Project Managers Serve the Team
In agile, the project manager serves the team. The project manager might arrange for the resources a team needs, such as lab time, a team meeting room or even desks and chairs.
During one of my projects, the technical leader had a back problem. His previous manager had scrounged a desk and chair from storage. That was good because he had a place to work. It was bad because the desk and chair didn’t fit him.
I had two important jobs: find this guy a desk and chair that fit him, and aid him in helping the rest of the project team understand what he was thinking about and working on. I was afraid–as he was–that he might have to take significant time to manage his health.
It took me two weeks to convince the Furniture Police that he needed a different desk and chair. For those two weeks, I encouraged him and helped him organize what we called “technical leadership” sessions.
He explained a small area of the code to a cross-functional subset of the project team. They asked questions about how to change the code and write the tests. He then coached them for the first part of the work, and checked back later to see how they did.
This helped in a number of ways: He didn't have to sit in his office on the bad chair. He could sit in a conference room chair, which was more comfortable for him. In addition, he helped other people learn the internals of the code and the design. That made it easier for him to discuss possible architectural changes with the team members.
Agile Project Managers Serve the Product Owner
In another project, the product owner, Ben, had a difficult time creating a roadmap so the team could see ahead a little. Ben also had trouble making small enough stories so the team could complete the committed work inside the iteration.
After a couple of retrospectives, the agile project manager, Cindy, realized the product owner needed help. Ben could not solve this problem himself.
Cindy asked Ben how she could help. “I need more time to write stories. I am flat out and don’t have time to make smaller stories,” he said.
Cindy asked the team if they were willing to use the Three Amigos Strategy to help Ben create better stories. That way, even if everyone was in the story refinement meeting, they could work as sub teams, working on their own stories.
Ben agreed. Cindy organized the requirements workshop and helped the team reorganize into triads, so each team had a developer, a tester and someone acting as a product owner/business analyst.
After the first requirements workshop, Ben was surprised by how small the stories were. “I never get to this level of detail,” he said.
That next iteration, the team was able to estimate as a team and not over-commit. In the retrospective, they all agreed they would continue to work in a Three Amigos way to refine the stories just in time.
That allowed Ben to work across the organization and refine the roadmap so the team could see ahead and allow for more options in development. They didn’t need to prematurely reduce their options for ways to design the product.
Agile Project Managers Serve Management
Many managers want to know when the project will be done. In agile, we often say, “That depends. Because we limit our work in progress by either working in flow or iterations, we can be done whenever you want us to be.” While that is true, that’s not always a helpful statement to make to management.
Danny, an agile project manager, responded to his management this way, asking, “What are the minimum features you want in a release? What does success look like to you?”
He had asked those questions at the beginning of the project, and had received the answer, “We need everything. It’s not successful unless we have everything.” Danny knew that answer would change as the project proceeded and the managers could see demonstrations of the product.
Sure enough, as the managers saw the demos, they changed their mind about what the minimum releasable product was. When Danny heard, “When will the project be done?” he asked, “What is the minimum releasable product for you?”
Danny organized a meeting of all the managers who wanted to know about the end date. He asked what the minimum releasable product was.
One of the managers said, “I need what we have and these next couple of things on the roadmap. Once we have that, I want you to release. That’s enough for me, at least for now.”
Danny asked for what other people needed. They all agreed with the first manager. Danny said, “Okay, that will be release 1. Let’s talk about releases 2 and 3. Are other projects more important than release 2, or should release 2 be next?”
The managers discussed what else they wanted this team to do, and decided that release 2 was more important than anything else they had. Making release 1 an interim release would provide enough value for current customers and future customers.
Danny then worked with the product owner and the team to make sure they could finish release 1.
Agile Project Managers Serve
As you think about how agile project management differs from traditional project management, consider how you can apply servant leadership:
- What can you do to more fully serve your team?
- What can you do to better facilitate the work of others? To help develop their skills?
- How can you help product owners and management distinguish between short- and longer-term goals, and to focus accordingly?
Those are just three ways you can exercise your servant leadership.