I recently led a short evening session discussing strategies for collective code ownership. We opened with a set of patterns and practices but the team highlighted something painfully obvious that I’d overlooked…
What’s the business value and driver behind collective code ownership. What’s in it for your product owners and customers?
So often we focus on the people barriers and technical challenges to collective code ownership without recognizing that the barriers may be organizational or financial.
This challenge happens when you attach yourself to “the right thing to do” and seek to progress without recognizing that the population you’re likely to be working with will fall across a spectrum from complete support, through “don’t care” to disagreement and dissent.
If you want to pursue a strategy for collective code ownership, step back and work through the following questions (some of these are hard – consider starting by brainstorming with a small supportive team):
- If we just got on did it, would we be successful?
- Yes – Great, you’re working with a team and business that “gets” this or trusts you to do the right thing. You could stop reading here, but you might want to skim this to see what ideas & thoughts are triggered.
- No – OK, you’re part of the more normal population (for now) read on for some ideas. You might not need to cover all of the following (and if you do, it might slow you down)
Still reading? – Good!
The following apply to pretty much any change or investment program but answering them is surprisingly hard. Your context will probably differ to mine so I’ve not given all the answers today.
- What are the top 1-3 benefits of pursuing this?
- What are the top 1-3 costs of pursuing this?
- Are there people outside the team that I’m going to need to “sell” to?
- Are there people inside the team that I’ll need to sell to?
- What are the risks, pitfalls and political or personal agendas?
- What do we sacrifice – what’s the opportunity cost?
- Who are my supporters and how can they help me?
- Who’s on the fence, do they need to be involved and how can they help/hinder?
- Who will fight against this and how big a problem is that really?
- Do I ask for permission and support or press ahead and ask for forgiveness later?
- Who will this impact and in what ways (positive and negative)? **detail below
**How about those stakeholders?
For the set of stakeholder questions I suggest you’ll achieve better flow and find natural breaks if you cover positive and negative aspects for each role by “switching hats” as you work through rather than batching up all the positives first.
- What’s in it for you and what’s the down side?
- What’s in it for your peers and what’s the down side?
- What’s in it for your boss and what’s the down side?
- What’s in it for your team and what’s the down side?
- What’s in it for your business and what’s the down side?
- What’s in it for your users and what’s the down side?
- What’s in it for your customers and what’s the down side?
- What’s in it for a product manager/owner and what’s the down side?
- What’s in it for a project/program manager and what’s the down side?
- What’s in it for an individual team member and what’s the down side?
Wow! that’s a lot of questions.
As I said – you might not need to answer all of these and you really don’t want to have to write them all down but it’s worth spending a few minutes or hours considering these if you’re planning to invest your time, effort and credibility in something you believe in.
Beyond everything here, I also recommend a read of Fearless Change to help you on your way.