Many teams think they're agile. They might work in iterations and have a ranked backlog, but they don’t see the value they could be seeing. Usually that means they have a number of false impressions about agile. Read on to have three common misconceptions debunked and to learn what you need to do to make your agile transition successful.
In my work, I meet many people who want to go agile, or think they already have.
They might work in iterations. They might have a ranked backlog. But they don’t see the value they could be seeing from their agile transition.
They have a number of misconceptions about agile or how to be agile. Here are three of the common misconceptions I have seen.
1. People think Scrum is equivalent to agile
Have you ever heard the term “agile/Scrum”? I have. The people who use that term don’t understand that agile represents the principles behind the manifesto and that Scrum is a project management framework designed to instantiate those values.
I spoke with a potential client who talked about “agile/Scrum.” I asked him what he meant by that term.
“Scrum is the way you do agile, right?”
“It’s one way. It’s not the only way. You have many other options beside Scrum,” I added.
He didn’t realize that and was quite surprised.
I explained that the Extreme Programming practices made Scrum work. I suggested that if his team has too much work in progress, they can use a kanban board inside their iterations.
He stopped me there. “Wait a minute. How many ways are there to do agile?”
“As many ways as there are teams. As long as the team works according to the principles of the Agile Manifesto, it doesn’t matter.”
“Oh. Where can I find this manifesto?”
It’s OK to start ignorant of what the agile terms mean and where you can find them. But as an organizational leader, you need to know your options. He decided he had some learning to do.
If you are one of those people who thinks Scrum is the same as agile, you might be surprised to learn about lean and Extreme Programming. The roots of Scrum are actually in lean, and if you use the Extreme Programming practices, you will discover that your Scrum projects proceed better.
We all need to learn everything we can about the ways we want to work.
2. Teams can’t find the small value to produce something useful every day or two
I meet many teams who complete one story—or maybe two—per iteration. That’s terrible, because if you become stuck, you can’t recover easily. The longer it is between finished stories, the less involved your customer or product owner is with your team. You don’t receive feedback on your work. It’s too easy for the team to think they are doing the right thing. Instead, they hear, “You gave me what I asked for, but it’s not what I need.”
Sometimes, that occurs because your features are too big. Sometimes it occurs because people are stuck in the thought that they need “frameworks before features.” If they can get the framework right, then they have a place to hang features. It’s actually easier to implement several features before you decide on a framework or two. That way you get feedback faster, and it’s clear what your framework needs to be.
But this problem isn’t limited to technical thinkers.
During a recent product ownership workshop, one of the product owners said, “I can’t take the time to break a feature down. Besides, the team needs to create the framework first.”
We discussed the feature, and I asked, “What about just doing login for the main product, before you do all the other parts of login? Would that be a small feature?”
One of the team members replied, “Sure, we could finish that in a day.”
I was elated. “That’s your small feature. After you get that done, you take all the alternative paths and do them, one at a time.”
The product owner looked dismayed. “I’ll have to write all those stories. I don’t have time.”
“The team can help you write the stories. And if you don’t have the time, that’s an obstacle someone has to remove,” I explained. “You need to produce something small each day or every other day.”
“Ooh,” the entire team said in unison.
Taking the time to write the features small enough for a team to finish in a day or so can challenge the best product owners. But the nice thing about agile is that you don’t have to write huge requirements documents. Because you’re not writing them, you have to spend the time discussing or writing small stories. You’ve traded off one huge task for many smaller tasks.
Once you make the mind shift to small chunks of work, you won’t go back to large chunks of work.
3. People don’t replan often enough for the product backlog
The product backlog is a document always in progress. As the product owner sees completed features, the product owner can update the product backlog. The iteration backlog is what you fix for the duration of the iteration.
That means if the iteration is too long, the product owners want to mess with the iteration backlog. If the stories or features are too large, it’s difficult for the product owner to see progress.
Instead, assume the product backlog will change each iteration. That helps the team get to done on each feature.
I worked with a client who had a quarterly backlog. The product owners defined what they wanted in a quarter. The teams took that information and decided on their own backlogs for each two-week iteration.
However, because the product owners had only planned in large features, the teams had trouble breaking the features down into small enough chunks. Worse, the teams worked on whatever they thought was the highest rank. Sometimes they were right, but more often, they were wrong.
That’s because the organization’s priorities for the product shifted over the quarter, and shifted based on what the teams completed.
In agile, we want change.
If you have an agile roadmap where you don’t have to make all the features small, you can see where the product is headed. If you then take a month’s or so features and make stories, you can guide the development more easily.
When a team finishes a two-week iteration, you have the option to ask them to continue on not-yet-completed features. Or you have the option to say, “I don’t want to do more in that area. Yes, I know that feature is incomplete. Either back it out or mask it, please.”
You can focus the team on completing work that is most valuable, not just completing work because they hadn’t quite finished it in the previous iteration.
Agile Is All about Change
Agile works because we finish work, get feedback, and have change. If you know about agile approaches, keep your stories small, and replan the backlog, you can be agile—even if it’s not part of a named project management framework.
Do what you need to do to make your agile transition successful.