Possible, Valuable, Viable




my office wall

 

The wall above my desk is plastered with artifacts that help keep me grounded in product development principles, including the Scaled Agile Framework (SAFe) Big Picture, the Agile Manifesto (including the principles), and a to-do list from the inception of our Agile adoption.  I’m going to use those three particular artifacts to explain how we arrived at the practice of “possible/valuable/viable” being critical to our success.

The To-Do List

Agile Adoption To Do

In early 2011 we adopted Agile methods and practices.  We organized all of our business analysts, QA analysts, and engineers into six cross-functional teams and aligned them with product families.  The membership of these teams is stable and work is funneled to them instead of forming new teams around new projects.  With six stable teams, we had a clear view of our capacity that forced us to stop trying to work on too many concurrent projects.

We had great internal support and it didn’t take long for the teams to stabilize and consistently deliver working, tested software.  We learned early that the teams could hum along when they had a well-groomed backlog, but really struggled when the backlog of work was vague.

As a means to force the creation of well-groomed backlogs across the teams, I scheduled our first quarterly release planning meeting to occur about three months after we began our adoption — nicely aligned with a vacation I already had planned.  Seriously, I went on vacation and left one of our scrum masters to facilitate our company’s very first attempt at synchronized release planning.

The key learning from the first release-planning session was that planning can’t be accomplished in a two-day period.  Planning needs to be continuous with a short burst of what people have termed “pre-planning” right before the two-day planning event.

The SAFe Big Picture

SAFe Big PictureThe quarterly two-day planning event  continued to be valuable as a way to achieve synchronization across businesses and teams.  It was a great way to meet the tactical needs of our teams to understand what they need to build and think about how they’re going to build it.

However, the methods used to conduct continuous planning and prepare for the planning event were a bit of a dark art.  Some product groups did it well while others really struggled.

Additionally, the growth in people and products across the company made it impossible for any one person to have awareness of what’s going on at any level of depth.  We’re now up to 13 teams serving seven product lines across two business units.

As we grew, we started to look at Agile scaling models that would give us a framework to enable distributed decision making within certain guardrails.  We wanted people to understand how they would consistently contribute to the process of turning an idea into a product feature.

At the time we began to adopt Agile methods and practices, I was reading Leffingwell’s Agile Software Requirements book, a precursor to the SAFe.  I adapted concepts from the book into our existing stage-gate product development process.  At a very high level, our process looks like this:

Simple Process

Obviously, I’m not much of a graphic artist so I’ve kept the SAFe Big Picture on my wall to give me something to point at when I’m explaining the principles and concepts of scaled Agile.

The Agile Manifesto

Agile ManifestoThat was all well and good, but I felt like we were losing something in the process.  I started to hear phrases like “sign-off” and “hand-off”, phrases that reminded me of the days of waterfall software development and a lack of cross-functional collaboration.

When looking at Agile scaling frameworks, it can be easy to get lost in the “governance” aspects required to effectively implement and leverage a multi-tiered model.  It is tempting to get caught up in all the nicely structured functional-decomposition tokens (epics, features, stories) and the logical lifecycle flows of these tokens.  It all looks so neat and orderly — how could anything go wrong?

Some things that started to go wrong were long lead times in the fuzzy front end, creation of lengthy Business Requirements Documents (BRDs) by Business Analaysts, sign offs on BRDs, and narrowing in on a solution very early with late engagement of technologists to validate potential solutions.  Man, we were back to waterfall!

As I looked at the copy of the Agile Manifesto taped above of my desk, it bugged the hell out of me that we were losing sight of the first value,individuals and interactions over processes and tools, as we scaled Agile to earlier phases of product development.

Possible/Valuable/Viable

possible valuable viableAlthough I was frustrated that we were sliding into waterfall practices in the early phases of product development, I struggled to figure out what action to take.  That changed one day when I was talking to my friend Dennis Stevens.  Imagine that — an interaction with another individual helped me move forward.

When we got through with our conversation, we had come up with a simple model called “possible/valuable/viable”.  We wanted to make sure conversations were happening at all phases of product development between people who could evaluate whether something was possible, valuable, and viable.

  • Possible: we have the organizational capability and capacity to undertake it.
  • Valuable: it provides value to us and our customers.
  • Viable: there is an achievable technical solution for it.

When we applied Possible/Valuable/Viable to our development process, you can see the roles involved at the various stages of development.

Simple process with PVV

Early in the process, the Executive Committee and GMs are determining if we’ve got the high-level strategic capability and capacity to undertake a new idea.  They’re having conversations with business managers who understand the marketplace value and architects who can help assess build/buy choices.

In the middle where we we’re decomposing the idea into versions and features, the PMO is making sure the right people in the organization are available.  They’re having conversations with business analysts who help determine what features are most valuable, and architects or tech leads who are coming up with the specific solution architecture.

When we get down to building and releasing software, scrum masters, product owners, and teams are having the possible/valuable/viable conversations.

Results

As with all things Agile, the journey continues.  We don’t get the right people involved every time, but we’ve seen significant progress.

The simplicity of possible/valuable/viable has also proven to be helpful.  When someone says a decision was made and I ask, “Who was there to assess the viable aspect?” no more needs to be said.  The person I’m asking has a clear understanding what I’m talking about.

Leave a Reply

Your email address will not be published. Required fields are marked *