The Three Pillars of Product Agility, Part 3: Change and Collaboration

Agile is simple to understand but a challenge to master. Learn how to achieve sustainable product agility in your organization in this three-part series.

In the first part of the series, we looked at the concept of a quarterly North Star to focus teams on outcomes. We also looked at the importance of making fast decisions and how that can be more affordable than looking for more information. In the second part of this series, we looked at why it’s important to reach out to your customers and how experimentation plays a significant role in discovering opportunities and solutions.

In this post, I will discuss why we need to set the proper foundation to promote team and product group collaboration and alignment.

Set the Ground for Collaboration

For many organizations, keeping people aligned is one of the most challenging and time-consuming challenges. Achieving a successful alignment of managers, internal stakeholders, and customers is quite a balancing act. Getting your manager’s buy-in of the product roadmap requires alignment with their needs and expectations. When building risky solutions, you need to be aligned. When pursuing a problem that will occupy a team for months, you need to be aligned.

Promote Recurring Alignment

But how do you align people that are often overwhelmed with work? People with a different context? What if to move forward, you need them to make a decision or a sponsorship?

Based on my experience, the answer is cadence. Teams should get recurrent feedback from managers, internal stakeholders, and customers.

Align with your managers on a frequent basis (monthly, for example): share findings, discoveries, the execution of deliverables, and identified risks to the roadmap that may jeopardize the initiative. They can help you handle the risks or agree on a shared and sponsored decision. This kind of executive meeting promotes alignment and builds trust.

Align with internal stakeholders (every 2 weeks, for example): share the discovery process progression, show them what you’ve developed and what you plan to build, get their valuable feedback or ask questions, and fight assumptions.

You can also extend the invite to other teams with whom you share technical or shared-value dependencies.

Align with your customers whenever possible: communicate with them frequently. For instance, don’t underestimate the power of having a monthly release scheduled. Keep your customers engaged. Keep them wondering what goodies the next version will deliver.

There are several benefits in having a steady cadence. It maintains a light pressure for the team to distill their knowledge. It forces decision-making because the team regularly meets with the stakeholders. Risks and assumptions are regularly conveyed to the managers, and decision-making is a shared effort. Constant alignment requires teams to be forthright when preparing alignment sessions, and they can move forward with confidence.

Pitfall warning: cadence should never replace ongoing communication. Don’t hold back when an unexpected risk happens that can compromise the project; don’t wait for your next meeting. Recurrence simply means that you are steadily working towards your audience’s expectations. They expect to see something meaningful, and you want (and need) their feedback.

Use Visual Representations

Externalizing our thinking with visual representations helps us to examine our thoughts. It allows others to critique our thinking, guiding us toward our next steps. The Opportunity Solution Tree, developed by product coach Teresa Torres, is the best visual representation aid I’ve seen. It supports streamlined communication with outcomes, problems, and solutions. It’s a simple way of representing how you plan to reach the desired outcome, making implicit assumptions explicit. It forces you to have the right conversations.

There are four sections to the Product Opportunity Tree:

Section #1: Align around a clear desired outcome. This gives you a clear direction of what you want to achieve. It’s the essential first step to knowing what to do next.

Section #2: Opportunities should emerge from generative research. Learning our customer’s needs and pain points show us opportunities. Each opportunity should be framed on the tree.

Section #3: Solutions can and should come from everywhere as long as they help us find an opportunity.

Section #4: Experiment to validate the solutions and the riskiest assumptions behind them — not the whole solution.

Visual representation brings clarity, speed, engagement, and impact. Visual storytelling equalizes everyone involved making communication more easily understood, and memorable.

I’m such a huge fan of visual communication that I even called my personal blog napkin-talks.

Offer Autonomy With Constraints

A triad (a team of three) is considered by many to be the sweet spot for the modern product team composition. Typically, these teams are given full autonomy to decide on their course. They have the mandate and all the skills to discover and deliver a feature. Software development triad teams balance the responsibility between Product Management, Product Experience Design, and Engineering.

Product Management: the product manager represents the customer, the wider business, the team’s stakeholders, and vice versa. They ensure value.

Product Experience Design: user experience ensures the product is coherent and provides the voice and personality for the product. They ensure usability and desirability.

Engineering: Development delivers the feature to the product, ensuring reliability and stability and responding to issues — Engineering ensures feasibility.

Yet, frequently, this unbounded autonomy brings painful frustration. Teams lack momentum and spend too much time planning. Then they lose measurable goals and ultimately fail to demonstrate value to the customers.

Teams are mandated but often don’t have the maturity to make decisions. They are given more responsibility and autonomy than they can handle. Managers assume they did a great job hiring the best talent and expect them to simply deliver.

To build a team that systematically delivers, you need to give them two things: a flow with a common language and rules. The flow is like a process foundation, it’s a path that keeps the team aligned and collaborating, yet it’s not a prescriptive framework. The flow is an empirical framework, based on observation and experience, and it includes lean and centralized sources of common knowledge in the form of best practices, concepts, values, principles, and pointers to relevant information that will help with discovery or development activities. The flow evolves along the way, adapting to the needs and characteristics of the organization. It keeps the team aligned and acting consistently because everyone speaks the same language.

How do you explain to a newcomer your product development processes? This empirical framework can provide the answer. You can quickly onboard them, suggesting the flow they can follow to collaborate efficiently.

Identify what constraints will safeguard the team’s growth. Narrowing the options down focuses the team on the priorities. The constraints can be related to the product or procedures that are key for overall alignment, like a quarterly outcome, a release every 2 weeks, an updated roadmap deck at the end of each month, or a monthly meeting with the managers.

The Ultimate Goal of Agile (It’s Not Agile)

The Agile or Agility Methodology is often misunderstood, leading many companies to struggle with their Agile transformation, frequently failing with catastrophic consequences. It’s becoming ever more common to see headlines like U.K. wasting £37 billion a year on failed Agile IT projects.

Why is that? Because organizations have gone for the quick fix (certifications and in-room training, for example) expecting it to solve all their problems.

In 2014, Dave Thomas wrote, “Once the Manifesto became popular, the word Agile became a magnet for anyone with hours to bill or products to sell. It became a marketing term, cooped to improve sales in the same way that words such as eco and natural are. A word that is abused in this way becomes useless — it stops having meaning as it transitions into a brand.” Well, I believe it’s continued to go downhill since then.

Agile is not the end goal, and organizations don’t want to be Agile. They want to be faster at reacting to change, to be profitable. Agile is a means to an end. The goal of Agile is to serve the purpose of the organization as best as possible.

Avoid the Agile Pitfalls

I love the interactive learning Agile brings. But Agile is blindly overused, gaining a bad reputation. Organizations misunderstand its purpose. The Agile Manifesto is frequently misinterpreted as being a principles-based mindset, and this leads to two unintended consequences.

Pitfall #1: Organizations have forgotten to be customer-centric. Instead, their focus is on delivering efficiently, and they lose sight of delivering what the customer wants and needs.

Pitfall #2: Organizations have forgotten to promote behaviours and practices that reflect the values and principles of Agile. Words without actions are meaningless, an expensive illusion.

To set the record straight, Agility is simple. These are three steps to achieve agility:

1. Define the impact you want to achieve. This means identify and move confidently towards the chosen North Star (something that is measurable and meaningful for the customer).
2. Iterate on your work in light of what you’ve learned. This means to identify and partner with customers and experiment smart (fast and cheap) with them.
3. Be efficient in reacting to change. This means you need to set the ground for collaboration in order to promote effective collaboration in the team and within the product group.

Mastering Agility is quite a challenge. If you don’t fully understand what Agility is, your transformation may be set up to fail even before you start.

If you want to avoid some of the growing pains that come with learning the Agile methodology, I suggest you read these two articles I wrote about what coaching Agile for long and lasting results really means and why Servant Leadership is so discouraged, what you can do to avoid it, and how to start nurturing a supportive culture.

Delving deeper into Agile is well worth your time — if you want to save time in the future, that is. And don’t forget that keeping your customers happy, keeps your stakeholders happy too.