Alignment vs. Autonomy and the Purpose Alignment Model
How do we create alignment and what tools can we use to quickly evaluate if what we want to do is part of the mission or better left out? Niel Nickolaisen created the Purpose Alignment model and I use it with innovation labs in large enterprises to decide what should be part of our innovation and what should be left to others.
Join the DZone community and get the full member experience.Join For Free
When scaling agile / Scrum, we invariably run into the alignment vs autonomy problem. In short, you cannot have autonomous self-directing teams if they have no clue in what direction they should go; or even shorter, alignment breeds autonomy.
But how do we create alignment and what tools can we use to quickly evaluate if what we want to do is part of the mission or better left out? Niel Nickolaisen created the Purpose Alignment model and I use it with innovation labs in large enterprises to decide what should be part of our innovation and what should be left to others.
If you struggle with aligning your development approaches with the market strategy on how their product is going to be successful in the marketplace, grab a whiteboard. To be successful, a product must solve a particular set of problems that customers are willing to pay for. At the same time, it needs to solve other basic problems no worse than the current solution. Product teams need to know where they are aiming to be “differentiating” and where they are aiming to be “good enough.”
As Gartner as taught us: all comprehensible things fit a 2 by 2 diagram. In reality, the world is more complex but if we can frame our problem in two dimensions at least the major decisions become obvious.
The Y –axis is indicating where your product should have true market differentiation (high) or where differentiation is either not possible or simply not a focus of the organization (low). The X-axis asks what the impact or mission criticality is.
It’s easy to see that your product is differentiating not only in functionality, but also in importance to the end user. If it is not that important, or mission critical as Niels calls it, we just need to be on parity with the solution we are substituting. Remember the first iPhone? It was not attacking Nokia on call quality, durability or battery life, but was good enough.
Some aspects may not be in your reach, but are mission critical to the customer. For those items, we can look to partner with someone to create an overall differentiated offering, e.g., we created several Value Added Reseller networks for our products. This allows for local, native presence for support, training and maintenance, while the product company focusses their energy on increasing the differentiation.
Then there is the who cares segment. Really, the customer doesn’t care and we won’t sell anything more if we build something there. (2 x 2 quadrants always have such a segment. It helps the Product Manager to say "No.")
To align the individual Product Owners/Managers of the self-directing team, we need to get them together and decide on what the model looks like. You probably won’t get this right the first time, but that is okay. Build in feedback loops to test your assumptions, if you think a feature is mission critical, gather evidence.
Follow these steps to engage in purpose alignment:
- Present and explain the model.
- Identify the key problem for your customer that you solve better than anyone else.
- Write a simple filtering statement or question that you can use to quickly evaluate future decisions and designs. Verification: check if any of the differentiating activities can best be delivered via a partnership, if so they are not a partner, but a competitor.
- Now check if the remains features are mission critical or differentiating and assign them to the appropriate boxes.
You can use the Purpose Alignment Model for roadmap planning, by performing a gap analysis on the differentiating, parity, and partnering activities. Your roadmap should explain how to fill the gaps.
The second great use of the Purpose Alignment Model is to design projects, features, and functionality around purpose. Design differentiating features and functionality to win the market. Design parity features to be good enough. Parity features are still mission critical so don’t do them poorly, but simplify and standardize.
If you have an engaged team they will want to solve all of the problems for your customer. We want to be the best in what we do, so leaving something to partners or not doing it all doesn’t feel right. After all, everything we do is important, right? So it must be upper right corner stuff!
People have a natural tendency to make their work “differentiating” and if you don’t emphasize and communicate the mission-critical nature of the parity activities, people will resist the use of the model and its associated decision filters. Or worse, they will attempt to put everything in the differentiating category.
So if your workshop ends up with all stickies in the upper right corner, your did not moderate it well.
What I like about the Purpose Alignment Model is that it can be done with Post-IT’s which makes it easy to update. Have regular meetings in cadence with your release scheme to make sure you are not chasing the past. Also, partner opportunities come and go, sometimes you need to adapt your strategy. The Kano model learns us that what once was a differentiating feature will become a parity feature over time.
Purpose Is Not Priority
Purpose identifies the design goals of a process, business rule, function, or feature. It does not define the sequence in which the work on that process, rule, function, or feature must occur. That being said, purpose can provide a framework for strategic and tactical planning.
Now, go look at your product backlog and ask yourself the following questions:
- Is your product differentiated in the market?
- Are you treating some features as though they are differentiated but just need to be at parity?
- Are you working on features that are really neither differentiated nor mission critical?
Published at DZone with permission of Chris Lukassen, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.