One of the key risks that organisations need to address, is building the wrong thing. No one willingly builds the wrong thing, so why do Product Owners build the wrong thing?
The first question to understand is “What is the wrong thing?”. The wrong thing is building anything other than the right thing?
So the second question is “What is the right thing?”. The right thing is a subjective decision based on the context of the organisation and the needs of the customer. At least Product Owners always prioritize the building of what they think their customers or organisations need. Or do they?
There is a nasty cognitive bias built into most organisations that Executives need to actively manage. That bias is your architecture and organisation structure. Everyone knows that it is easier to deliver something if only your team is involved. They know that involving another team in their department is harder so will try to avoid doing that. They know that involving another team in another department or division makes it even harder, almost impossible in fact. So as a result the way that many product owners approach the problem is not to ask “What does the customer need?”, they ask “What does the customer need, that I can do with my team or another team in my department?” As such, the Product Owner is more focused on their capability than the needs of the customer. They will (often unconsciously due to the culture) pre-filter those things they know are hard to deliver.
So the answer is simple, the reason why building the wrong thing is so so easy, is because building the right thing is hard.
Some Agilistas around the world have attempted to avoid this problem by creating “autonomous product” groups such as Spotify’s Tribal Model or SAFE’s Agile Release Train. My experience is that no matter how hard you try to architect your product solution to remove dependencies, there is always a customer or organisational need that crawls out of the woodwork that requires work by two or more groups. There is always a new regulatory regime, or a new way of servicing the client, or a new operating system that requires coordinated changes across multiple “autonomous product” groups.
So instead of trying to build autonomous product groups, or constructing projects from scratch, lets consider a middle ground. What would that look like?
- Create long lived teams based on a carefully (and continuously) thought out but dynamic architecture. Smaller components supported by a handful of teams are more stable than massive chunks of the business.
- Use Quarterly Capacity Planning to optimise the delivery of value from the portfolio, and make it easy to pull together teams needed to deliver the customers needs. Ensure that all of the business have an agreed ordered backlog.
- Understand that pulling together a group of teams who do not normally work together is constructing a value stream from scratch. Get the teams to collaborate and coordinate using “scrum of scrum” stand ups and regular retrospectives (rather than plan up front). Assign responsible to facilitate the collaboration and coordination to an individual for each piece of work. Make it easy to reassemble groups of teams by doing it frequently as required by the work rather than try to avoid it.
- Build what the customer and organisation need rather than build what is easy.
This was the approach Skype took to managing the risk of building the wrong thing. We may not have built the right thing every time, but at least we did not build the wrong thing because it was easier than building the right thing.
Its another genius thing worth studying that Mark Gillett created.
The IT Risk Manager 
January 1st, 2017 at 10:46 pm
HI Chris,
Thanks again for sharing your expertise. I’d like to clarify my understanding on one of your points.
You said: “Create long lived teams based on a carefully (and continuously) thought out but dynamic architecture. Smaller components supported by a handful of teams are more stable than massive chunks of the business.”
Having worked with some large organizations that struggled with how to organize their teams and fought constantly between “component” teams and “feature” teams I’m trying to get a picture in my head of what this might look like.
So lets use for an example, (Since I suspect you can’t share how Skype was organized). Let’s pick Hipmunk (hipmunk.com) simply because it’s fairly easy to take a look at and see how things may be broken up (or at least take a guess).
So the way you would approach Hipmunk would you have teams formed around:
– Flights
– Hotels
– Cars
– Packages
– Integration with Other price listing sites
– Other
Or are those components too large, or did I pick the absolutely wrong way to go about organizing the teams and the architecture.
January 2nd, 2017 at 11:45 am
Hi Kent
The answer is “it depends” of course based on the customer needs and where the most change will happen. Its likely that the following components exist:
Payments and Accounting
Customer and Login
Mobile and Web
Desktop (Mac and Windows)
Flights and Hotels and Cars in a single component
Interfaces in a single component
One of the problems is when organisations try to align the product and delivery organisations. Obviously each development team needs a product owner but the product owner organisation is better aligned with the organisations metrics rather than the architecture. The delivery teams need to be aligned to the architectural components.
The architecture is dynamic and the APIs (the architecture) will shift over time. For example, the company wants to try an experiment with a new service called “Day Trips”. They start it as a premium service for web only (because web have spare capacity). The web team build the thing front to back based on its future state architecture or in such a way that the refactoring to the future state architecture is easy to do. If it is successful, it spins off into a “Day Trip” component containing the business logic and feeds, and finally into the target architecture with a separate feeds team. In effect, the teams switch between feature teams and component teams based on the context. You see the team APIs migrate closer to the UI when the feature is stable and rolled out across several UIs, and the team API is further away from the UI when there is more change.
Does that help or do we need a Skype call?
Chris
January 3rd, 2017 at 4:05 am
Hi Chris,
Thanks a bunch for your reply.
It helps… but I think we need a Skype call. I’d like to unpack this:
“Obviously each development team needs a product owner but the product owner organisation is better aligned with the organisations metrics rather than the architecture. The delivery teams need to be aligned to the architectural components.”
Because I think there is something extremely important embedded in there that I want to make sure I’m picturing correctly and not making a bad assumption. I think it goes back to the idea you hinted at of the product owner (or somebody) shepherding in #3 of the original post.
January 2nd, 2017 at 3:37 pm
Hi Chris,
What a great series of blogs over the last couple of weeks. I might be oversimplifying things but there seems to be a constant theme that you are continually returning to the ‘what’ (e.g. customer needs, business value, agile principles and values) to inform and guide the ‘how’ (e.g. organisational structures, technology, tools and techniques).
You can look at this as above the line thinking – the what and below the line thinking is the how. I keep seeing people accept that there is no alternative to ‘how’ they currently do things which as you say results in building the wrong thing. I think in this blog you are trying to find a way of organising ‘how’ you do things so that it can easily recognise and adapt to the new ‘what’ which may or may not mean changing ‘how’ you do things.
I keep referring to the Brown Cow model which Suzanne Robertson describes here I keep referring to the Brown Cow model which Suzanne Robertson describes here https://www.youtube.com/watch?v=NygofsXJhuc
cheers
James
January 4th, 2017 at 2:09 pm
Chris,
Thanks again for serving as unofficial historian and process librarian for some of the approaches we adopted at Skype.
Perhaps to help folks think through some of the ‘how’ and ‘why’ regarding our team organization:
I. Acknowledge Conway’s law – you will most likely end up shipping your org chart, and the best internal APIs you have will be between teams and not within teams;
II. Recognize domain boundaries – within any application/system (if you look hard enough) there are domain boundaries which are apparent (payments are different to call signaling, or to media sharing in the Skype example). Try to organize team within coherent domain spaces (note this is very different from organizing teams within the traditional architectural domains (front end, middle tier, back end).
III. Dependencies are not bad ….. tight coupling is – if you have no dependencies then likely you aren’t building one product or solution and likely you have multiple customers. Seek as an objective to minimize the need for synchronous evolution across teams. Co-ordination will be necessary (primarily to allow teams to understand when other teams will facilitate mutual release of value) – think of co-ordination about sequencing work and mutual understanding of the value of backlog items.
IV. Encourage folks to recognize and avoid excessive ‘local optima’ – as teams have more freedom to innovate and drive their own metrics forward it is important that everyone has as much of the full ‘organizational context’ as is possible (obviously the value cascade is important here 😉 ). Product owners at team level should collaborate to understand the whole product value proposition and to optimize value across as well as within product areas.
V. Recognize that the role of leadership is in strategy and capital allocation (in the case of most engineering organizations this means resource (i.e. people) allocation). To this end the activities you outline in 1. & 2. and the thinking above should result both in long lived teams and in careful capital allocation from the leadership to balance delivery velocity (over the mid-term – perhaps several quarters) of the entire system.
Mark