Features Are Job One

The continuous, visible, delivery of features as specified by the customer. A common outcome is to take on ten and complete 95 percent of each of them. In terms of delivering visible features, it is better to have completed nine and LetOneGo. Deliver nothing, or deliver something. BusinessValue is what customers are looking for.

Summarized from http://www.xprogramming.com/xpmag/rtfMaximizeEachIteration.htm

Might we instead say that Capabilities are Job 1? A large and growing number of features can be the enemy of simplicity and the enemy of utility.

Capabilities are skill 1, growing numbers of features in lists are the product of poor design and failure to reveal intentions via specification. Note the job 1 indicated in the introduction is delivery of specified features.

CustomerFeedback? (aka Profit) is Job Zero.
Quality is Job One.
Features are Job Two.

It ain't about features, it's about profit from end-users using our code. Like the parable at SharpenTheSaw, saying that more features is better is like saying the more strokes needed to chop down the tree, the more progress we made.

--PhlIp

(And "CategorySuccess" is reminding me of those spoof "Followership" posters with a troop of penguins following the dumbest one...)

It reminds me of a certain flavour of smarmy, kitschy, condescending, reality-avoidance business babble of the kind promulgated by overpaid suits with titles like "Corporate Culture Consultant," and distributed to every employee in glossy pamphlets that nobody reads except for a laugh, but which are generally followed up with an email from the Vice President of Nothing in Particular exhorting everyone to read this Very Important Document, because we're now a "Success Oriented Company" -- as if we were a Failure Oriented Company ten minutes before the brochure was sent out... perfect example of what LeadingQuietly is all about, success is in the doing, not the saying.

Luxury. I used to hang awake at night, dreaming of being given glossy phamplets promoting quality... --PhlIp

Those who achieve success are doers, not followers. Since according to some figures, nearly 80 percent of software projects fail.

SharpenTheSaw is a metaphor for plan ahead. Those who wish to succeed with the minimum of effort are found producing intended results. This they do by application of appropriate talent and resources to make sure ItWorks. --CorporateCultureConsultant

SharpenTheSaw is a metaphor for planning by sharpening your tools, not guessing the future.

SharpenTheSaw is a metaphor for enhancing the usefulness and efficiency of tools, whether for immediate or future expected use.

Creating a page entitled "FeaturesAreJobOne" takes the article cited above out of context. In the context of the article, FeaturesAreJobOne makes sense. It's about implementing features that the customer agrees are needed within a given iteration, but what if there isn't sufficient time to complete all the features? Then it's better to fully implement (say) nine out of ten features than implement 95% of all of them. In other words, some complete features are better than no complete features, hence (completed) features are Job One. It's a principle to be applied in a certain circumstance, not in all circumstances.

I'm wondering if another title mightn't be better. I'm also wondering whether summarising xprogramming.com articles here has any point. -- DaveVoorhis

Wiki Page Titles are many things, but accurate portrayal of an ongoing exchange and dialogue isn't one of them. The point wanted here is the establishment of plan and priority, and in the definition of success as 100% complete. Even if the completion is but a part of the whole, success can be celebrated and the project can move forward. It is an attempt to reverse the 20-80 success/failure rate by emphasizing successful deliveries over that of clever methods that promise much, but deliver little.

Okay... But what does this page do that http://www.xprogramming.com/xpmag/rtfMaximizeEachIteration.htm doesn't?

It introduces successful achievement as something to be celebrated by those involved in the accomplishment, not simply the mark on a progress chart. It emphasizes success as completion of a intended deliverable. It emphasizes achievement as the result of focus and concentration on what can be done while recognizing the need for reframing what remains to be done. It provides a wiki platform for discussion.

Fair enough. The last sentence sold me on the idea.

As the person who asked the original question, my point was not that there's anything wrong with the ideas presented, just the connotations of the language chosen. In my mind, "feature" conjures up "stuff" in the application (buttons, forms, menu items, tables, APIs, etc.). I think the language we choose should emphasise maximization of what the customer is enabled to accomplish rather than thingies to try to accomplish stuff with.

Indeed. I think CompletedStoriesAreJobOne would more effectively capture the essence of the cited xprogramming.com article.

MayZeroSix

CategorySuccess