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.
User Comments
Yes, the confusion that Agile = Scrum is a big problem for Agilie adoption in large organizations. These organizations often bring in Agile coaches, and require that they be CSMs. Yet I have found that for a traditional organization, Scrum is often not a good starting point - it is an endpoint. Rather than disrupt teams by telling them to start using an entirely new process overnight, I prefer to talk them through gradual modifications to their existing process, to make it more and more Agile - guided by the Agile Manifesto.
It is also true that backlog items need to be granular enough to move them around, and the Product Owner needs to be responsible for that - throwing a backlog at a team once a quarter and saying "do that" is little better than the traditional up front requirements document.
HI Cliff,
Yes, I see people use Scrum as a starting point. They are not able to manage the cultural changes needed.
Hehe, yes, I had not thought of the quarter-long "requirements" as almost equivalent to a requirements document. You are correct!
Being able to come up with appropriate-sized user stories in advance is not easy. I'm a tester and when I end up writing two test cases for one user story, I know that we should have split it into two stories. Great article! It inspired me to hang a copy of the Agile Manifesto and the 12 principles over my desk at work.
HI Dave, my guideline is no more than three acceptance criteria for a story. Even that might be too big. I like your idea of two test cases might mean you should have split the story. (Sorry I just replied now. I didn't see your comment earlier. Astonished me!)
Love it!
I remember you suggesting I write something similar and now I don't have to! Thanks
I think sometimes people get confused in the other direction too, so many options: David says this, but Jeff says that, and Jim, well he says something else completely! Agile requires thinking and some of that thinking involves make sense of sometimes competing advice from gurus.
Allan,
Well, I would love an article from you, with your perspective :-)
Yes, not all advice is applicable to all teams. (Makes me nuts when people say there is "One Right Way.")
Hi Johanna, this is a great article, thanks.
I'm going to make a couple of points that some will interpret as being in favour of traditional development. First is that there is a natural bias in favour of creating a framework, and it comes down to not wanting to rework things to fit into an architecture after the event. The fact that doing a couple of small features first can give guidance on what that framework might need to be is a big change from more traditional approaches. People don't want to throw work away, and they don't realise they probably will have to (despite Fred Brooks advice "plan to throw one away, you will anyway").
Second is that the problem with requirements documents is not that they exist, anybody who develops a system that needs to exist and be maintained for a long time needs to produce a requirements document as part of development (see Parnas and Clements famous "Fake It" paper), it is that the traditional approach says you need to create a complete specification before you start. (Actually, very few approaches ever really said that, but, hey, it's a great straw man.) There is nothing wrong with developing the requirements document in an agile manner, along with the product. That way, it matches the current state of the product, including what is currently in progress.
HI Keith,
Yes, we do love our frameworks, don't we? (I include myself in this category.) When I was a developer, I was constantly surprised by the fact that what I thought was going to be the right architecture/design turned out to be insufficient partway through the project. I thought it was just me. After 2 or 3 projects like this, I provided my managers with "designs," and I told them I needed to implement some feature to make sure my designs were right. (I was not smart enough to implement by value; I implemented by risk.) That worked better for me. I threw less away.
I do love developing the requirements doc as we proceed. Many people feel uncomfortable with that. That's why I now use an agile roadmap (a picture of deliverables, by month and quarter) so people can see what we want. Because a roadmap is a wishlist, we can update the roadmap as we proceed, and fill in the details in the form of stories as we proceed. For me, that's a win-win. It might not work for everyone.
"I was not smart enough to implement by value; I implemented by risk."
Ha! Me, too. I did my own variation of Spiral. Actually thought I invented the term in the early 1990s until I kept hearing about this guy Boehm and his Spiral Model. Turns out he did a paper in 1988, before I was drawing spirals and explaining how I attacked risk. My spirals went inward to a target, though. Point is, I was like you and worried about risk, not value. I assume the folks asking for XYZ had a good reason and knew what they were doing.
Paul, I grinned when I read your comment. I also thought the folks asking for XYZ had a good reason. The problem was they asked for XYZ and not x0, x1, x2, x3, y1, y2, y3, z0, z1, z2, etc. They wanted it "all." Now when I work with teams who use agile approaches, I find that when they ask about all the pieces of XYZ, the PO realizes she doesn't need it "all" right now. x0, x2 and y3 are the first increments of value. If the team wants to learn about z2 because that will help them provide feedback about risk, the PO can decide what to do with that information.
Agile approaches help people realize what they are asking for and what they need to know. When we used spiral approaches way back when we got feedback and we realized more about the value. Same thing with incremental approaches.