From John Maeda’s SIMPLICITY, a real life parable about a scientist and his devoted assistant:

“…great people know how to take care of their people. For a great person does not become great by themselves.”

Read the full post.

Posted: January 21st, 2008 under Uncategorized.
Comments: none

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.

Posted: March 10th, 2007 under Uncategorized.
Comments: 1

SD Times has a brief item on the Standish Group CHAOS Study update. In 2006, 65% of sampled software projects were canceled, significantly late and/or over-budget. Over ten years of thought and practice have improved our success rate by a meaningful but disappointing 19%.

Business execution shares more than equal credit for our state of play. Four of the first five Standish Group project success factors are engaged, empowered and pragmatic product management.

There will always be a background failure rate no matter how excellent technical execution becomes. Things change and opportunities involve risks. Some well-executed projects will always fail to pan out. Still, 65th percentile is a mean aspiration.

I haven’t met a talented developer or development manager who wasn’t obsessed with self-improvement. Yet a focus on self isn’t enough. Standing out in the crowd may benefit individuals but it diminishes our craft. The failure around us lowers the hopes of society for what we can achieve.

Principle 7 of The IEEE Computer Society Code of Ethics says we should:

7.07. Not unfairly intervene in the career of any colleague; however, concern for the employer, the client or public interest may compel software engineers, in good faith, to question the competence of a colleague.

Inferior work embarrasses me. Behavior that perpetuates inferior work infuriates me. But when should we step beyond criticism of code to criticize those who author it? First, in good faith we should search our motives for self-interest and vanity. Opportunism is bullshit. Bullshit devalues truth. Bullshit destroys trust.

Ultimately we have a responsibility to protect the interests of those who pay us and the larger community who benefit from our efforts. We have a responsibility to society and the reputation of our industry upon which our potential to contribute to society depends. It’s our duty to find a way of expressing criticism that stands some reasonable chance of benefiting those interests.

Easier said than done where a power imbalance exists. As Ken Schwaber says in Agile Project Management with Scrum, “A dead sheepdog is a useless sheepdog.”

With all that to balance, how do we sleep at night?

Posted: February 28th, 2007 under Uncategorized.
Comments: none