Mastering Product Agility in the Modern Organization

Back in the days before agile really took hold in the software development world, workflow processes were dominated by project management. You might not remember what that was like, but you can imagine it:

1. It started with a tremendous amount of research and brainstorming focused on identifying a killer idea, and then figuring out how to make that idea a reality.
2. A master plan was developed — including a detailed budget and schedule broken down into milestones over what could be as much as two or more years — and that plan became the marching orders for however many developers were needed to carry it out.
3. In the largest development organizations, most developers would be assigned their little slice of a project, and then move on to the next project in line where their particular skill set was needed.
4. And then, finally, perhaps two years after the initial idea appeared, there would be a finished product sitting there ready to launch.

 

Of course, by then the market had often changed, as had the customer’s wants and needs. Depending on how dramatic the change was, the product may have been launched to lackluster reception, pulled back in for some massive overhauls, or even scrapped completely.

That’s why Agile software development was created in the first place: the system was broken and it needed to be fixed. And, to a large extent, agile development practices have successfully improved the system. Most development organizations now claim to be agile, and there’s no doubt that products are making it from idea to launch far more quickly than they ever did as projects.

But, even today in many organizations, the old project management principles that ruled the industry years ago are still very much in place. Sure, they’re beneath the surface, well hidden under Scrum-colored skin and flashy kanban makeup. But, they’re still there. And, as a result, development organizations are still facing some of the challenges that old broken system was known for.

The solution to this pervasive problem is product agility.

 

How Are Projects and Products Different?

To understand what product agility actually is, we need to take a step back and consider the meanings of the words project and product in this context:

 

Project

According to the Project Management Institute, “a project is a temporary endeavor undertaken to create a unique product, service, or result.” In a software development context, although every project is different, they tend to share some common attributes:

• The project has a set start time and end time, and a detailed plan with milestones to be reached.
• Effective management and execution of the project is measured by how closely the plan is followed.
• The work is assigned to ad hoc teams based on what’s needed to reach the next milestone.
• The project is finished when the product, service, or result is created. Any changes based on customer feedback or future maintenance would constitute a different project.
• A project is considered successful if it was completed on time, within scope, and under budget.

 

No doubt, you can see that traditional project management flies directly in the face of nearly everything the Agile Manifesto declared. You might think it would be impossible for anything like a project to make its way into a supposedly agile development organization. But, as we’ll see in the next section, that’s not true at all.

 

Product

As defined by Anne Steiner, VP of Product Agility at Cprime, “a product is anything you build or develop that impacts people.” As we’ll discuss below, this is a pretty significant shift in thinking about work. Organizations that achieve that shift notice these qualities:

• A product has no inherent start and stop points, so it expands to include all necessary changes or maintenance along the way.
• Instead, products have “time horizons” stretching from initial concept to final “sunsetting”.
• Ideally, the same core group of experts will work together throughout the product’s entire lifespan, allowing for deep expertise and a tight-knit working environment.
• Success is measured based on the frequent delivery of value to the customer across the product’s lifespan.

 

Clearly, thinking of your development work in terms of products (rather than projects) falls far more in line with agile principles. Interestingly, though, it’s actually at odds with some common agile practices, including some that have become so ubiquitous, they’re almost considered synonymous with agile.

 

Product agility

With those two definitions in mind, the meaning of the term “product agility” becomes clear:

Product agility is not a specific process as much as it is a new way of looking at work. Its focus is on delivering value to the customer often through fast, iterative cycles of discovery and delivery. And, as a result, it’s finally addressing one of the biggest issues traditional project management never could:

It ensures we’re actually building the right thing, rather than allowing us to build the wrong thing well.

Product Agility is a Different Mindset

Let’s briefly run through the basics of a product agility workflow to illustrate how much it probably differs from what you’re doing right now. If you’re like most development organizations, you’ll see bits and pieces of this ideal description in your current processes, but you’ll also see a lot of things that are slowing you down. That’s totally fine, because improvement is always possible.

Phase one: early product discovery

As opposed to a traditional project planning and strategy period, which could last weeks or months, the official start of an agile product is a brief discovery period that usually lasts just one or two days.

During that period, the following four questions are considered:

1. What are we building?
2. Why are we building it?
3. Who are we building it for?
4. How are we building it?

 

Phase One may begin with one or more seeds of ideas that have been collected over time, or it may start with a fresh brainstorming session. But, the key test of which concepts are pursued lies, not in who came up with the idea or how long it’s been floating around, but in how effectively those four questions can be answered when considering each idea. The concepts that generate productive answers across the board are worth moving ahead with, while others should probably be scrapped or, at least, deferred to a later discovery session when new information may be available.
<br/

The end result of early product discovery is a list of prioritized experiments that are worth investing some time and resources into. That list is our product backlog.

 

Phase two: blended discovery and delivery

That initial product backlog may only include a few dozen stories to start with, but it’s enough to engage a new product team and give them some productive work to dig into. This product team will include members focused solely on delivery — such as FEDs, BEDs, and QA testers — as well as members dedicated to ongoing discovery — such as product managers, product owners, and analysts. Most importantly, there will be at least a few team members who are involved in both aspects of the product development process. Some examples may include a tech lead, lead QA engineer, or UX developer. While they’re in the trenches writing and testing code, they’re also in a prime position to share information back and forth with the discovery folks to inform the work.

As this blended team starts working on the initial product backlog, trying out the experiments, a feedback loop is immediately established between delivery and discovery. The delivery side is constantly considering these questions:

• How will we build this?
• How much can we build?
• Are we building it the right way?

 

Meanwhile, the discovery side is considering:

• What problems does the customer have?
• What value can we create for them?
• In what order should we create that value?
• Are we building the right thing?

 

With each iteration, the stories completed by the delivery side provide additional data to the discovery side. And, simultaneously, the discovery side is taking that data and using it to hone and expand the product backlog with new stories for the delivery side to execute.

With that feedback loop in constant motion, the initial “plan” as it was conceived during early product discovery may or may not even exist after a few iterations. That’s because the product team is able to pivot incredibly quickly as real world results inform their activity.

In some cases, experiments prove that the initial product idea just doesn’t have legs and it needs to be scrapped. This is certainly a boon for the company because investment in what turns out to be a failed product is only a fraction of what it would likely have been after a year-long project resulted in the same conclusion. On the other hand, if the experiments continue proving that the product is creating real value for the customer, development continues and the product is constantly improved.

 

Phase three: sunrise to sunset

With the initial release of a minimal viable product, ideally very early in the development process, the product’s customer-facing lifecycle begins. Since the stories making up the product backlog were strategically ordered by priority, this first official release of the product should have just enough features to carry the customer through a complete “journey”.

You can think about a customer journey as a logical, horizontal path through a grid full of potential features. Each column is its own feature stack, some of which are vital, and others of which are nice-to-haves. Likewise, each stack includes features that are dependent on, or demand features in other stacks.

Here’s a simple example of what could be an ecommerce mobile app:

 

Through strategic prioritization, the product team ensures that what they release to customers adds the highest possible value by taking them through the most valuable journeys first. In the above example, the first release of this ecommerce mobile app includes just enough of the features to allow a customer to log in, find what they want using search, save their favorite products, and securely checkout.

 

Then, the next journey may include a second way to save favorite products (like a shareable wish list) as well as a few filters to help enhance product discovery, or a new payment method. The key is that future releases can add new journeys or enhance the journeys already provided, increasing the product’s value over time. Most importantly, these decisions (what to build, when, and for whom) are based on real world feedback and data.

 

Product Agility Beats Project Management

Product agility is a far more nimble way to approach product development than the traditional project paradigm could offer. For the modern development organization, the speed and agility with which a product can be conceived, developed, tested, and improved is crucial to success. Done well, product agility offers all the following benefits:

• Frequent delivery of whole value
• Building the right thing in the right way
• Collaborative learning and improvement
• Balancing evidence with intuition
• Producing what people need
• And, doing it in a way that doesn’t burn people out

 

But, making the transition isn’t going to be easy for most organizations. Smart companies get help. If you’re ready to finally break free from the limitations of a broken project management system, explore what Cprime can offer to help you master product agility!