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.

Short link: http://jkat.me/hc8CXf

Tag(s): CEO, computing, consumer software, Gerry Laybourne, Oxygen and Oxygen, principle, product owner, software developers, Software Product Development Manifesto Building, specific solution

Comments: 1

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.

Short link: http://jkat.me/eb8GTs

Tag(s): creativity, Dave Pollard, Dean Kamen, F.I.R.S.T., management, product owner, scrum, software development

Comments: none

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.

Short link: http://jkat.me/gO9pVU

Tag(s): CEO, entrepreneur, ethics, product owner, responsible and empowered product owner, scrum, software developer, software development, software development dependencies, software product, software project, Yahoo

Comments: none

Informed Consent — “the right of each individual potentially affected by a project to participate to an appropriate degree in decision making concerning that project” (Gail D. Baura, Engineering Ethics: An Industrial perspective)

“(T)he astronauts should have been informed of the possibility of O-ring failure before the Challenger launch…” — G. Baura

Often the people asked to pay down a risk are not the ones who suffer if the risk plays out. For Challenger, this distance contributed to the sacrifice of innocents.

As developers, we must never hide risk for which others suffer the consequences. This is core to Scrum. The team tells the Product Owner anything that may affect the business outcome of a project.

Scrum’s focus on self-directed teams instills the courage informed consent asks of us. Frequent opportunities to inspect and adapt gives it voice.

However, an ethical view obligates us to more than delivering business value and we cannot entirely cede our conscience to our product owners. We have an obligation to each other, our collective reputation, the people who use or indirectly benefit from our systems, and the public good. For the most part, these interests have no informed consent on our projects.

As Agile practitioners and Scrum advocates, how can we expand our conversation and help each other exercise due care?

Short link: http://jkat.me/lZ73hD

Tag(s): ethics, Gail D. Baura, product owner, scrum

Comments: none

This is what unrealistic planning does to execution.

Here’s the scenario:

Management adopts a project plan with unachievable goals given the time, features and resources.

The team begins in ignorance of “the plan”. Initial progress represents a sustainable pace.

Visible progress doesn’t match “the plan”. Management pressures the team. Short term, the red line gets steeper.

At this point, management revises the plan adjusting the start but retaining aggressive assumptions. “Now we know what we’re doing!”

Problem is, the productivity gain is not sustainable. The team is working extra hours and skipping necessary work to declare things done.

Problem is, the productivity gain is not real. Under stress the team works to increase the measure of value instead of value itself.

So productivity stalls. The team catches up on sleep, settles into the slog, and confronts thorny problems created by messy, incomplete and untested code.

Ultimately, the team produces less than had it maintained a sustainable pace.

Assuming the people and codebase aren’t hopeless, I added a period before the end where the team returns to sustainable pace. These are the tragic days when management gives up and before they cancel.

Another scenario – similar chart:

Management adopts a business plan with unachievable goals.

The product owner becomes risk averse or fool hearty, ignoring real opportunities that won’t hit impossible numbers.

The product drifts or lurches in bizarre directions and declines.

Short link: http://jkat.me/iiQltv

Tag(s): agile, management, product owner

Comments: 1