April 15, 2015

I signed up for Agile, but it sure feels like waterfall. What can the Product Owner do about it?

Written by Dr. Kuryan Thomas

As I mentioned in the introductory post in this series, an issue I frequently see with underperforming Agile teams is that work always spills over from one iteration into the next. Nothing ever seems to finish, and the project feels like a waterfall project that’s adopted a few Agile ceremonies. Without completed tasks at iteration planning meetings (IPMs), there’s nothing to demo, and the feedback loop that’s absolutely fundamental to any Agile methodology is interrupted. Rather than actual product feedback, IPMs become status meetings.

In this post, let’s look at how a Product Owner can help ensure that tasks can be completed within an iteration. As a developer myself, I’m focusing on the things that make life easier for the development team. Of course, there’s a lot more to being a good Product Owner, and I encourage you to consider taking a Scrum Product Owner training class (CC Pace offers an excellent one).

First and foremost, be willing to compromise and prioritize. An anti-pattern I observe on some underperforming teams is a Product Owner who’s asked to prioritize stories and replies, “Everything is important. I need everything.” I advise such teams that when you ask for all or nothing, you will never get all; you will always get nothing. So don’t ask for “all or nothing”, which is what a Product Owner is saying when they say everything has a high priority.

As a Product Owner, understand two serious implications of saying that every task has a high priority.

  1. You are saying that everything has an equal priority. In other words, to the developer team, saying that everything has a high priority is indistinguishable from saying that everything has medium or indeed low priority. The point of priority isn’t to motivate or scare the developers, it’s to allow them to choose between tasks when time is pressing. You’re basically leaving the choice up to the developer team, which is probably not what you had in mind.
  2. You’re really delegating your job to the developer team, and that isn’t fair. You’re the Product Owner for a reason: the ultimate success of the product depends on you, and you need to make some hard choices to ensure success. You know which bits of the system have the most business value. The developers signed on to deliver functionality, not to make decisions about business value. That’s your responsibility, and it’s one of the most important responsibilities on the entire team.

The consequence of “everything has a high priority” is that the developers have no way to break epic stories down into smaller stories that fit within an iteration. Everything ends up as an epic, and the developer team tends to focus on one epic after another, attempting to deliver complete epics before moving on to the next. It’s almost certain that no epic can be completed in one 2-week iteration, and so work keeps on spilling over to the next iteration and the next and the next.

Second, work with the developer team to find out how much of each story can be delivered in an iteration. Keep in mind that “delivered” means that you should be able to observe and participate in a demo of the story at the end of the iteration. Not a “prototype”, but working software that you can observe. Encourage the developers to suggest reduced functionality that would allow the story to fit in an iteration. For example, how about dealing only with “happy path” scenarios – no errors, no exceptions? Deal with those edge cases in a later iteration. At all costs, move towards a scenario where fully functional (that is, actually working) software is favored over fully featured software. Show the team that you’re willing to work with the evolutionary and incremental approach that Agile demands.

Third, be wary of stories that are all about technical infrastructure rather than business value. Sure, the development team very often need to attend to purely technical issues, but ask how each such story adds business value. You are entitled to a response that convinces you of the business need to spend time on the infrastructure stories.

At the end of a successful IPM, you as the Product Owner should have:

  • Seen some working software – remember, fully functional but perhaps not fully featured
  • Offered the developer team your feedback on what you saw
  • Worked with the developer team to have another set of stories, each of which is deliverable within one iteration
  • Prioritized those stories into High, Medium, and Low buckets, with the mutual understanding  that nobody will work on a medium story if there are high stories remaining, and nobody will work on low stories if there are medium stories remaining
  • A clear understanding of why any technical infrastructure stories are required, and what business problem will be addressed by such stories

Finally, make yourself available for quick decisions during the iteration. No plan survives its first encounter with reality. There will always be questions and problems the developers need to talk to you about. Be available to talk to them, face to face, or with an interactive medium like instant messaging or video chat. Be prepared to make decisions…

Developer: “Sorry, I know we said we could get this story done this iteration, but blahblah happened and…”

You: “OK, how much can you get done?”

Developer: “We would have to leave out the blahblah.”

You: “Fine, go ahead.” (Or, “No, I need that, what else can we defer?”)

Be decisive.

Next post, I’ll talk about what developers should concentrate on to make sure some functionality is delivered in each iteration.

Leave a Comment

2 Responses to “I signed up for Agile, but it sure feels like waterfall. What can the Product Owner do about it?”

  1. S Baranwal says:

    Dr. Thomas, this has been a very though provoking read and I could feel myself nodding my head in agreement throughout. I do however would like to add one thing to the overall responsibilities of the PO. That would be to provide a high level understanding of the business value of the story being implemented to the development team. In my experience, it adds a flavor of ownership towards the business goal more than just a bunch of deployables at the end of sprint. Knowing that the alert on error for a data processing task means that the end user may have a chance to an efficient processing of his/her data and thereby improving his experience of the system (and in the health insurance world, possibly a positive impact to his life) is a big morale boost that is the side affect of an accomplishment in another human’s life.
    Many a times, the technical aspects of the development de-humanizes the effort and that makes it nothing more than nuts and bolts under the hood of fancy system.

    Secondly, the POs (and the devs) need to understand that though the sizing of stories is an evolving effort, it needs to be practiced with utmost discipline to keep a consistent velocity measure from one sprint to the other. The biggest variable in a sprint team is the human mind that acts differently under different external stimuli. Hence it is utmost important to keep this variable as stable as possible with allowing the sprint team to form a brotherhood of sorts to balance out each other’s weaknesses. This also works in smaller groups so every effort must be made to keep team size under 7.

    That said, it was very refreshing to know there are other people who have experienced the agile waterfall and are learning ways to counter the tendency of putting one step after other.

    Pardon my forwardness in sending this comment.
    Sharad

  2. Kuryan Thomas says:

    Sharad,

    Thanks for the comment, and yes – I couldn’t agree more with you.

    I see a lot of dysfunctional teams try out “team building” exercises like bowling or karaoke. They’re usually unsuccessful in repairing the dysfunctions. While such activities can help cement bonds in well-functioning teams, I truly believe that the shared vision and sense of common cause you describe, form the bases of true team bonding. The PO is absolutely vital to creating this “sense of mission”. We often kick off projects with a vision meeting in which everyone is told why this project will make a difference to its ultimate users.

    On your second point, developer teams should be coached or trained in effective estimation. I agree with you: if points do not reflect a consistent level of effort from one iteration to the next, then it becomes impossible to measure the increase in velocity (acceleration, if you will) of the team as it becomes more efficient.

    I’m also thrilled to hear you speak of teams as groups of people who balance out each other’s weaknesses. I’ve always taken this approach to building teams. Hiring Agile team members should be a lot more thoughtful than simply looking for specific technical skills.

    Thanks again for your insights.