Tag Archives: scrum

Ript™: Innovation and Collective Product Ownership

Posted on by

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

The buck stops… where?

Posted on by

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.

Learned Helplessness

Posted on by

Dave Pollard has an interesting post, From Simplistic Thinking to Embracing Complexity.

On attempts at knowledge creation that don’t engage employees and customers…

such systems presume ‘learned helplessness’ of customers and employees: The customer, the citizen, is often viewed as a mere, passive consumer of your organization’s products and so-called wisdom. The employee, likewise, is assumed to be ignorant, stupid and disinterested in the success of the organization beyond his/her own job. Most people don’t take kindly to having their intelligence insulted. And failure to engage customers and employees in co-producing the product is a tragic waste of great opportunity.

Learned helplessness. Yup, that about sums up what it’s like to work for a product owner who refuses to let the team invest in the vision of a product. Complexity and invention don’t lend themselves to command and control.

There are individuals like Dean Kamen with a singular genius for invention. Still he emphasizes the value of collaboration – of sensitivity to others and society. His F.I.R.S.T. foundation celebrates the whole individual engaged with others in a technical challenge and the ethic of Gracious Professionalism.

It’s a way of doing things that encourages high-quality work, emphasizes the value of others, and respects individuals and the community.

Agile software development values collective ownership. However, there is shared code and there is shared risk and shared reward. When a FIRST LEGO League Team wins, I’m sure it’s not a single 14 year old product owner who accepts the prize.

For a development team to contribute beyond the bounds of technical execution, i.e. “his/her own job”, product owners need to approach them

…through conversations, stories, and presenting the ‘problem’ to them so they can help you appreciate it better and then address it. – Dave Pollard

Embracing complexity is about engaging the whole person not just the coder. With the person comes life experience, passion, and imagination. As product owner, use your authority to break through indecision but avoid the desire to tell the team how to solve your problems. Describe what you are trying to accomplish and why it is important. Get the team in touch with the customer and let them help you.

The result will be more than the formulation of a single mind. It will be more what the customer needs and, perhaps, it will be unlike anything else out there.

Trust, the Product Owner, and the Team

Posted on by

KnotWe are currently working on a consumer software product named Ript. 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?

Knowledge Creating CompanyInnovation – 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, Gerry Laybourne. This initiative is her idea but she partnered with the development team to craft the concept and feature set for our first consumer product, Ript.

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.”

Context Switching

Posted on by

My team is currently working on two very different programs by pulling work off both backlogs into a single sprint. We did this for pragmatic reasons having to do with our size and the wishes of both the product owners and the team. This was working well when the two programs were clearly defined projects. However, we’re going through a rough patch with one program driving maintenance work and the other rallying towards release. We’re paying a price for context switching with lower point commitments overall per sprint.

Inspect and adapt.

The Washington Post published an article by Lori Aratani, Teens Can Multitask, But What Are Costs?

When subjects were focused on sorting, the hippocampus — the part of the brain responsible for storing and recalling information — was engaged. But when they were multitasking, that part of the brain was quiet and the part of the brain used to master repetitive skills — the striatum — was active.

The Journal of Experimental Psychology published a paper by Joshua S. Rubinstein, David E. Meyer, and Jeffrey E. Evans on Executive Control of Cognitive Processes in Task Switching. As an APA release summarizes:

…subjects lost time when they had to switch from one task to another, and time costs increased with the complexity of the tasks, so it took significantly longer to switch between more complex tasks. Time costs also were greater when subjects switched to tasks that were relatively unfamiliar.

Neither the article or paper distinguish results by gender. The First Sex says that according to gender specific studies women are better multi-taskers than men.

I bring up the gender differences because I work at a women-owned company. One of the benefits is seeing the world from my CEO’s point of view. Sometimes not identifying differences between men and women denies women opportunities, or worse, perpetuates harmful stereotypes. As a society, we are late to acknowledge that women present with heart disease differently than men. This has perpetuated a myth that heart disease is a male illness.

“(A)ccording to the American Heart Association (AHA), more women than men die from heart disease in the U.S., and 1 in 3 women is living with it today” – TIME Magazine

If women are truly better multitaskers, maybe they have some inherent advantages in certain kinds of jobs (like mine 🙂 ).

Both the men and women developers in my team have acknowledged that the context switching penalty has gotten worse recently. So whatever the difference in this case, some kind of scrum master response is required.