Tag Archives: product owner

Yet Another Manifesto

Posted on by

When we set out to build consumer software, I pulled together sentiments from our CEO, lessons learned, and principles behind the Agile Manifesto into our own set of principles.

Since I’ve already received permission from my employer to publish it in a paper, Agile Practices and Innovation, I thought I’d include it here.

Oxygen Software Product Development Manifesto

Building consumer software is a joyous and daunting challenge. We, software developers, owe Oxygen and Oxygen’s customers every chance at success. We believe success springs from the following principles:

It’s all for the end user

The most important relationship is between us, the people building these tools and the women and men who are our customers. We must continually refine our products based on ever increasing knowledge of our customers.

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. — http://agilemanifesto.org/principles.html

People own their identity and information

We respect our customers. We respect their privacy. We believe people own their virtual selves.

To that end, we will never misuse data, we will always provide a way to keep personal information private, we will always give our customers a way to export their assets and remove their identity from our systems.

Each tool we build helps people do a specific thing better than anything else available

Build the best solution for a specific need felt by a broad range of women.

Build simple tools that are useful, elegant and fun and go from there

First build a specific solution and then abet our customers using that tool in ways we never imagined.

This is both a cause and a business

We must remember that this is a business proposition. As our products evolve, we need to understand the revenue models and targets. We need to help define and measure appropriate metrics. We need to do everything we can without sacrificing the other values in this manifesto to achieve the business aim of the company.

Gerry Laybourne is the product owner

If our most important relationship is with our customers, our most important collaboration is with our product owner. Gerry sets our priorities. She must embrace what we are doing. Our relationship must remain direct. The best way to convey information is face-to-face.

These tools spring first and foremost from Gerry’s imagination. Direct connection between Gerry’s vision and our team’s creative efforts leads to success.

We are inventors

We must imagine solutions outside current limitations and ask ourselves, “what of this can be done now”. We must build something never seen before that when handed to the right consumer feels inevitable and obvious.

We must engage creativity, empathy with our customers, resolute professionalism and an inspired sense of play.

If we don’t love our inventions, no one else will.

We have authority, we are responsible, we are accountable

We are a self-organizing team in the best spirit of Agility.

If we, the people doing the work, allow this project to drift from its founding principles it will fail – with consequences for all concerned. In the face of that possibility, we must have courage to speak truth to power.

Specific technologies and mediums are just tools. Get over them.

This project is about helping our customer get more out of computing and making a profit for our company. We must not let assumptions or affection for specific tools, technologies and platforms on anyone’s part distract us from our mission.

Admit failure and move on

Resources are limited. Set specific, measurable goals. Face the truth and course correct. Don’t knowingly waste time or effort. Don’t use lack of knowledge as an excuse for wasted time or effort.

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

When Should a Chicken Dive in with the Pigs?

Posted on by

I started talking about the manager’s role in scrum as facilitating a series of conversations between the team and the larger company.

The first of these is the product owner and the team.

As a manager, I have to constantly remind myself I’m a chicken, not a pig. My main responsibility is to deal with issues escalated to me by my scrum master. I also coach around practices. This is often about challenging team members to find their way towards our expressed values and principles.

On occasion, I do intervene in the dev room. This is dangerous ground. Innovation springs from the ability of an organization to surprise itself. Such creativity finds its source in autonomy, accountability and necessity.

Software development doesn’t proceed down straightforward path. For each unexpected problem there is a wealth of possible solutions. Ingenuity can add wasteful complexity or differentiate and define a product. You want a team to keep momentum but you want them to think deeply.

I need my team to be open to the problems before them, purposeful and playful in devising solutions but determined to release. This takes more than good work for good wages and it’s profoundly more than good leadership from managers. Project success has to be the individual team member’s success. Tomorrow’s intellectual property is not code yet to be written, it’s the inventive potential of the coders.

If I step in therefore it should be to maintain personal investment and esprit de corps rather than to reverse any individual decision. I have a scrum master and I rely on him to maintain morale and productivity in sprint reviews and planning. Still, with my experience as a developer and unique observer role, I’ll intervene in conversations between the product owner and the team to:

  • dispel misinformation
  • surface contradictions
  • flag intractable disagreements

Misinformation is toxic to the product and individual accountability. A misinformed team builds the wrong product. A pattern of misinformation leads a team to lose trust. They will focus on not failing in their narrow scope of execution rather than a successful business outcome. Playing safe eliminates surprise and invention and ultimately leads to failure.

Contradictions create opportunity. A solution that addresses both a value and its antithesis such as high quality and low cost can differentiate a product.

Some disagreements cannot be solved by conversation. Time and more information may resolve the conflict. Sometimes disagreements simply need to be acknowledged. In the spirit of “any decision is better than no decision”, the product owner or scrum master needs to be encouraged to move in one or other direction despite dissensus in the team.

All of this assumes the project in question is healthy. Intervention into a troubled project is a different animal [see my earlier post on stopping the line].

The Manager and Scrum

Posted on by

Jeff Sutherland posted notes from an open space hosted by Jens Ostergaard on Nov 2006. The subject was the role of manager in a Scrum.

  1. provide strategic vision, business strategy, and resources,
  2. remove impediments surfaced by Scrum teams that the teams cannot remove themselves,
  3. ensure growth and career path of employees, and
  4. challenge teams to move beyond mediocrity

For me, introducing agile practices has been evolutionary not revolutionary – five years work, three title changes and counting. My role is to make sure the team’s accomplishments build towards something progressively more and more valuable for the company and the individual team members.

In my experience, this involves facilitating a conversation between the business and the team on at least three levels:

  • Product owner and product team,
  • Organization and employees, and
  • Leadership’s grand vision and the team’s accomplishments.
The Oxygen team and management

[the oxygen team and management]

I’ll go into this in more detail in later posts.

Product Owner Change – Stop the Line!

Posted on by

What do you do when the fundamental assumptions behind a software project change mid-stream?

My experience before adopting agile practices was people often plugged away at the original plan drifting farther and farther off course.

I’ve been on projects that failed simply because no one had an honest conversation about who had authority to drive changes. How many of us have built something only to have the launch postponed because a senior executive got their first look and over-ruled their under-powered product manager? How many of us have had a project declared failure as a result? How many have seen work shelved? Me. Me. Me.

I’ve found Scrum does a great job of surfacing these issues and forcing the team to deal with them. Product owner is being over-ruled? Sprint integrity not being honored because interruptions and changes? Believe me, a performing scrum team will raise the alarm as quickly as this occurs and force a conversation about who is the product owner and what are the criteria for success.

One possible result? “Stop the line” interrupting the current sprint. Meet with the relevant managers and make the person setting feature priorities accountable for the backlog and the business outcome of the project. Plan a new sprint and re-commence work. The cost of mid-sprint changes is made explicit and responsibility is aligned with authority.

This can benefit everyone. First, the hidden product owner now has the regular feedback and control that reduces the urge for mid-sprint intervention. Second, the team knows who to rally around and why. Third, difficult conversations about what is driving changes and what defines success for the project happen earlier rather than later.

I’m not saying that these changes ensure success. Honestly, a project with mushy business ownership and vision is troubled. What I am saying is that with frequent inspections and a culture of honesty these seeds of failure become very clear to everyone much earlier.

I’ve found that once a team becomes used to satisfying the customer with early and continuous delivery of valuable software. They fight like hell rather than get caught in a familiar pattern of failure.