Customize Your Agile Approach: What Kinds of Leadership Does Your Project Need?

Team A was new to the organization. They had each worked--with various levels of success -- in agile teams before, but they were new here. Their management assigned them several leaders:  a Scrum Master to facilitate their process, a project manager to report status to the management, a technical coach to help them learn how to use TDD and BDD, and an interpersonal coach to help them learn how to talk with each other.

That lasted about a week. That’s when the team said, “Thank you, and no thank you,” to all the people who supposedly were helping them. This team felt micromanaged and wanted to understand what they needed for their team’s leadership. They didn’t need micromanagement and inflicted help from all these supposed leaders.

This is the fourth in a series of articles that will help you think about how you might want to customize your agile approach for your context. This article is about the kind of leadership your project might need and who might provide it.

Leaders Serve the Team

Part of the problem is that Team A’s appointed leaders didn’t serve the team. Management thought agile teams needed all these appointed leaders to help the team succeed.

It was clear to the team members that the managers didn’t understand agile approaches or have agile experience. The managers thought the team could provide the same artifacts as they had in the past, even though things like Gantt charts for an agile project made no sense.

The team did have trouble with their initial attempt at an agile approach: their stories were too large; they didn’t reach done on the stories every time; the testers were overloaded with too much work late in their iteration. They needed some time to understand what was happening in their team and they needed to keep management off their backs. They decided they would ask for an agile project manager. They used that term “agile project manager,” on purpose.

Danny, a senior developer said, “Our management understands that project managers help a team succeed. We think they might understand that agile in front of project manager means that we need someone with a different perspective. When we did that, we got the kind of person we needed. We got someone to help us visualize and facilitate our process. We got someone who could help remove our impediments. And, we got someone who could help us gather our data and prepare it for the management meetings.”

The team members used Danny’s manager, the development manager, to help them create a job description and work with HR. The team insisted on interviewing all the candidates themselves. To do so, they created interview questions that they thought would help them discover whether candidates were right for the role.

Since the organization was in the midst of an agile transformation, many people changed their titles and how they worked. The development manager, while not an agile expert, was savvy about the way the organization worked. He helped the team find exactly the right person, Jenny, to help them succeed. Jenny had several years of agile project experience in using both flow and iterations, so she was ideal for this role.

Kent Keith, in The Case for Servant Leadership, says servant leaders follow these seven practices:

1. They are self-aware.
2. They listen.
3. They serve the people who work "for" them (Keith calls this "changing the pyramid").
4. They help other people grow.
5. They coach people, not control them.
6. They unleash the energy and intelligence of others.
7. They work to develop their foresight so they can act, not react.

Team A needed a servant leader to help them learn how to use an agile approach that would work here, and deliver on a regular basis. They expected Jenny to help them do so.

Jenny decided to serve the team first by facilitating a retrospective with the team. During the action planning, she asked the team members to decide on only three actions for the next time period. The team decided to use these actions:

1. Create a board that reflected their reality, not what people thought their board should look like. (See  Customize Your Agile Approach: Select Your Agile Approach That Fits Your Context for more details.)
2. They would count stories, and see if they could finish--really complete--four stories in the next two weeks. (See Customize Your Agile Approach: Start with Results You Want.)
3. Measure their cycle time to see how long their stories really took. (See Customize Your Agile Approach: What Do You Need for Estimation?)

The team decided to stick with their two-week iteration so they wouldn’t change everything all at once. Jenny agreed with that decision. She was concerned that changing three things might be too many, but she thought these three might work.

During the first week, the team moved from a three-state board: Ready, In Progress, Done to a five-state board: Ready, In Dev, Waiting for Test, In Test, Done. That helped the team see where the work might be stuck.

Jenny noticed something strange about this board. The team had decided to see if they could complete four stories in two weeks. And, there were already six stories on this board. She asked the team why they had six stories when they were supposed to finish four.

Tracy, the tester, said, “I asked the team and we agreed. I’m still finishing the work I didn’t do from the last iteration.”
Jenny asked the Product Owner if he wanted Tracy and the team to complete that work or to see if the team should just start and finish four stories. He said he wanted the four stories, and to not worry about the unfinished work. Tracy removed the card from the board.

Now they had five cards on the board, one already In Dev. Danny, a developer, asked, “I bet you don’t want me to finish this story either?” The PO said no, and Danny removed the card. Now, the team was down to four stories.

That made more sense to Jenny. She asked the Product Owner, “Are these stories in your rank order?”
He said they were.

“Good. Now, how do you want to start the first story?” Jenny asked the team.

Danny asked, “All of us were accustomed to take our own stories before. That’s probably not going to work now. Do you have suggestions for alternative ways of working?”

Jenny said, “I can provide you suggestions, but you folks are smart and have worked on this product longer than I have. Why don’t you take five minutes, bat it around, and then see if you need my suggestions?”

The team discussed their options. They already knew about pairing and swarming. They also knew that they could spike a story as a team and see if the story was more complex than they thought.

They decided what they could do in about three minutes. Danny said, “Okay. Here’s how we’re going to split up our five developers and one tester. We’re going to have three developers work on Story 1 as a swarm, and ask Tracy to start developing automated tests for this story. I guess that means that four of us will swarm on Story 1.”

Jenny nodded her head. “Okay, sounds good. For your swarm, how often will you check in with each other?”

Danny said, “We like checking in every hour.”

Jenny said, “Okay. Is it alright with you if I listen in? That way, if you have impediments, I can help resolve them.”

Danny looked at the team members who nodded. He said, “Sure.  And, the other two developers will work on Story 2.”

“Okay,” Jenny said. “I’ll work with the PO on making smaller stories for the next iteration and discussing the ranking of the work.”

“So you think this will work?” Danny asked.

“I don’t know. You folks sound as if it’s going to work. Why don’t we see where we are for each hour and see if you can finish a story in two or so days? That way you can also measure your cycle time.” Jenny said.

The four team members checked in with each other every hour. Things appeared to proceed fine until the middle of the second day. The team had more than four cards on the board. Jenny wasn’t sure who had added them or how the cards got there.

Agile Projects Need Project Management

Let’s look at what Jenny did. She helped the team visualize their workflow and a little about how they worked as a team. She listened to the team. She coached the team as a team and individuals. She served the team.

Jenny facilitated the team to manage their project themselves. This team is now a self-directed team, on its way to a self-organizing team. They might need more coaching to become a self-organizing team, but they are on their way.

Jenny’s motto is this:

Every project needs project management. Not every project needs a project manager.

Because Jenny wasn’t invested in the project manager part of her role, she could help the team discover their own project management.

The team thought they could finish a story every two to three days, which is why they thought they could complete four stories in an iteration. After three days, their board looked like this:

Jenny was concerned. How could a board that started with four cards be at six cards on the third day and no card was In System Test or Done? She needed to understand what the team had done.

The team was swarming, so they didn’t use standups. She decided to ask the team members if they could discuss the board over a lean coffee. She suggested they try timeboxing the lean coffee to 45 minutes and see what happens.

She opened the lean coffee explaining she had several questions to discuss. She suspected other people had questions, too. She wrote her first question on the flip chart, “Why are there six cards on the board?” She had other questions, but decided she would start there. The team members wrote other questions on the flip chart, such as “When will we get to System Test?” The team had started as a unified team, but it didn’t seem as if they were a unified team right now.

At the end of five minutes of brainstorming, they dot-voted on the rank order of the questions. Luckily, Jenny’s question, “Why are there six cards on the board?” had the most dots, so they could discuss that question first.

Danny started to explain. They had discovered that the first story was not a three-day story, but a much larger story. They worked on it in two parts. The first part was in Waiting for System Test and the second part was still In Dev. The other story that the other two people had started was still In Dev, also.

Jenny asked, “That makes sense. Thanks for explaining. Now, why do we have a story in Waiting for System Test as opposed to In System Test?”

Tracy answered, “We’re helping clarify the first story and the second story. We thought it would be more useful if we all understood this new story and the second story before we started to test.”

Jenny said, “I can see where you would think that. I might think that, too. I’m going to put you on the spot a little.” She smiled. “Why didn’t you ask the PO and me to help you with the stories? We would be happy to do so. I could learn this part of the system if I help. And, the PO could learn a ton if he understood what was large or small about his stories.”

Tracy frowned. Then, she said, “I didn’t think of that.” She turned to the rest of the team. “Did any of you?”

Everyone shook their heads no.

“Oh,” Jenny said. “The PO needs feedback on the stories and the story size as much as you need feedback on how you’ve implemented the stories. That’s the double-loop learning part.”

Jenny drew her double loop learning image so the team could discuss it.

© Johanna Rothman from Create Your Successful Agile Project

When Danny saw the image, he said, “Oh, so if I have an assumption about the design or the architecture, and I create a plan based on those assumptions, I can share my assumptions as much as I can share the plan with everyone. Then we can all check the plan, adjust it and refine the assumptions, and replan and keep going, right?”

“Yes, exactly!” Jenny said. “That’s how you show people what you’re thinking. That’s one of the reasons I wanted you all to manage your WIP (Work in Progress) so you could keep only a few assumptions in your heads and then work to resolve them.”

The team discussed this for their timebox. Then it was onto the next item on the list.

They finished their lean coffee with several more action items:

1. Start with a system test on this story so they could move it to done.
2. Actively explain any code or test designs for a few minutes to bring people into the loop to be able to plan as a team, check and adjust as a team, and refine their assumptions as they proceeded.
3. If they wanted to refine a story, they would ask the PO to join them for the refinement.
4. They would consider WIP limits for the next meeting, in two days. They wanted to see what they could complete before the next meeting.

Now, the team was able to finish a story and measure their cycle time.

Leaders Help the Team Learn

As the week proceeded, Jenny noticed the team having more whiteboard meetings. They already knew to timebox those meetings. Their guideline was “10 minutes at the board and then we move to code and tests.”

Danny and Tracy weren’t the only ones at the whiteboard. The entire team took turns leading their discussions.

Jenny asked if she could sit in on their discussions. They agreed that she could. One of her favorite discussions occurred when a junior developer explained to Danny several alternatives for a tricky part of the performance work. A less-experienced tester jumped up and pointed to several key areas and said, “This is a loophole. I saw this at my old job, and here’s how we fixed it.”

Danny and Tracy sat back and listened as the other team members discussed the problems and potential solutions.

At the end of the meeting, Jenny asked Danny and Tracy, “Do you have a minute? I’d like to discuss something with you.”

The two of them looked at each other and shrugged. “Okay,” Danny said.

Jenny led them to a small conference room, closed the door and smiled. “You two did a terrific job as leaders, just now.”

Danny asked, “What did we do? We didn’t say anything.”

“Exactly!” Jenny said. “You listened. You helped unleash everyone’s energy when you stayed quiet. You knew you don’t have to have all the ideas. You helped other people explain their point of view. I was quite impressed.”

Tracy said, “If we always tell everyone everything, we don’t learn and they don’t learn.”

Danny said, “Uh, thanks. I still think it’s a challenge to know how much to tell and how much to hold back.”

“Yup, it is,” Jenny said. “It’s worth it, though. Even if you have to say, ‘I don’t know how much to tell you and how much to let you explore…’ Sometimes, I say that to all of you. You acted as project leaders. That’s what we need, to have everyone act as a leader.”

Leaders Protect the Team

In the next iteration, Tracy came to Jenny and said, “I need to take a few days to help another team.”

Jenny said, “Who is asking you to do this?”

Tracy said, “My manager.”

“Okay, here’s what you do. Stay on this project. I will go talk to your manager right now and explain why you can’t come off this project and multitask. I will take the heat for this.”

Tracy said, “Are you sure?”

“Oh yes,” Jenny said. “I am very sure.”

Jenny met with Tracy’s manager and explained the difference between resource efficiency and flow efficiency, the cost of delay due to multitasking, and the fact that this project was a higher rank than the other project.

Then, she worked with the manager to find an alternative to the manager’s problem that did not require Tracy to move to another project.

Treat People Like Adults

This team took several more iterations to understand how to create small stories, work together, and manage their WIP. They measured their actual cycle time which ranged from two to five days per story.

Jenny offered suggestions, some of which the team took, and some of which the team ignored, and some of which they improved.

Jenny used servant leadership approaches with the team, primarily trusting people to do their jobs. Agile teams who have an agile mindset and a reasonable environment don’t need a lot of management. They might need a project facilitator. They might need coaching. They might need to learn how to learn together. And, they might well need someone to protect the team so they can continue working together.

I hope you consider the kind of management your team needs and doesn’t need. Agile teams don’t need micromanagement. They might need coaching. Often, teams new to agile or new to an organization need facilitation so they can create their own agile approach that works. Especially if the managers are new to agile, the team might need someone to protect the team.

The more your leaders (in the team and outside the team) treat people like adults, the more success the team will have, creating their successful agile project.

About the Author

Johanna Rothman, known as the “Pragmatic Manager,” provides frank advice for your tough problems. She helps leaders and teams see problems and resolve risks and manage their product development. Rothman is the author of more than ten books, including: Create Your Successful Agile Project: Collaborate, Measure, Estimate, Deliver, Agile and Lean Program Management: Scaling Collaboration Across the Organization, Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects, 2nd ed., See more of Rothman’s writing at jrothman.com.