Bottom-Up Change: The Agile Manifesto at 10

The most enduring and most people-positive change starts at the bottom: Bottom-Up Change. It starts with the few, then spreads to the many.

People-positive change is change that benefits the common good. The principles of the Agile Manifesto have improved my professional life as a software developer.

Individuals and interactions over processes and tools

Agile Manifesto Turns 10

17 software developers convened in Snowbird Utah in 2001 to discuss lightweight development methods. Out of the Snowbird meeting came the Agile Software Manifesto.

The manifesto is a rallying cry: it says what we stand for and also what we are opposed to.
~Martin Fowler

Full Disclosure - Considering the arc of the Agile phenomenon, I am a newbie. The only reason I might have been at Snowbird in February 2001 was to re-live a romantic notion of myself as a ski bum. The truth is, I knew nothing about Agile methods until I joined a David Hussman coached team in 2006.

The advent of the 10th anniversary of the inception of the Agile Manifesto next February has me probing the nature of change and revisiting the stated principles in the manifesto.

The Nature of Change

On change, Nathaniel Branden said

The first step toward change is awareness. The second step is acceptance.

Did Branden miss The Movement? Did he miss some steps before acceptance?

1. Organization - Convening & engaging like-minds to rally around change;
2. Inspiration - Inspiring first followers to virally grow change.

The most enduring change germinates at the bottom. The old saw

You can lead a horse to water, but you can't make it drink

means people, like horses, will do what they have a mind to do. Directives, top-down plans, and top-down change rarely endure.

Shoehorning Agile

Agile doesn't scale particularly well. People-centric principles in the Agile Manifesto fall by the wayside in the ponderous, profit-take-all organization. Agile principles like customer collaboration or individuals and interactions are summarily ignored in ponderous organizations because there's ostensibly cheaper developers to be had in remote locations. That your organization dictates the use of cheaper developers, is a smell.

There are exceptions. To be sure the challenge of Scaling Agile has stoked an industry for consultants, coaches, and charlatans. But it's a fools game.

Shoe-horning Agile into the ponderous, profit-take-all organization often - some would say inevitably - leads to a twisted Agile Lite bastardization where people must make do with sub-optimal conditions and where

process & ceremony trump humanity and practicality

Sub-optimal constraints are today's reality. But at what point does leaning on people to absorb and adapt to sub-optimal constraints lead to diminished returns?

Dictatorships and oligarchies have been proven untenable time and time again. It seems Agile principles are at odds with current corporate charters.

Thinking Forward

The ponderous organization's resistance to transformative change and transformative learning appears to be peaking. The antithesis of the ponderous organization, the Lean Startup, is gaining momentum. Lean startup principles are rooted in transformative learning.

Resisting transformative movements is unstable.

It is not necessary to change. Survival is not mandatory.
~W. Edwards Deming

Lasting change and people-positive movements start with passionate people, then infiltrate into the cadres of controllers that infest ponderous organizations. Movement is sparked by passionate people who organize and inspire; not by cadres of controllers.

Agile at 10 years is a double-edged phenomena:  People continuing to do transformative work, and a growing numbers of ponderous organizations paying lip service to change.

A Primary Directive

Michael Pollan's brilliant TED talk asks that we consider that human consciousness might not the crowning glory of Darwinism -- a humbling notion, particularly to those who insist on clinging to the slippery pedestal of human exceptionalism.

Other species have developed refined systems for foraging, attracting, defending, and, in short, optimally surviving with the least expenditure of energy. We ignore these wonders of cut-throat evolutionary optimization to our detriment.

Seeing an organic and undulating cloud of starlings dancing in the sky, I can't help but wonder about how people work together.



Observing schools of fish, flocks of birds, or a stalking wolf pack, I wonder what we can learn from other species.

In the Harvard Business Review post The Five Habits of Highly Effective Hives, Biology professor Thomas Seeley draws from his study of honey bees to suggest ways teams might build consensus and make better decisions. Seeley suggests:

1. Remind the group's members of their shared interests and foster mutual respect, so they work together productively. The scout bees know instinctually that their interests are aligned toward choosing the optimal home site, so they work together as a team. There are no clashing curmudgeons in a bee swarm.
2. Explore diverse solutions to the problem, to maximize the group's likelihood of uncovering an excellent option. The scout bees search far and wide to discover a broad assortment of possible living quarters.
3. Aggregate the group's knowledge through a frank debate. Use the power of a fair and open competition to distinguish good options from bad ones. The scout bees rely on a turbulent debate among groups supporting different options to identify a winner. Whichever group first attracts sufficient supporters wins the debate.
4. Minimize the leader's influence on the group's thinking. By functioning as an impartial moderator rather than a proselytizing boss, a leader enables his group to use its combined knowledge and brainpower. The scout bees have no dominating leader and so can take a broad and deep look at their options.
5. Balance interdependence (information sharing) and independence (absence of peer pressure) among the group's members. Only if ideas are shared publicly but evaluated privately will the group be good at exploring its options and making good choices. Scout bees share freely the news of their finds, but each one makes her own, independent decision of whether or not to support a site.

When we have a common interest, people can be efficient collaborators. Scout bees have an evolutionary advantage in community collaboration. That is, bees know instinctively to search for a new hive location that is

10 meters off the ground and has 40 liters capacity. 

Eons of optimization baked into their DNA, scout bees know instinctively what their primary directive is (i.e., what's most beneficial to the survival of the community).

A Primary Directive

Honey bees have a clear understanding of the criteria for success. Not always so for people meant to collaborate on teams. On software teams, we rarely have a concise expression of the purpose or the desired end state (cf. Team Decisions & Commander's Intent).

At a recent Practical Agility gathering orchestrated by David Hussman, Mary Poppendieck scoffed at the mention of self-organizing teams. It struck me as gratuitously dismissive. Drilling down I was able to determine her derision was based in that observation that, unlike other species, people working on software teams don't intuitively know what their most immediate directive is. That is, we rarely know what to do next. An important point.

Having 10 meters off the ground and 40 liters capacity baked into your DNA is quite different from a software team, with varying levels of commitment, discovering what it is they are to build. Still, I'm taken by the prospect of observing and learning from the collaborative successes of other species.

The UX of Desire

The Botany of Desire by Michael Pollan gives a compelling perspective on how desirability determines viability and how plant species have thrived by co-evolving with humans. Michael Pollan's insights are wildly applicable to software User Experience (UX).

Pollan begins with the premise

Design in nature is but a concatenation of accidents, culled by natural selection until the result is so beautiful or effective as to seem a miracle of purpose.

He demonstrates how four plants have survived through adaptation, and have ultimately thrived by capitalizing on human desires and needs:

• The Apple - exemplifies our desire for sweetness & intoxication (apple jack),
• The Tulip - exemplifies our desire for beauty,
• Marijuana - exemplifies our desire for pleasure, and
• The Potato - exemplifies our need for sustenance.

Human Desire & Software

Facebook grew from an idea in a Harvard dorm room to over 500 million active users in a hand-full of years (cf. Facebook Timeline). My hunch is that Facebook's popularity is based on its appeal to human behavior and its fulfillment of human desires. That is, by tugging at our narcissism, our curiosity and our instinct to connect with others, Facebook enables us:

• to know what our friends, and would-be friends, are saying & doing, 
• to surreptitiously learn more about particular love interests, 
• to be flirtatious within a socially removed virtual cocoon, or simply 
• to be noticed.

The Botany of Desire reversed my bias about humans domesticating plants like corn or apples or cotton. Perhaps it was the other way around - could it be that the plants domesticated us? Plants have, at the very least, used humans to co-evolve and thrive.

I now think of my killer app as a "species" co-evolving with humans. Future startup software might well have to be every bit as cunning as a Venus Flytrap. Our software must provide the sensory lures, then deliver on needs. Future apps might well be like successful plants -- spawned by and grown by adaptively fulfilling specific human needs in a survival-of-the-fittest environment.

The Lean-Startup approach seems a fitting platform for the evolutionary experimenting that future killer apps might require. Lean-Startup is rooted in the principle of iteratively adapting and refining a business model (i.e., an evolutionary concept), based on proving the viability of features (meeting needs that customers desire).

INot only will killer apps have to provide features and fulfill needs, they will also have to present desire fulfillment in an alluringly positive experience not unlike a flower's nectar lures and intoxicates a honey bee to better serve the flower's ongoing reproductive purpose.

The UX of Desire means attracting and delivering (...so beautiful and so effective) as if the life of your app depended on it!

It's People, Not Machinery

Before we learned Toyota doesn't know jack about software, the software community embraced Lean Manufacturing hoping to mimic Toyota's legendary quality & efficiency.

In her post Creating a Mess by "Eliminating Waste, Esther Derby reminds me how principles built on assembly line manufacturing efficiencies don't necessarily translate to people-centric businesses like software.

...any tool can and will be misapplied. This is especially true when a tool is plucked from one context and applied in another and when the use of the tool is divorced from the thinking and philosophy behind the tool. ~Esther Derby

Bill Clinton's advisor James Carville coined the phrase

It's the economy, stupid.

In the same vein, I advance a rule of thumb about the making and consuming of software:

It's people, not machinery.

The simplest caution I offer is "…start by understanding", not by applying the tired bromides of manufacturing efficiency.

Lean's three-legged stool of waste, overburden, & workload unevenness are more readily measured and tweaked in the context of machines and assembly lines — not so easily with people.

Yvon Chouinard, founder & visionary behind the outdoor equipment company Patagonia, has a mantra "Let my people go surfing" which is shorthand for

My business is focused on the fulfillment of my employees, and by extension, the fulfillment of my customers.

Encouraging your teammates to ditch work when the surf's up is distinctly not a production-driven view that activity equals cost.

I cringe when referred to as a resource. I'm not a lump of coal to be burned. The phrase "efficient use of resources" is much less offensive to me when applied to carbon-based fuel than when applied to people.

Over-clocking a CPU & demanding higher output from people probably doesn't overlap on any Venn diagram.

If it’s your job to nag me to cut waste, I'm left to wonder how and why you exist.

As a teammate, you may lean on me. But as a misguided efficiency weenie, please don't Lean on me.

Facing the Software Music

As a software developer, I am fortunate to live in the Twin Cities. I participate in monthly, after-work, software Jam Sessions and Practical Agility Sessions hosted by DevJam. These sessions are produced and deftly facilitated by David Hussman. Malcolm Gladwell, author of best-seller The Tipping Point, would identify David as both a Maven and a Connector.

To the uninitiated, imagine these sessions as book group gatherings for software producers and heads-down programmers, but without the herbal tea and cranberry scones.

The Vibe

The sessions are held in a cavernous subterranean space below an independent coffee shop. The subterranean walls are festooned with vintage rock posters and late 20th century kitsch. The garage band vibe is palpable.

The Playlist

We don’t actually produce software in these sessions. For participants, these sessions are pre- and post- production events (to carry the music metaphor). We talk about our gigs as programmers, software producers, and coaches. Discussions are lively.

The Format

We use David's brand of Fight Club discussion format. I have never seen the movie Fight Club, but I understand it is about insomnia, aggression, and an underground fight club used as radical psychotherapy. I don’t know if that describes our Mötley Crüe, but I dig the kinship with a cult flick.

I'd guess that about 50 or so people show up. Many are regulars, but each session welcomes Fight Club newbies.

In this fight club, one or more participants tee up a discussion topic with a 5-10 minute lightning talk. After the lightning talk, we break to imbibe, socialize, and to write a few leading questions about the topic at hand on index cards.

Our questions will be fodder for the ensuing fight club.

The Venue

The physical space is one key to the vibe. There’s a platform in the room raised a foot off the basement floor. All sorts of recycled library chairs, bistro seats, grungy sofas, and a bank of velour theater seats are distributed about the platform.

The platform is metaphor for both performance stage and fighting ring. The visual is basement-level darkness interrupted by colorful lights and strings of LED bulbs.

How It's Done

Six stools are placed on the raised platform.

Five people begin by sitting on a stool, leaving one stool open. One person will read one of our questions off an index card. Discussion begins.

The audience may not speak to those holding court on the platform. If an audience member wishes to contribute to the discussion, he or she must jump up on the platform to perch on the open stool. Simultaneously, one of the five people must exit the platform. There are always five people discussing the question at hand. And, there's always one chair at the ready for dissenting or consenting views.

People are experience rich and theory poor.
~Malcolm Gladwell

Each question is alloted about 10 minutes of discussion, then we vote yay or nay to continue the discussion, or move to another question.

Often I don’t know if I want to jump up to express an opinion, show off my understanding of something, or jump on stage to lay down some guitar licks on an imaginary Jimi Hendrix tune.

Social Milieu

Our theater of discourse makes for interesting amateur sociology. Among other things,

1. There's No Limit. There’s no limit to how many times one can jump up on the platform to grab a stool to speak. So if you’re an irrepressible windbag, with no sense of communal fairness, it’s your shining moment in the spotlight to grate on those with measurable Social IQs.
2. Who Steps Up? When something needs to be said, who steps up to say their piece? To defend or to shred? Who's eloquent? Who's milk toast? and
3. Who Steps Down? When someone leaps to the platform, the audience is left to wonder who will step down. There’s no squatting-length rule. Sometimes a person has just grabbed a stool, and hasn't had a chance make a peep (let alone opine), yet feels compelled to step down to allow room for an unheard voice.

Characterizations

We have some oddball characters, in the best sense, and several character types. I identify with several of the character types, and I borrow a few character descriptors from Malcolm Gladwell.

Do you recognize yourself in these?

• The Stoolies. Stool Monopolizers, or Stoolies for short, are of the genus homo wind bagus. They hog the stage stools to pontificate via verbal air-guitar. Stoolies are widely suspected of having soaring IQs, coupled with demonstrably low social IQs. It's widely held that the consistent wind emanating from their pie-holes precisely offsets the collective suck of black holes in the universe.
• The Mavens. Mavens are the generous, unassuming people whom we all rely on to connect us to new information and helpful technology tips. Gladwell says mavens often spark word-of-mouth epidemics due to their capacity to enthusiastically communicate often complex concepts.
• The Salesmen. Gladwell identifies these persuader-types as charismatic folks with serious negotiation chops. These hucksters could convince Microsoft's chief curmudgeon Steve Ballmer to learn Objective-C and code up Hello, World on a Mac Book.
• The Jesters. These are humble people with a sense of humor, and a sense of irony, who generally speak from anecdotal experience. I fancy myself a jester, but admit I might lack the requisite humbleness.
• The Minutiae Mongers. Minutiae mongers can’t avoid auguring into the abyss of marginally relevant detail. For these poor sots, it's as if waves of staccato detail possess them like an involuntary tick.
• The Questioners. These are the peeps who, when questioned, tend to ask another question; another question either to spark discussion (positive) or to inadvertently deflect direct challenge (negative). I might be one of these, but if so, it would only be to mask an acute impostor-complex.
• The Meek. Occasionally the meek bound upward to seize a stool only to be overcome by stage-fright, then simultaneously overwhelmed with anxiety. In this pitiful state, the meek are incapable of expressing what might have been the most profound statement of the evening. Our loss.

I wonder how other software communities face the software music. Do others have their ideas about producing software lauded, shredded, or scrutinized by peers?

Thank you DevJam. 

Startup Pivoting & Software

What is Startup Pivoting?

As Alan Cooper says in To Pivot, Or Not To Pivot,

When a startup company discards Plan A and moves on to Plan B, it is called a "pivot."

The Lean Startup approach suggests that entrepreneurs use the Lessons Learned from the inevitable failure of Plan A to adjust their business model. An iterative approach that rapidly continues until the business model proves the viability of the idea.

In the context startups, pivoting is a term coined by Eric Ries. Pivoting is when, through a series of small-scale trials (hypothesis testing), a startup moves incrementally toward a better business model.

Each failed trial causes a pivot point where some element of the business plan is tweaked (e.g., customer segment, feature set, positioning).

Does Pivoting Apply to Iterative Software Development?

I propose that we - the iterative software development community - think of each release of new features as a business proposition and an opportunity to Pivot, much like a lean startup. Then, ask

• What is our feedback loop with our customers?
• Would our team modify a feature based on negative feedback?
• Would our team roll back a feature based on negative feedback?

Further, I challenge the iterative development community to think of meaningful measures of the value of a new feature, whether value is measured by revenue generated or by the coolness buzz created.

Beware of Shadow Beliefs

One term I learned from Eric Ries is Shadow Belief. Shadow beliefs are the closely held, somewhat notional beliefs and assumptions that frequently sink good-intentioned entrepreneurs. All of us fall somewhere in the continuum of delusion, particularly those under the spell of a great startup idea or cool software feature.

One shadow belief is We know what the customer wants. Another shadow belief is Advancing the plan is progress.

Hypothesis Testing & Software

What is Hypothesis Testing?

Hypothesis testing is used by Eric Ries in the context of the Lean Startup. Hypothesis testing encompasses:

1. Proposition - for example: How many users will pre-order our product?
2. Test - e.g., a website with a picture of the product and an accompanying pre-order button.
3. Results - Evaluate the number of pre-orders.
4. Action - Refine the test (e.g., A/B testing or different market segment) or tweak business model (see pivoting).

Does Hypothesis Testing Apply to Iterative Software Development?

A shortcoming I repeatedly see in Agile software development is what I derisively call bogus prioritization. That is, the business or product owner sets the direction of the development team based on seat-of-the-pants guesses of what's valuable, rather than on something more verifiable.

I propose that we - the iterative software development community - think of each release of new features as a business proposition, much like a startup company. Part of the Lean Startup philosophy is continuous testing and refinement as you converge to a better business model. Can we do the same with each software release?

We might ask,

• What is a hypothesis and how best to test it with real customers?
• That is, how do we make a bold hypotheses like "mCommerce will double eStore revenue" testable?
• What hypotheses are we hoping to get answers to in this release?
• How might prototyping of features be used to test hypotheses?
• Will test-marketing feature sets be off-putting to our loyal customers? To new customers?

Believe those who seek the truth. Doubt those who find it.
~ Derek Sivers

 

The Building Blocks of Software Pleasure

I found Aarron Walter's software pleasure pyramid in Esther Derby's post Are We Aiming Too Low? Aarron's sketch is compelling for its simplicity, and for what it says about past and future agile software development.

Software Pleasure Pyramid

David Hussman pointed out that ancient Egyptians practiced evolutionary design with improvements with each iteration.

"The first pyramids were merely burial mounds. The next version was the step pyramid (Djoser's tomb) and the next version the "bent" pyramid (a design in rock that they had to refactor during construction. These were all the forerunners to the Giza structures. It was a progression of small, simple structures which evolved based on the learning (and failures) from the last iteration."
~David Hussman

Most of the developers I program with day-to-day concentrate on functional & reliable. And, on balance, we're proficient, if not rock stars. Many of us have benefited from wisdom from the Agile & XP communities. Most of us use, in one way or another, some or all of the following:

• granular tasking, 
• emergent design,
• programmer's idioms like One method, One purpose
• test-driven development, and 
• continuous integration.

The better craftsmen I have worked with, young coders like Eric Brandes, consider usability as part of the craft and it shows in their work.

I yearn for the pleasurable in software; software that's a pleasure to use.

Listening to Alan Cooper, the progress to the pleasure plateau is going to require a new level of professional craftsmanship that runs the gamut from simply functional and reliable to sublime user experience.

We are the experts, we are the grownups, and the users are the 5-year old kids. No you don't give them ice cream & candy but...realize they're hungry...so you get the broccoli and liver.
~Alan Cooper

We've learned from evolutionary science that successful organisms often take advantage of the desires of other species. Apples, in the European-centric frontier of North America, appealed to the human desire for sweetness (and for intoxication in the form of hard cider), so humans cultivated the apple for the properties they desired. Or was it the apple cultivating humans?

Part of achieving the level of pleasurable in our software is to understand human behavior and desires.

How do we get to the pleasure plateau in software?

Like the emergent design that unfolded with the incremental construction of ancient pyramids, the Agile software community continues to learn and grow. Future viability of the community rests on integrating interaction design and adopting some important principles of the Lean Startup community like

Integrating product hypothesis testing into iterative development to create a tighter feedback loop between paying customers and a money-generating (pleasure) applications.

The pyramid is an instructive metaphor because software pleasure rests on the stability of the underlying building blocks of functionality, reliability, and usability.

Finding the Software Nectar

I have quirks. One has to do with information workers named Jerry.

When I meet a Jerry, I'll insist that this new Jerry suffer the whole Seinfeld sitcom shtick where I, in thinly veiled disgust, say

"Hello Jerry"

and he, on queue, snidely responds to me with

"Hello Newman"

This all started years ago with a Microsoft practice director named Jerry. The shtick with this particular Jerry works well since I've long suspected we don't trust each other.

"You know who you are, Jerry." :-)

This Seinfeld repartee amuses more than embarrasses (although increasingly more Jerrys have never watched the 1990's Seinfeld TV series).

When I find myself enduring an insufferable meeting with Jerrys, my Jerry-tick possesses me like a pesky eye twitch. Every time this Jerry makes a constructive suggestion, I'll respond with

That's gold Jerry, gold!

It's obnoxious, but I'm no Kenny Bania.

I apologize, in advance and in arrears, to Jerrys future and past.

Many agile software teams are burdened with stakeholders and product owners that set direction grounded in whim rather than on hard data. My guess is that most product owners don't possess savant-like industry knowledge.

I've had it with coding to whim.

Should the next step be sarcastically applying That's gold Jerry, gold! across the range of names to software product owners setting direction based on whim?

Many species, like honey bees, must forage optimally to survive. There is too much churn on most agile software projects. Burn-down charts have developers buzzing, but today's programmers are worker bees bewildered by the fog of business whim.

There must be more efficient means to find the nectar.

Posthumous Retrospective on Google Wave

By beaching Google Wave little more than a year after heralding the engineering leadership of Lars and Jens Rasmussen at the Google Wave Developer Preview at Google I/O 2009, Google now sets the high water mark for the familiar rapid prototyping mantra fail early, fail often.

What's to be learned from the demise of Google Wave?

What is the Google ethos? The Google ethos, lifted from my post Lessons From the Google Rocket, is

• Have the audacity to be different
• Maintain a healthy distrust for suits
• Let data be indicators that trump notions
• Release early and learn

One demonstrably productive prejudice that pervades Google group-think is

Stuff gets invented by engineers, not hucksters or charlatans.

Google values the engineering method. To an admirable fault, Google pursues an engineering-centric path. Introducing Google Wave inventors Lars and Jens Rasmussen to the Google I/O audience, Google Engineering VP Vic Gundotra extols the Rasmussen brothers' engineering chops, gushing about the Rasmussens' previous triumph, Google Maps.

Few companies do more than Google to feed the engineering pig. Google are legendary in engineering circles.

Usability Gets Short Shrift

Unfortunately, product usability at Google gets short shrift. Usability of Google products is often relegated to lipstick on a pig. Google is remiss in dismissing interaction design - usability - as lipstick.

As one who occasionally muses about burning his TV remote in a flaming, ball of confusion effigy, I believe

Usability is as fundamental to any product as any whizz-bang functionality

Google Wave was an engineering triumph - a creative mash-up of tried and tested technologies like XMPP and established web concepts like Wiki. However, usability was never improved. User experience was never demonstrably considered by Google. Most users just didn't get it.

Perhaps the engineering tent at Google needs to include interaction designers. Why not?

Google could even refer to these insightful creative-types as "usability engineers". Heck, the folks at Cooper, some of the most talented interaction designers on this hairball, are only 30 miles up the road from the brain trust ensconced at the Googleplex.

As cyber buddy Ergun Çoruh says in RIP Google Wave:

Google Wave was too stressful to use.

What Worked...

At the Google Wave Developer Preview held at Google I/O 2009, Google VP Vic Gundotra said, "Frankly we need developers to help us develop this product". The strategy to release a half-baked concept to the open source community is laudable. The ink wasn't dry on the Federation spec when eager developers attended the Google Wave Hack-a-thon in June 2009. Developers were jazzed to get in the ground floor building. Bullish on the potential uses for Google Wave, I wrote Google Wave and Collaborative Projects and Will Google Wave Overtake Microsoft Groove?. With the advent Story Board for Google Wave, I was hopeful that the Agile community finally had a software tool that helped rather than hindered.

Half-Baked Product

What Didn't Work...

For execution metaphors & ease of operation, Google Wave was the TV Remote of collaborative software. It was a pinball waste-land of bells & whistles. Many of the operational metaphors that make things easy for users to understand were never explored or realized for Google Wave. Why did Microsoft Bob, an epic product failure, last longer than Google Wave? Perhaps because it used the familiar metaphor of a house with rooms. Google Wave vs. Google Maps: Google Wave was bereft of metaphors to guide skittish users. One reason Google Maps is wildly successful for inventors Lars and Jens Rasmussen is because online maps have a direct and familiar analog on paper. The Rasmussen brothers didn't enjoy the same advantage with Google Wave.

Half-Baked Product

Google will bake the lessons-learned into future forays into social networking and collaborative apps. Perhaps we'll see user experience improvements in Google's upcoming Facebook-killer Google Me?

Value Experience Over Features

As a software developer, it requires vigilance to temper my tendency toward joining feature frenzy. Like you, I like to build features.

My lazy inclination is to forget about asking why or how we justify the new-fangled feature that I'm itching to build.

Features represent our bread and butter, but we are also professionals. We want to be proud of our work.

Since

• our business partners are utterly, in many cases, clueless;
• we aspire to be better professionals; and
• we identify with being craftsmen in the best Alan Cooper-ian sense,

it's up to us to

Value experience over products & features.

How-To Value Experience?

Be an advocate for users. Politely question what's motivating improvements. Are improvements driven from hard data or the soft notions of some muckity-muck over in operations? Resist your tendency to join the feature frenzy.

Let yourself be dragged kicking and screaming before you contribute to BAD user experience by layering in Over-Featured Confusion.

Over-Featured Confusion

Case in point of Over-Featured Confusion is LinkedIn's new and improved Discussions feature.

As soon as LinkedIn released its groups concept, I founded two LinkedIn software groups (i.e., the global Agile .Net Practitioners and the local Twin Cities Software Consultants).

Laudably, LinkedIn has steadily rolled out features that have improved our group experience. Until now...

LinkedIn's new Discussions feature amounts to a ball of confusion. The most glaring improvement is a horizontal slider bar with options to Like, Pass, Comment or More? as a mashup of blog, news and discussion items scroll past (horizontally).

At best, it's confusing. At worst, it's unusable.

• May I Pass on this colossal FAIL by LinkedIn? No.
• Did my feedback to LinkedIn about this improvement disappear into a black hole? Probably.

LinkedIn replaced simple & serviceable with confusing & dysfunctional.

Considerations

As design luminary Don Norman says

Forget the complaints against complexity; instead, complain about confusion.

Perhaps it's excusable to transform something complex into something confusing. But it's inexcusable to transform something simple, like a discussion board, into something confusing.

Google UX researcher Paul Adams says in his presentation Designing Experiences, Not Products

We need to understand how people think, and what motivates them to behave in certain ways. The best way to do this is to design from the outside in. To observe people in their own environment, probing them so that we understand their behavior. This understanding enables us to design things that are meaningful and valuable to people.

Asked or Ignored?

Esther Derby enumerates helpful considerations when Hiring for a Collaborative Team.

I particularly like Esther’s advice to

Involve the team in the hiring process.

Many hiring managers in organizations of all sizes and shapes don't conceive of people working in teams, so it simply doesn't occur to them to ask for input from the team when hiring.

As someone working day-to-day on software teams, I appreciate inclusion in team hiring rituals. A team lunch with a potential hire often smokes out valuable intrapersonal impressions.

Most people would rather be asked than ignored.

Sadly, I've also worked on teams where the morale is so low that team members have a "whatever" attitude vis-à-vis adding new members to the team.

Still, I suspect most would rather be solicited for input.

I value behavior over technology.

A teammate's sense of humor, and professional modesty, is more an indicator of collaborative success than outstanding programming chops.

Microsoft WCF Gotcha

As a WCF newbie, I experienced some wheel-spinning with a service this week. Here's a gotcha that made us swerve into the weeds, along with the solution we implemented.

Our team gained traction developing and running a WCF service under our local Cassini web servers.

Our service was performing as expected.

Well, it works fine locally...

Yet we skidded into the ditch when we deployed our service out onto our IIS web servers. Under IIS, we got the cryptic

This collection already contains an address with scheme http. There can be at most one address per scheme in this collection.

Solution

Our solution was to write a Custom Host Factory that overrides the method CreateServiceHost the framework calls when firing up a WCF service.

A custom host class was derived from the framework's ServiceHost with an override whose purpose is to select the appropriate host vis-a-vis the http context of the server environment (e.g., Dev, QA, Prod).

IIS typically returns a handful of base addresses reflecting any host headers it might have in the Uri array baseAddresses (see above). One of those addresses has to be selected for use. If not, IIS will return the error above. If an appropriate host is not found, a warning is logged to the Windows event log and a default host address returned.

We created the method GetContextAwareAddress to loop through the base addresses IIS returns until we match it with the host of our current http context -- HttpContext.Current.Request.Url.Host.

Remember to wire up the custom service factory in the code-in-front of your service so your service knows to call the overridden, customized CreateServiceHost method.

In our case, the service class is named ProductService.svc.cs and the factory is named ProductServiceFactory as shown above.

Lean Startup for Established Businesses?

The Lean Startup concept - as championed by Eric Ries, Steve Blank, Andrew Chen, and others - is to move incrementally toward a viable business model using a tight feedback loop with potential customers.

Lean Startup is an ongoing sequence of posing hypotheses, testing those hypotheses, and then pivoting (adjusting) your business model based on the test results.

Integral to the Lean Startup concept is Steve Blank's idea of Customer Development (i.e., a hyper-focus on customers and the market at hand).

Lean Startup should not be limited to cagey entrepreneurs and Silicon Valley hipsters. 

Lean Startup could be readily applied to most product development projects that occur in companies of all shapes & sizes.

For software development projects in established companies, Lean Startup would be much like an incrementally improved version of Agile software development.

A significant upgrade to the time-tested Agile approach might be realized simply by having the development team pivot based on a tight customer-testing & analytics loop, rather than reacting to deer-in-the-headlights guesses hastily offered up by bewildered product owners. Engineers at Google have been doing this for years (see the Google News example in my post Launch Early & Learn).

Have the development team pivot each iteration based on a tight customer-testing & analytics loop, rather than the whims of the product owner.

Established companies are afflicted with an overwhelming inertia to make seat-of-the-pants decisions based on whims and half-baked notions. This occurs because employees and contractors are not stakeholders. This also occurs because of dead wood (the lazy & uninspired). To be fair, it’s not their bacon. It's much easier to make decisions based on a whim than it is to design tests, and do the grunt work, that answers essential and existential questions.

One challenge to established businesses is to set up an iterative framework of hypothesize, test, and pivot. Another challenge is to inspire employees to care enough about the product to doggedly pursue customer experience & customer desires through balls-out hypothesis testing and a feedback conduit to customers. 

The flip-side challenge is walking the tight-rope of customer development. That is, walking the fine line between engaging potential customers to help you converge to a business model and repelling potential customers by asking too much of them.

Resources

• Startup Lessons Learned by Eric Ries
• Customer Development Manifesto by Steve Blank
• A Strategy for New Products
• Definable & Measurable Software Value

Google App Engine Changes Everything

Google App Engine changes everything. Much of the out-of-the-gate resistance inherent in kicking out a new web app has been greased by Google. Google gives you essential software services, storage, and scalable hardware.

Apps running in App Engine scale automatically.

If boat-loads of customers start pounding on your app, App Engine allocates more resources.

You only pay for the resources you use.

Google measures resource consumption at the gigabyte level with no monthly fees or set-up charges. CPU usage, storage per month, incoming and outgoing bandwidth, and resources specific to App Engine services are potentially billable items - But ONLY if your app hits pay dirt.

Developers get a generous chunk of free resources for exploratory apps and Lean Startup hypothesis testing (approximately 5 million page views a month).

Google language support consists of Java and Python.

The following My Preferences example I cobbled together uses the Python SDK to demonstrate two key features:

• Google Accounts (for authentication) and
• Google Datastore (data access & persistence)

My Preferences

I wrote My Preferences to learn how out-of-the-box Google Account authentication and Datastore "cloud" persistence is done via App Engine.

My Preferences lets one sign in to select preferences for:

• Page Theme (4 color schemes) and 
• Time Zone (offset from GMT).

Screen capture #1 (below) shows a hyperlink to Sign in or Register. The Sign in and Register links are wired up to Google Accounts. The time displayed before Signs In is the Greenwich Mean Time (GMT) of the web server.

Screen capture #2 (below) shows the Default theme (white background) and GMT time zone after I sign in with with my Google account, but before I have specified my preferences.

Screen capture #3 (below) shows the Winter Green theme I chose. It also shows that I have changed to my time zone (GMT -5.00). These preferences are persisted and keyed to my Google account on the onChange events of the two dropdown lists.

If I Sign Out and then Sign In, my preferences will be displayed.

What You'll Need Bare Bones

Getting started requires a minimum amount of software. All free. Following is a checklist of items you'll need to copy and run My Preferences on a Windows computer (Win 7 or Windows XP SP3). You will need:

1. The Python 2.5 programming language. There are newer versions, but I worked with the recommended version 2.5. The Windows installer for Python 2.5 from python.org is at
   http://www.python.org/ftp/python/2.5/python-2.5.msi.
2. The Google App Engine SDK for Python. The Windows installer for version 1.3.4 from Google is at
   http://googleappengine.googlecode.com/files/GoogleAppEngine_1.3.4.msi.

Project Setup

After running the Python msi and the Google App Engine SDK for Python msi, I had to make sure the Python directory was in the Windows path.

I made a Windows folder for my source code. The source files and a sub-folder for my css stylesheets looked like the adjacent screen capture (right).

Sample Code

app.yaml (below) is a config file in the root of your app directory.


application: preferences
version: 1
runtime: python
api_version: 1

handlers:
- url: /prefs
script: prefs.py
login: required

- url: /stylesheets
static_dir: stylesheets

- url: /.*
script: main.py


models.py (below) contains my datastore objects (e.g., theme, zone, and user) that I want to persist using the Google Datastore.


from google.appengine.api import memcache
from google.appengine.api import users
from google.appengine.ext import db
import prefs

class UserPrefs(db.Model):
theme = db.StringProperty(default="0")
zone = db.StringProperty(default="0.0")
user = db.UserProperty(auto_current_user_add=True)

def cache_set(self):
memcache.set(self.key().name(), self, namespace=self.key().kind())

def put(self):
self.cache_set()
db.Model.put(self)

def get_userprefs(user_id=None):
if not user_id:
user = users.get_current_user()
if not user:
return None
user_id = user.user_id()

userprefs = memcache.get(user_id, namespace='UserPrefs')
if not userprefs:
key = db.Key.from_path('UserPrefs', user_id)
userprefs = db.get(key)
if userprefs:
userprefs.cache_set()
else:
userprefs = UserPrefs(key_name=user_id)

return userprefs


prefs.py (below) gets the page post and stores preferences. That is, the authenticated user specifies and posts their theme choice and time zone preference. The userprefs method I created is called to put( ) them into the Datastore.


from google.appengine.ext import webapp
from google.appengine.ext.webapp.util import run_wsgi_app
import models

class PrefsPage(webapp.RequestHandler):
def post(self):
userprefs = models.get_userprefs()
try:
zonePost = self.request.get('selZone', allow_multiple=False)
userprefs.zone = zonePost

themePost = self.request.get('selTheme', allow_multiple=False)
userprefs.theme = themePost

userprefs.put()

except ValueError:
# Ignore for now.
pass

self.redirect('/')

application = webapp.WSGIApplication([('/prefs', PrefsPage)],
debug=True)

def main():
run_wsgi_app(application)

if __name__ == '__main__':
main()


main.py (below) is the main page that includes code and HTML.

Python is persnickety about whitespace and column alignment, so beware. If you cut & paste the code below, you'll probably have to format it nicely so Python can digest it. I had to jury rig the HTML for this blog post, so lookout for munged HTML if you cut & paste.


from google.appengine.api import users
from google.appengine.ext import webapp
from google.appengine.ext.webapp.util import run_wsgi_app
import datetime
import models

class MainPage(webapp.RequestHandler):

def get(self):
time = datetime.datetime.now()
user = users.get_current_user()

def IsEq(a,b):
if str(a)==str(b):
return "selected=selected"
else:
return ""

if not user:
prefsForm = ''
myTheme = "0"
signInOut = ('To set and persist preferences, <a href="%s" style="text-decoration:none">Sign in or Register</a>.'
% (users.create_login_url(self.request.path)))
else:
uPrf = models.get_userprefs()
prefsForm = '''
<form action="/prefs" method="post" name="frmMyPrefs">
<label for="selTheme">
Theme<br/>
</label>
<select name="selTheme" id="selTheme" OnChange ="document.frmMyPrefs.submit()" style="font-family:Arial, sans-serif; font-size:12px">
<option %s value="0">Default</option>
<option %s value="1">Slate Blue</option>
<option %s value="2">Salmon Eggs</option>
<option %s value="3">Winter Green</option>
</select><br/><br/>

<label for="selZone">
Time Zone<br/>
</label>
<select name="selZone" id="selZone" OnChange ="document.frmMyPrefs.submit()" style="font-family:Arial, sans-serif; font-size:12px">
<option %s value="-12.0">GMT -12:00</option>
<option %s value="-11.0">GMT -11:00</option>
<option %s value="-10.0">GMT -10:00</option>
<option %s value="-9.0">GMT -9:00</option>
<option %s value="-8.0">GMT -8:00</option>
<option %s value="-7.0">GMT -7:00</option>
<option %s value="-6.0">GMT -6:00</option>
<option %s value="-5.0">GMT -5:00</option>
<option %s value="-4.0">GMT -4:00</option>
<option %s value="-3.5">GMT -3:30</option>
<option %s value="-3.0">GMT -3:00</option>
<option %s value="-2.0">GMT -2:00</option>
<option %s value="-1.0">GMT -1:00</option>
<option %s value="0.0">GMT (Greenwich Mean Time)</option>
<option %s value="1.0">GMT +1:00</option>
<option %s value="2.0">GMT +2:00</option>
<option %s value="3.0">GMT +3:00</option>
<option %s value="3.5">GMT +3:30</option>
<option %s value="4.0">GMT +4:00</option>
<option %s value="4.5">GMT +4:30</option>
<option %s value="5.0">GMT +5:00</option>
<option %s value="5.5">GMT +5:30</option>
<option %s value="5.75">GMT +5:45</option>
<option %s value="6.0">GMT +6:00</option>
<option %s value="7.0">GMT +7:00</option>
<option %s value="8.0">GMT +8:00</option>
<option %s value="9.0">GMT +9:00</option>
<option %s value="9.5">GMT +9:30</option>
<option %s value="10.0">GMT +10:00</option>
<option %s value="11.0">GMT +11:00</option>
<option %s value="12.0">GMT +12:00</option>
</select>
</form>
''' % (IsEq(uPrf.theme,"0"),IsEq(uPrf.theme,"1"),IsEq(uPrf.theme,"2"),IsEq(uPrf.theme,"3"),IsEq(uPrf.zone,"-12.0"),IsEq(uPrf.zone,"-11.0"),IsEq(uPrf.zone,"-10.0"),IsEq(uPrf.zone,"-9.0"),IsEq(uPrf.zone,"-8.0"),IsEq(uPrf.zone,"-7.0"),IsEq(uPrf.zone,"-6.0"),IsEq(uPrf.zone,"-5.0"),IsEq(uPrf.zone,"-4.0"),IsEq(uPrf.zone,"-3.5"),IsEq(uPrf.zone,"-3.0"),IsEq(uPrf.zone,"-2.0"),IsEq(uPrf.zone,"-1.0"),IsEq(uPrf.zone,"0.0"),IsEq(uPrf.zone,"1.0"),IsEq(uPrf.zone,"2.0"),IsEq(uPrf.zone,"3.0"),IsEq(uPrf.zone,"3.5"),IsEq(uPrf.zone,"4.0"),IsEq(uPrf.zone,"4.5"),IsEq(uPrf.zone,"5.0"),IsEq(uPrf.zone,"5.5"),IsEq(uPrf.zone,"5.75"),IsEq(uPrf.zone,"6.0"),IsEq(uPrf.zone,"7.0"),IsEq(uPrf.zone,"8.0"),IsEq(uPrf.zone,"9.0"),IsEq(uPrf.zone,"9.5"),IsEq(uPrf.zone,"10.0"),IsEq(uPrf.zone,"11.0"),IsEq(uPrf.zone,"12.0"))
if uPrf.zone.endswith('0'):
time += datetime.timedelta(hours=int(uPrf.zone.split('.')[0]),minutes=0)
else:
time += datetime.timedelta(hours=int(uPrf.zone.split('.')[0]),minutes=30)
signInOut = ('Welcome, %s.&nbsp;&nbsp;<a href="%s" style="text-decoration:none">Sign Out</a>'
% (user.nickname(), users.create_logout_url(self.request.path)))
myTheme = uPrf.theme

self.response.headers['Content-Type'] = 'text/html'
self.response.out.write('''
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
<head>
<title>My Preferences</title>
<link rel="stylesheet" type="text/css" href="stylesheets/style''' + myTheme + '''.css" />
</head>
<body>
<div class="signInOut">%s</div>
<div style="clear:both;padding-left:5px;padding-top:5px;">%s</div>
<div style="clear:both;padding-left:5px;padding-top:10px;">%s</div>
</body>
</html>
''' % (signInOut, prefsForm, str(time.strftime("%A, %d %B %Y &nbsp;&nbsp;<b>%I:%M:%S</b>"))))

application = webapp.WSGIApplication([('/', MainPage)],
debug=True)

def main():
run_wsgi_app(application)

if __name__ == '__main__':
main()


index.yaml (not shown) is an auto-generated file that is updated whenever the dev_appserver detects that a new type of query has been run.

style0.css (below) contains the css stylesheet for the Default theme. There are 3 additional stylesheets (style1.css, style2.css, and style3.css) that are identical except for tweaks in colors. Here's the Default template:


body
{
background-color:white;
font-family:Arial,sans-serif;
font-size:13px;
margin-left:0px;
margin-right:0px;
margin-top:0px;
}
a:link{font-weight:normal}
a:visited{font-weight:normal}
a:active{font-weight:normal}
a:hover{font-weight:bold}
.signInOut
{
padding-left:5px;
color:black;
background-color:#E0E0E0;
clear:both;
padding-bottom:5px;
padding-top:5px;
border-bottom:solid 1px #C0C0C0;
}


Kickin It Old-School

You invoke the Python compiler from a command prompt as shown below.


Once compilation completes, you can run the app from localhost on port 8080 as shown below.


Uploading To Google App Engine

Once you have developed your app locally, you can create a developer account and upload it to run on Google App Engine via the App Engine Admin Console.

Resources

Programming Google App Engine by Dan Sanderson.

Project Places

A space starts as a lonely noun. Eventually it might be filled with other nouns.

A space becomes a place when it is full of buzzing verbs.

Project teams, team coaches, and community builders, often have the notion of space as the means to facilitate and channel interaction between team members.

Space is our latitude and longitude. Place requires a bit more thought and adaptability.

Space provides our locus, but not our focus.

We're located in a space, but we act in place.

In the oft-cited PARC paper Re-Placing-Ing Space (Harrison and Dourish, 1996), the authors draw from experience in architecture and urban design, and their research findings, to make a distinction between space and place vis-à-vis collaborative environments.

Harrison and Dourish argue it is the notion of place that frames interactive behavior in real and virtual space.

Space is the opportunity; place is the understood reality ~ Harrison and Dourish

Observing a variety of collaborative systems, Harrison and Dourish say

Place derives from a tension between connectedness and distinction, rather than from a three-dimensional structure.

Think of the symbiotic relationships of a bee colony in a three-dimensional hive.

In  A Place of My Own, author Michael Pollan argues that thoughtful crafting of space has the potential to give us a place in the world that serves our bodies, minds, and aspirations.

Behavioral Framing

A place is a space that is valued like a home might be valued over a house. Harrison and Dourish point out that the same physical space can function as different places at different times framing the appropriate behavior.

We fill our places with cultural expectations and notions of appropriate behavior.

In The Timeless Way of Building, Christopher Alexander discusses reoccurring Patterns of Events. He says,

all the life and soul of a place, all our experiences there, depend not simply on the physical environment, but on the patterns of events that we experience there

Places exist within a space. A place is within a space where we've added social context and cultural understandings that help frame and cue behavior. Something is out of place when it feels out of context.

The Forward Edge

Stanford d.school believes we can design for innovation. Planners, students and staffers have spent six years brainstorming, designing, and tweaking their environment to make it fertile ground for ideas.

After a May 7th ribbon cutting at the d.school, Fast Company will go behind-the-scenes to document how

every nook, cranny, and fungible wall system has been smartly designed to maximize collaboration.

I will be following the d.school and Fast Company's findings with interest.

ScreenCasts For Bug Fixes

The Problem

I shouldn't be such a curmudgeonly troll when it comes to software tools that are supposed to make things easier for me. But I am.

• The Agile Tracking software I have used does not make things easier.
• The Bug Tracking software I have used does not make things easier.

Why? Stuff gets missed. Stuff gets lost. People can't consistently write clearly. People can't consistently find things. And, I'm kinda dense.

Red Thread of Failure?

The red thread of failure, and the root of my dissatisfaction is communication, or lack thereof. Communication is munged, obscured and buried in software tracking tools.

We falsely assume because something is written down, that it is also clearly communicated. Not so.

A client said to our software team a few projects ago,

I'll summarize our discussion & queue it up in Brand X.  (Brand X is tracking software) 

I replied,

That's fine, as long as we recognize that Brand X is where critical information goes to die.

If I possessed extraordinary senses (visualize the pinball wizard from the tune by The Who), then perhaps a few cryptic lines buried in an email, or saved in a software tracking tool, would suffice.


But, This Is Easier

The forward-thinking folks at Affinety Solutions found a way to make my programming easier. Affinety founder Steve Holewa contracted me a few years ago to update parts of their software. During a flurry of recent updates, Sys-Ops expert Holly initiated sending links of short videos she had recorded using ScreenCast.com.

Holly's screencasts include narrated screen illustrations of the bugs I have caused and the nice-to-haves she has found in code I have staged for her in QA.

Two of the subtleties I like about Holly's screencasts that simply would not translate from words buried in a software tool:

• See - I can see the sequential steps she took, and the data entry she made, to re-create the bug.
• Hear - I can hear the tone in her voice as she describes an issue to judge emotional cues like urgency or frustration.

Plus, I can replay the clip until I understand the problem.

Sliced Bread

This might not be the Stradivarius of shortening the bug fix cycle, but it might be the sliced bread of subtle cues in communication that enable efficient off-site feedback cycles.

Thanks Holly.