I'm quite certain a lot of people reading this article would heard of or read about ZOPA (zone of possible agreement). It talks about the common ground between 2 parties where they both benefit from the negotiations that occur between them, as illustrated in the image below (ref: https://www.beyondintractability.org/essay/zopa)
For e.g. business wants a user management module on the company's ecommerce website in 1 month and delivery team feels it cannot be delivered in less than 2 months. If n either of them negotiate keeping the other's requirements in mind it would be a stalemate and nothing would ever get done. 3 possible ways to proceed from here could be:
Get more people to do the work (not a good idea)
Increase the time to market (possible but not the best idea)
Negotiate on the scope (good idea)
A possible outcome benefitting both the business and developers could be reducing the scope of user management to roughly fit in a month. If you have other possible outcomes please feel free to comment on the article. Would love to add your suggestions to the list above.
What problem are we trying to solve
Enough of fluffing around about ZOPA, let's cut to the chase. Have you ever faced a "prioritisation stalemate" kind of a situation where you experience some of the following behaviours or activities:
Business users call the priority without factoring in delivery complexity
There's hardly any collaboration between business and delivery when prioritisation is done
The team cannot visualise how priority is done
Methods of prioritisation often do not fit the construct of the team
Prioritisation over time becomes a non - repeatable activity with over dependence on key people
Prioritisation becomes a burden with too much time spent on it because there's no agreement on parameters / attributes for relative comparison
If the answer to any of the above behaviours is yes, then we're in business and I get start getting into GoPA.
Introducing "GoPA"
A technique that's stood the test of time and has been a revolution in way teams prioritise their work collaboratively. I'm only joking. In reality i've used GoPA with a few teams and have been able to refine itwith the learnings from failed attempts.
On the Y axis we have value (business value) and on the X axis we have complexity (delivery complexity).
The graveyard is usually items with low value and high complexity, i.e they'll never get done. For e.g 5.
The "no brainers" are the low hanging fruit that have high value and low complexity, i.e just get them done. For e.g 6.
The order of implementation starts from the high value low complexity quadrant to low value high complexity quadrant. If you notice I have an arc on the line which is bent towards value. This arc is used to signify that we should assign a high priority to higher value items when there's 2 items placed close to each other on the graph. It's like you're giving the benefit of doubt to higher value items in case of a deadlock or confusion.
The benefits I've seen from using this technique are:
Common team priority
Ubiquity - everyone speaks the same language
It's visual
Level playing field for everyone in the team. Business and delivery have to work together to provide necessary inputs
Gives a relative comparison for items
It's simple :)
Failed attempts and how GoPA got refined to it's current avatar
Just want to take an opportunity to talk about how I like to coach. I like to dumb things down to a level that's understandable and maintainable by everyone in the team (ubiquity). I'm a big fan of ubiquity and GoPA helps in that endeavour by creating a simple and repeatable way of how a team prioritises. The following are some of the highlights of the failed attempts that helped refine GoPA:
1. How the "arc" in the order of implementation got added to the graph
When I first used this technique with a data mining platform at Telstra back in 2012 it didn't go as planned. This was because there were a number of items that were relatively close to each other on the graph, i.e similar value and complexities. Almost every attempt to prioritise these items ended up in a shit fest (pardon my french) between the business and the delivery. We finally came to an agreement that slightly higher business value takes priority over slightly lower delivery complexity when there's a conflict.
Well that solved the that problem but the graph was never used religiously. I couldn't really figure why. The usual complaint from delivery was that business assigns higher value when they want to and the usual complaint from business was that delivery makes items more complex when they want to. This was an issue of trust and empathy for each other.
2. How the definition of value and complexity was added to the graph
It took me quite some time and after I had moved on from Telstra to figure out what the issue was. It was while I was trying to prioritise my personal backlog of ideas when it dawned on me that there was no relative comparison for value or complexity. Damn you ubiquity - I screamed. I took a step back and
listed things I deemed as value to me (I was the business here :D)
listed things I could use as a measure of complexity (I was always delivery here :D)
I don't remember the exact parameters I added but it was something on the lines of the above lists. Now this started to make sense to me. Every time I visited my GoPA, I knew the questions I needed answers for and it made my life easy when it came to prioritisation. Now I didn't have an issue slotting my ideas on the graph and rarely did I have a conflict. On the occasion that I did, I pulled out my trump card; requested my wife to prioritise it for me :D
So, in a nutshell:
Define what value and complexity means to you and jot them down on the graph. If working in a team do it collaboratively so that everyone feels like they're part of it. If they own it they'll take care of it.
Make it visual and build your prioritisation cadence around the graph. It'll help keep it up to date.
Make it ubiquitous. So that everyone understand everyone else.
Business and delivery may be separate teams. Try and make them 1.
Find a whiteboard (or create a confluence page for distributed teams) and write "PLEASE DO NOT RUB" on it in caps and bold letters. Draw your GoPA on it.
Keep it simple
What do you think of GoPA? Please share your thoughts and opinions if you do try it at your workplace. Would love to incorporate feedback and make it better :)
Happy days and happy sharing and learning :)
Comments