Ript™: Innovation and Collective Product Ownership

My co-worker Ilio Krumins-Beens and I are presenting an experience report at Agile 2007 in August. Special thanks to Jeff Patton, our champion and adviser through the submissions process!

Abstract

In 2006, Oxygen Media CEO Geraldine (Gerry) Laybourne, the woman largely responsible for Nickelodeon’s early success, partnered with her XP/Scrum development team to create a new mission and new revenue stream for her company. This experience report covers product conception through initial release of a single product. It describes how Gerry’s leadership qualities paired with agile practices to engender deep mutual trust and collective ownership over technical execution and business outcome. This unbounded collaboration provides a template for future projects at Oxygen and other organizations with innovation as part of their agile product development strategy.

Ript

Why I Blog

It’s been about a month since I last posted.

The hardest thing for me about blogging is not the writing, it’s maintaining the belief that I have something relevant to say. Despite that, I have to say writing on a regular basis helps me in my job and here’s why…

I read about a theater director who had trouble with confrontation. He imagined the muse of drama floating above him; a silent witness to his conversations. This helped him focus on those specific values he needed to champion in the best interests of his project. It’s easy to give ground but to diminish your work as an artist – humiliating.

I have no short cut for doing my job well. The best way for me to contribute to my employer is to build the most value for our end users given the resources at my disposal. End user value drives consumer demand. My reading tells me that the most productive teams are up to ten times better than the least productive and that repeatable innovation requires creative investment from line level staff.

All this implies to me that as a technical manager I need to work with talented people and foster their intrinsic motivation. In my fifteen years in software, I believe a cohesive, senior level, agile team is the best multiplier of individual talent and attracts and retains the most motivated, value-focused developers.

All that said, management is fraught with compromise and difficult conversations. Advocating agile within a company is definitely a case where the pain of staying the same needs to be worse than the pain of changing. Pain being a frustratingly subjective thing.

Reading, thinking and writing about what we owe to our peers, ourselves, our employer, those over whom we have authority, and those who use the software we make helps me visualize a muse of software development.

This muse sits over my shoulder; a silent witness to my actions. She boosts my courage. She challenges me to be humble. She draws brighter lines for me between ground I should give in the interests of peace and the ground that supports my core values and my ethical responsibilities.

Honesty, loyalty, and service

I just found out that the ambassador to Iraq, Ryan Crocker, is an alumnus of my school, Whitman College.

It’s an interesting coincidence because I’ve been thinking alot about Renee Montagne’s February 7th NPR story:

Like his military counterpart, Lt. Gen. David Petreaus, the new top general in Iraq, Crocker raised questions about the conduct of the war. Now, Crocker and Petreaus are being asked — perhaps too late — to correct it.

Crocker and Petreaus will be sent to fix the troubled post-war situation that they warned of four years ago. [Barbara] Bodine [, former ambassador to Yemen,] wonders where the United States might be today, had Crocker and Petreaus been appointed earlier in the war.
“It will be one of the inevitable speculations of history,” she says.

As Demarco and Lister say in Waltzing With Bears: Managing Risk on Software Projects, it can be futile to be the only one in the room acknowledging risk.

It really is so late.

Is it too late for professionals with relevant experience, appropriate authority and a willingness to entertain complexity?

The buck stops… where?

A fundamental value of computer ethics, agile and Scrum is truth telling.

As developers we have an obligation to provide honest feedback around decisions that affect either the quality or value of software our employer asks us to create.

I am now the senior person dedicated to software in my company. If that means anything it is that my responsibility has expanded to protect the best interests of my employer on any project we undertake that has software development dependencies.

The profound challenge in this is that while the company has expanded my scope of Responsibility it has not necessarily expanded my scope of Authority. As a mid-size, growing company we give department heads great discretion. My company is also one of many with a structural distinction between online and IT related software development. Therefore my team has no direct role in some of the most visible outputs of our company.

As a result, I cannot have true accountability for some outcomes since I cannot change them. That does not absolve me of my ethical responsibility nor allow me to narrowly define success in my current role. That is why to take my job seriously is to take on a certain amount of anguish.

The obvious answer is that I never should have taken on the role unless I was given commensurate authority. Perhaps this is correct.

I accepted the promotion because I believe it raises the profile of my team and makes more visible the quality and value return they are producing. I also believe that while responsibility without authority is flawed, it is a common state of play for those of us who introduce agile practices into a company. Let’s be honest, introducing agile is an attempt to lead change. Since I am not an entrepreneur it is a given that I will have to earn trust at each step of the way in making that change.

So given these circumstances, what is my responsibility to my employer around truth telling? Who am I obligated to tell truth to? Let’s focus on questions of value and quality and leave aside safety or legal concerns because as dramatic as whistle blowing is, that is not my reality.

Basic risk management tells me that the person who’s interests are most damaged should a problem arise owns the risk. In a functioning Scrum organization this is the product owner — or as Yahoo calls them, the single wringable neck. This one person is held accountable to the performance of a product in the market place. It is to them that any concerns over the value or quality of a software product need to be raised.

As I’ve said, I have a Scrum team but I do not work in a Scrum organization. There are times when projects originating outside my team do not have a clear “single wringable neck”. This presents a huge challenge. Who will be most affected by a problem if no single person is assigned real accountability for the outcome of a software project?

I have decided after hard experience that in circumstances where there is no responsible and empowered product owner the person most affected by problems is the person most identified with our brand and our products, my CEO. Therefore my responsibility for truth telling is to her.

This is, to me, a freeing realization for in it lies great opportunity for my company. My CEO who has proven herself to be an exceptional product owner. If anyone on the business side understands agile principles and my ethical responsibility as a software developer it is her. If anyone is capable of creating positive change in my company it is her.

Therefore, in the spirit of my CEO’s own vision, I will expect the best of people while maintaining my integrity and independent judgment to serve the best interests of my company, our customers, my peers, and our society.

Wendy and Oksana discuss pair programming

Two of our developers, Wendy Friedlander and Oksana Udovitska are taking “The Gentle Art of Pair Programming” on the road to DevTeach in Montreal on May 16th.

A description is on Scott Bellware’s blog.

Our team consistently pair programs both in the office and remotely. Oksana and Wendy’s introduction to this practice made enough of an impact at NYC CodeCamp that they were urged to repeat it at DevTeach.

I’m not surprised. They are smart and talented and a blast to work with. Such engaging personalities you might see them on Oxygen online sometime.