We are currently working on a consumer software product named. I feel extremely lucky to be a part of this project as does every member of my team.
If there is a single reason for this sentiment it is the deep collaboration between our product owner and the development team.
The Manifesto for Agile Software Development asks us to value:
Customer collaboration over contract negotiation
Contract negotiation within a single organization arises in conditions of low trust. One or both parties feel they need to explicitly document expectations to protect themselves.
A low trust environment is Hobbes state of nature as practiced by the software industry. Promises are prized more than outcomes. Authority and responsibility don’t reside in the same person. Incentives are not linked to outcomes. Blame brings more consequences than failure. Success is virtually impossible. Agile practices if they can be adopted at all are simply a mechanism for failing fast which has the virtue of saving the company money and sending talented people off to hopefully more rewarding jobs at other organizations.
Rising above this coding purgatory is an organization with some mutuality of sentiment and interest. A capable development team exists and business owners are both empowered and accountable. Here the organization can aspire to partnership.
But not all collaboration is equal.
In What’s Worth Fighting for Out There?, Andy Hargreaves and Michael Fullan describe the concept of bounded collaboration:
Bounded collaboration rarely reaches deep down to the grounds, the principles or the ethics of practice. It can get stuck with the more comfortable business of advice giving, trick trading and material sharing of a more immediate, specific and technical nature. Such collaboration does not extend beyond particular units of work or subjects of study to the wider purpose and value of what is taught and how. It is collaboration, which focuses on the immediate, the short-term and the practical to the exclusion of longer term planning concern.
This concept is applicable to the software setting which, like learning, is fundamentally about knowledge creation and sharing.
Bounded collaboration exists in software when the developers do not invest themselves in the business outcome of a project. This can occur through no fault of their own if the plan is vague, not shared with them, or if their input is not invited or listened to. Some managers simply don’t consider it important that technical staff buy into the vision or features of the software they’re building.
In such situations, developers shut off part of their brains. (for those of us who love our craft, a more apt description is cauterize part of our brains)
“I’m not personally invested in the business plan or priorities but I will execute on them as you (product owner) define it. Since I have no authority or meaningful influence on the plan or priorities, as long as I produce reasonably error-free code I refuse to be judged by how the product fairs in the marketplace.”
Scrum allows for success on these terms by assigning responsibility for the business outcome to the product owner and technical execution to the team. If the product owner has a thoughtful strategy and deep insight into their customers a well-executed piece of software stands a chance.
But what price does an organization pay for bounded collaboration?
Innovation – A company that does not engage fully with its workers diminishes its ability to think deeply about a problem and to surprise itself with unexpected solutions. It therefore fails to be what Ikujiro Nonaka and Hirotaka Takeuchi describe as a Knowledge Creating Company that can sustain success through its own invention.
A television company building consumer software – that’s audacious!
Our product owner is our CEO,. This initiative is her idea but she partnered with the development team to craft the concept and feature set for our first consumer product, .
Gerry has allowed us to fall in love with the project by leading us while listening to us. She’s given us the gift of high expectations demanding that the product be original, useful, and fun. She’s treated us as peers despite the fact she holds much more authority than we do. She’s shared her excitement for the product while sharing credit for it. She’s championed her priorities while allowing us to question any and all aspects of the product. We’ve both had the pleasant experience of disagreeing and realizing the other was right.
Yes, the product owner is the single wringable neck – she’s championing an entirely new line of business at her company – but I’ve never seen a team fight so hard to get in the noose with her. That’s trust.
To quote Jeff Sutherland, “Great scrums require great product owners.”
I’m presenting a paper, Great Scrums Need Great Product Owners, at the Hawaii International Conference on System Sciences.
The presentation is part of the Agile mini-track co-chaired by Jeff Sutherland and Hubert Smits. I co-authored the paper with the senior member of my product team, Ilio Krumins-Beens.
We survey literature to describe pragmatic and collegial relationships which satisfy the definition of collaboration and honor roles while barely tapping or actually working against the potential of a project and its participants. These limited forms of collaboration are common not just in our industry but within agile projects.
A common interpretation of the call for a single Product Owner is that the development team itself should play little part in shaping the vision and value priorities of a product backlog, focusing instead on efficient delivery of those priorities.
One of our major sources are the What’s Worth Fighting for series by Andy Hargreaves and Michael Fullan on collaboration in education.
The disempowering climate faced by teachers is a direct parallel to that faced by software developers disengaged from the business vision and value priorities of their work.
“â€¦ [W]e have collectively 45 years of teaching experience and nobody has ever asked us our opinion about anything where it would actually be put into action. And yet I’ve got to have more experience with junior [children] than a lot of the people who are telling me what I should be doing with them. And I think that is very frustratingâ€¦ I think I could help bring a lot to it and nobody ever asks, no one ever asks what we think. They just go ahead and proclaim and we have to follow.”
Its tragic how talented, experienced people are not allowed to bring their full selves to their work.
We contrast this with unbounded collaboration between a product owner and team. In unbounded collaboration an individual’s contribution is not constrained by their role or status.
It is a collaboration built upon high-performance, mutual respect and deep trust. The product owner walks a tight rope, engaging the team in an evolving product and business plan while guiding the project toward her vision and high-level goals. The team is passionate about the product they are building and feel personally accountable to the product’s success.
We argue that this kind of collaboration is at the heart of agile values and is a characteristic of the knowledge-creating companies upon which lean principles are based.
I’ll write more about unbounded collaboration, it’s opposites, practices we’ve used and what we’ve learned.