There’s a Gap in Your Agile Methodology No One Talks About

Agile methodologies rock at outlining process and mechanics. We learn the rules, the ceremonies, and the boxes we need to check to obtain a predictable, repeatable process. Additionally, many Agile methodologies these days (and the Xtreme Programming methodology in the old days) emphasize the technical practices required to inject and fuel agility within your codebase.

One thing, however, is glaringly missing, and nobody really seems to want to talk about it. That’s right; it’s the product piece. When we say, “product piece,” let’s consider that to be the secret sauce of figuring out where to invest, what to build, and how to discover, deliver, and learn incrementally by validating product in the market.

Questions organizations should be asking themselves

Agile methodologies don’t deny the need for these activities, but when it comes down to the brass tacks of how we go about doing the work, questions like the ones below are left unanswered or bring copious amounts of handwaving:

• How does our corporate strategy and product vision translate into a product roadmap?
• How do we ensure the product backlog maps to our product roadmap rather than becoming an overgrown, ‘to do’ list for the dev team(s)?
• How is this magical product backlog created?
• Where do stories come from?
• How do we keep customer problems and needs in the forefront while we break work down?

Aren’t we there yet?

Wait, but Scrum gave us the product backlog – you know, that single, prioritized list of stuff we can do. It also gave us the product owner – the all-knowing “voice of the customer,” who gets to write epics and stories and order them. Heck, the output of a sprint is even a “product increment.” There is indeed a product piece somewhere in there.

Wait again. SAFe is even more sophisticated. Now, we have stories, features, capabilities, and epics. We get to break down and plan work into both Program Increments (PI) and Sprints. There’s even more product in there, right?

And what about Lean Startup? Isn’t it the ultimate in product thinking as we seek to identify and to release an MVP as soon as possible for the purposes of validation and learning?

The ‘what to do’ vs. ‘how to do’

Yes, however (and here’s where I struggled for so many years) these Agile methodologies all tell us what to do, but not so much how to do it. Have any of you product people had your bosses tell you one of these (I sure did):

• “I need three sprints of backlog by Thursday.”
• “Just break the epics into features; PI planning is next week.”
• “Make these stories smaller; they don’t fit in the sprint.”
• “Just write the stories; why is this so hard?”

So, we go about our business of creating and breaking down the backlog as best we can. As a young product owner trying to navigate this, I first went back to the tech and broke down the work as a developer would into technical tasks. My stories fit into a sprint, but at the end of the day, they didn’t necessarily build up to the product idea or deliver on the promise we made to our customers.

Later, I learned to take more of a top-down approach but still struggled with the gap of getting from idea to epics to stories. My epics became large file folders of CRUD. We never seemed to finish an epic, and epics often represented a large vertical slice of the user experience as opposed to representing a path through the experience that delivered incremental value to the customer.

The scariest part was the product story was getting lost in this mess of the backlog. At the story level things became so fragmented that neither the team nor the leaders could tell what we were building anymore. It was as if we opened a Lego box, poured all the pieces on the table, and told people it was a space ship, but they couldn’t see the spaceship. They only saw the pieces.

We’re getting there….

For years I wondered why the answers to my questions are so elusive. I don’t think it is because they are hard or that we don’t know them as an industry. I think it is because process pundits and agile coaches typically come from the engineering and delivery side of the house. This wasn’t their job and often wasn’t their main concern. It also, admittedly, wasn’t the most important or highest priority thing; that is until now.

If you think about the first decade of the 2000s, the agile movement gave us tremendous advancements in terms of process maturity. We learned to work and to deliver in iterations. Then, as we advanced from there, we focused on progress. How can we turn the crank faster? We became more efficient and optimized our agile processes to get the most from the machine.

Now that we can consider delivery to be constant and understood, is the time to turn our attention to answering the question, “Are we building the right thing?” To do that, we need to get past the handwaving and into the how.

There is a better way to understand and tell the product story. There is a better way to create roadmaps, backlogs, and stories. We won’t necessarily find that way in the pages of our methodology’s documentation, but we can certainly fit it into whatever methodology our company has chosen. In the end our process will be stronger, and more importantly, our product will be too.

Tune in next time as we transition from the “what?” into the “how?” for creating backlogs and later managing backlogs.