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 Groupare 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?
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.
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.”
I am ambivalent about the Scrum community’s focus on process and tools.
Yes, it is this effort that has driven adoption and created an economy for us practitioners. But adoption is yesterday’s challenge. We’re kind of winning that one.
We need to place less emphasis on getting new organizations to try Scrum to more on getting existing teams practice Scrum better.
- Where reliable software delivers monetary return to sponsors because it is truly valuable to end users.
- Where individual contributors are allowed to bring their most creative effort to the workplace to the benefit of both employers and end users.
- Where workers are allowed to live rewarding lives outside the workplace to the betterment of their families and communities.
Not just exceptional productivity – ambitious enough as that is — but exceptional productivity to a genuinely productive end.
Life is full of compromise but if that is not the aspiration — to fill our careers with as much of these achievements as possible — then why bother?
Why spend money on training and tools to deliver more waste on short, iterative cycles?
Why extract more lines of code that no one will test or use but only spend money to maintain?
Why use the Scrum process to perpetuate the alienation of the knowledge worker from their work?
Mastery means taking responsibility for ourselves and our peers. Grasping our practice is the sum of our intentions and actions in the service of something.
So here’s my plea to shift the conversation back to it’s roots.
“Agile” is about the material and human good we create when we respect our co-workers tell truth to our employers, strive to improve, and care for the people affected by the software we help build.
We use a tool or process to the degree it furthers that end and no farther.
Here is a draft handout from my presentation at “Agile NYC”, Instilling Agile Values for Creativity, Self-Improvement and Organizational Change – A Manager’s Perspective.