In my first article about misconceptions about agile, I talked about learning all there is to know about ways to do agile, the value of small stories, and reranking the backlog. In this article, I have other misconceptions to banish.

1. Teams don’t need to watch their WIP

Teams who work exclusively in iterations sometimes have a ton of work in progress, or WIP.

One of my clients learned about agile by watching some videos and talking to other people. No one had taken a class or read any books.

It’s not surprising that they thought each person could take his or her own story at the start of the iteration—and that’s what they did.

In their iteration planning meeting, they assigned stories to people. Each person started on his or her own story. They thought if you had more open stories, you were making more progress.

But they encountered big problems: Some stories took more time than others. Some stories needed more than one person. And, because their stories were big, the testers had not much to do at the beginning of the iteration and too much at the end.

They had a difficult time finishing anything.

It’s easy to watch your WIP and realize if you have too many open stories at one time. You use a kanban board instead of a Scrum board inside the iteration. As a team, you track the flow of work. The team decides how much work in progress it can consider. If the team reflects periodically, say, at the end of an iteration, it can decide if the WIP is helpful or not.

The more time you spend together finishing stories, the faster you finish. But if you don’t know what WIP you have, you never consider pairing or swarming.

2. Teams don’t need to watch their cycle time

Cycle time is the time it takes to put an item on the backlog until the team releases that item for customers to use. If you don’t track this, you may not discover delays in your team or in your ability to release.

You might discover that your team has trouble finishing items. That might be because the team has too much work in progress, or it might be because some other team, such as DevOps or IT, has to release your features for you. But until you see the delays, you can’t know what they are or how to manage them.

Dennis, a manager in an organization working on their agile transition said, “I had no idea that the teams completed features—real, working features—and then we had to wait almost two months to see those features released. But once they showed me, I could solve that problem. I had to work with my counterpart in IT to understand their concerns and what the teams could do to alleviate their concerns. Once we did, we now have a delay of no more than a week. I’m working to reduce that to hours.”

3. Managers ask people to multitask instead of managing the project portfolio

Back in waterfall days, managers believed that people could cycle on or off a project. The manager could “place” that person where the person’s skills were most needed at a given time.

That wasn’t true then, but it looked like it. It definitely isn’t true if you are trying to be agile.

One of my coaching clients is having a terrible time with people multitasking on several projects. He never knows if the team will finish anything inside the iteration.

First, I suggested that regardless of the project, everyone put all their work on their backlog for the iteration. It didn’t matter what the work was; they had to see it.

He reported back to me in a week. “Putting all our work on the board was a great idea. I know who is asking people to do what. The team members realize they can’t commit to what they want to commit to; they have too much work. Our product owners realize they have to decide which project the team should work on.”

If you multitask, consider putting all your work on your board. You want to minimize multitasking—it’s the fastest way to waste time.

Multitasking also tears teams apart. You never know when people are available to work with you or answer a question. Teams need to stay together. The longer a team works together, the better it knows how to work together.

And it’s not just about the working together. When teams work together on a project, they can focus. They can reduce their work in progress. They learn—together—how to implement and test features. Everyone amplifies their learning.

When people multitask, they lose the teamwork. They lose the focus. The people who are multitasking don’t learn what the rest of the team learns. And the multitasking delays all the work that people multitask to do.

Multitasking is lose-lose.

Instead, managers have to learn to manage the project portfolio and not overcommit to work. This can be new for managers, and a cultural change for the organization.

Agile Is a Cultural Transformation, Not a Project Management Framework

Agile provides a team with transparency into its work. If you look at project data, you can see that to work in an agile way requires cultural change. Working as a team, reducing work in progress, making sure the entire feature is releaseable and gets released—all of those changes are cultural changes, not just a project management framework.

Managers who want to transition to agile need to realize that their jobs change. The teams’ job changes. That is a cultural shift.

Treating a culture shift as a new project management framework is not a recipe for success.

Managers need to nurture agile change. They need to act in a way that promotes change. Everyone needs to realize that sometimes you need to experiment to see what works in cultural change for your organization.

Do you have these misconceptions? Consider what you need to do to make your agile transition successful.