25 December 2011

Cloud Green or Cloud Nine?

The cloud metaphor gives the cloud storage of our data a misleading somewhere-up-in-the-clouds, ethereal quality.

Perhaps we could use a bit of grounding from the implied benevolence of cloud storage of our unending flow of music, videos and documents.

After all the lofty green 'n clean cloud imagery, cloud storage resolves to mundane bricks and mortar data centers.

Coal Trains of Cooling

Traditional data centers:
Require massive numbers of power-sucking, heat-generating servers that consume COAL TRAINS OF COOLING KILOWATTS.
Cloud storage is an energy-intensive proposition. For our collective well-being, two questions worth considering are:
  • What's the energy source? and
  • What's the impact on public safety and public health?
While a traditional data center might be sourced from a finite supply of air-fouling coal, a forward-thinking data center might be sourced from the steady winds of Wyoming, or from geothermal energy stored somewhere under the half-light and bitter cold of an Icelandic winter.

Wind Energy

In Cheyenne Wyoming, Green House Data is powered by 100% renewable wind energy. According to Green Data Center News Green House Data is about 40% more energy-efficient than traditional data centers. It helps that Cheyenne's average annual temperature is 46 degrees F.

Hydro-Electric and Geothermal

In Iceland, west of Reykjavik, Verne Global operates a power-conscious data center that is dual-sourced by hydroelectric and geothermal power. Verne Global's energy is 100% renewable hydro-electric power and its facility is 100% cooled by the natural environment of Iceland. Brrrr.

Present & Near Future

The Greenpeace report How dirty is your data? includes a Clean Cloud Power Report Card.

Despite a poor to middling report card among the cloud storage players, there is a trend toward clean, renewable energy.

Facebook is building a new data center in northern Sweden that will use hydro-electric power. Sited about 62 miles south of the Arctic Circle, Facebook servers will be cooled by Arctic air.

Google's Hamina Data Center is sited on the Gulf of Finland. The data center uses sea-water for cooling rather than freon-packed compressors in traditional air conditioners.

Both Facebook and Google are driven by economics more than earth-stewardship. Nonetheless when earth-friendly infrastructure collides with profit-increasing cost-savings, cloud green isn't simply cloud nine.


21 December 2011

You and The Org

Trust shapes the quality of our relationships in the market of jobs, gigs, and careers.
Love all, trust a few, do wrong to none.
~ William Shakespeare
Jurgen Appelo's clever t-shirt test is one of the simplest and astute measures of an organization's well-being I have encountered.
An organization passes the t-shirt test when employees will proudly wear a t-shirt with the company logo on it, hoping that other people notice the name of the organization.
~ Jurgen Appelo, The T-Shirt Test
For company t-shirts, my wear or not-to-wear criteria distill to a mix of ownership, connection, responsibility and loyalty.

What company t-shirts would you wear? What company t-shirts would be publicly embarrassing?

The more companies model the better behaviors of people, the more they resonate. The more companies squeeze people for profit, the more they repel people.

Perhaps it's idealistic to consider less profit for more satisfaction, but I think the notion of common-good will soon return to our lexicon.
Loyalty and friendship, which is to me the same, created all the wealth that I've ever thought I'd have. ~ Ernie Banks
The foundations of trust are broad. The supporting beams that shape the quality of my relationship are:
  • Mutuality of Control - Where is the Org in the spectrum between autocratic & democratic?
  • Dependability - Does the Org keep its promises?
  • Integrity - Do the Org and I share the same principles?
  • Competence - Does the Org accomplish its goals?
  • Interests - Does the Org share mutual interests?
  • Goals - Do the Org and I have compatible goals?
  • Commitment - Does the Org cultivate our relationship?
  • Identity - Do I identify with the Org's brand and public persona?
  • Exchange - Who gives more? Who takes more?

Trust is a two-way, living compact. Trust is gradually built, but suddenly broken.
The best way to find out if you can trust somebody is to trust them. ~ Ernest Hemingway
Broad-based familial-style loyalty is undervalued, if not lost, in productivity-obsessed companies.
I'll take fifty percent efficiency to get one hundred percent loyalty. 
~ Samuel Goldwyn

09 November 2011

Information & The Common Good

Information is power. But power tends to corrupt whether in revered individuals or in authoritarian institutions. One need only reflect on the sordid history of the Papacy, or the recent transgressions swirling around the cult of football coach Joe Paterno at Pennsylvania State University.

Power can be a very noxious Kool-Aid.
Power tends to corrupt, and absolute power corrupts absolutely.
~ John Dalberg-Acton, 1st Baron Acton
Don't Be Evil

Many software professionals revere the information giant Google. Pundits marvel at Google's ability to increase its relevance and reach year after year. Software developers put Google on a pedestal.

Google's informal Don't Be Evil motto has been adopted as a guiding philosophy by many professionals inside and outside the Google family.

We can all be thankful that the gods of search, Google founders Sergey Brin and Larry Page, are progressive thinkers. Still, I wonder about the practical limits Don't Be Evil.

Common Good

I will be following an organization called CommonCrawl with interest. CommonCrawl launched a free, open, web search crawler and index.
We strive to be transparent in all of our operations
~ CommonCrawl
Recognizing the power of the largest and most diverse collection of information in human history is indeed heady stuff. CommonCrawl is non-profit foundation with the motto "dedicated to the open web" and a website introduction that explains their mission:
As the largest and most diverse collection of information in human history, the web grants us tremendous insight if we can only understand it better. For example, web crawl data can be used to spot trends and identify patterns in politics, economics, health, popular culture and many other aspects of life. It provides an immensely rich corpus for scientific research, technological advancement, and innovative new businesses. It is crucial for our information-based society that the web be openly accessible to anyone who desires to utilize it.
~ CommonCrawl
The need to nurture and maintain equal access to unbiased information has never seemed more critical. With the control of information, it is imperative that individuals, organizations, and states thoughtfully weigh the fruits of laissez-faire market forces with the common good.

If corruptible power is an oft repeated pattern, then CommonCrawl might some day be the anti-dote for Don't Be Evil gone bad.

31 October 2011

Ownership & Responsibility

On the collaborative teams I have enjoyed working on, we quickly forget who the assigned leader is and often coalesce around a de facto leader. In Cisco and a Cautionary Tale about Teams Rosabeth Moss Kanter repeats the old bromide:
When everyone is responsible, no one is responsible
I can think of at least one scenario where this assertion doesn't hold water. It has to do with one's ownership stake.

With a top-down model, even highly collaborative team members are loath to assume full responsibility because they don't want to be taken for a mug.

But for many people, taking responsibility is proportional to their ownership stake in the product or venture.

My experience has this contrarian twist:
When everyone is responsible, shit simply gets done

When Fast Was Turbo

By dumb-luck and fortunate timing in the mid-80s, I scored an undergraduate fellowship from the University of Minnesota Civil & Mineral Engineering department to develop engineering applications for two-floppy drive IBM Personal Computers.

With mentoring from three engineering profs and one post-doc, our team of a handful of CE undergraduates benefited from a 2-year grant from IBM to learn and build educational software for engineers. We started our first applications using IBM Pascal (UCSD Pascal) in deference to our benefactor.

At the time one had to boot the IBM PC from a left-hand floppy disk that had MS-DOS and IBM Pascal  on it. 5 MB hard-drives weren't readily available until a year or two later. We used the right-hand floppy disk for source code and data files.

Around 1984-85, we switched Pascal compilers to Borland's Turbo Pascal. Turbo Pascal was shockingly fast and lightweight - even by today's standards. Turbo Pascal represented a quantum leap in our app development.

The Turbo Pascal 3.02 compiler and IDE was only 39,731 bytes. A size-wise comparison to a few contemporary benchmarks:
Reference: Things Turbo Pascal is Smaller Than

By fast I mean builds of 1-2 seconds.
Full rebuilds were about as fast as saying the name of each file in the project aloud. And zero link time. ~ James Hague
That all this was running on an 8MHz Intel 8088 makes it all the more remarkable.

27 October 2011

Silent But Deadly Guy

I get testy when the software community measures developers.

Many software projects use Sprint Burn-Down charts (SBD charts) thinking they are measuring Velocity.

My beef with SBD is that Velocity is misunderstood. I care most about the experience of a software product (e.g., general quality and usability). SBD is, at best, misused, if not useless.

Speed and Direction Define Velocity

We think we're measuring velocity when we're tracking the illusion of speed, and all the while, direction is AWOL.

Maybe speed isn't all it's cracked up to be. Here's the thing:
We have already wrung most - if not all - the speed & efficiency we're going to get from the  development team.
No more speed. No more getting faster. No more SBD.

If we want better software products, it's time to critique the Teflon Players in the software equation -- The Business. We'd be way ahead if we figured out how stakeholders can be accountable to the product team and to provide meaningful direction as a software product takes shape.
If you don't know where you are going, it's easy to iteratively not get there. ~David Hussman, 5:40 PM Nov 3rd, 2009 from TweetDeck

Silent But Deadly

The moniker Silent But Deadly Guy evolved during a software project that recently went up in flames. Silent But Deadly Guy was a gratuitous Project Manager the developers started calling Sprint Burn-Down Guy in recognition of his sole contribution to the effort -- the daily Burn-Down chart.

Soon Sprint Burn-Down Guy was shortened to the acronym SBD Guy.  Then by a simple twist of acronym morphed into Silent But Deadly Guy.

The Silent But Deadly story encapsulates how I feel about ceremonial metrics like Sprint Burn-Down that have little to do with making kick-ass software.

30 September 2011

Not What, But Who

I've been moving from project to project for quite some time now. What I've realized is that for most professional gigs, it's not what you're doing that's important as much as who you're doing it with.

I recall a time when my teammates called me Bobby Tables for an entire 2-week iteration. Bobby Tables is developer humor.

Like many of the teams I have been fortunate to work with, everyone was productive but more importantly, our days were humor-filled.

So whenever I piss and moan about this technology stack or that technology stack <cough>Silverlight</cough>, I have to remind myself...
It's the people, dummy

08 September 2011

Management & Leadership Psychobabble

I'm weary of management & leadership psychobabble (e.g., The manager does this, while the leader does that).

While not bullet-proof, two tenets that hold true more often than not in my day-to-day life as a knowledge worker:
  1. Command and Control Management is almost always unnecessary and irrelevant. 
  2. Leadership is often over-rated (see Dancing Guy video in Leaders Yes, Managers No).
Where's my management & leadership psychobabble?
The Manager asks for the report, but The Leader gets his own damn report.

21 August 2011

The Filler Anti-Pattern

There aren't enough killer apps to go around. Most software developers perform a daily slog making information massaging applications or information shuffling applications.

A developer I know worked on a project for the now defunct Minnesota Brewing Company. MBC occupied the former Schmidt Brewery in Saint Paul circa the late 90s through the early 2000s.

The Filler

To software developers, abstractions like inventory, workflow, content management, contact management, and so on, soon become a monotonous blur. Slinging code for an unscrupulous hedge fund manager or a head-strong brew-master -- after a while, it begins to look the same: massage or shuffle.

The difference in the story of our intrepid MBC developer was something known as The Filler. Our buddy would regale fellow-programmers with stories about The Filler. Filler stories involved the plant loudspeaker and a plant employee warning everyone about the dreaded Filler.

Our buddy might be VB-Scripting a jury-rigged ETL between Microsoft Access and Microsoft Excel when over the loudspeaker, he would hear:
Shut The Filler Down!....Shut The Filler Down!
Since we'd never been inside MBC plant gates, the meaning of this plea was left to our collective imaginations. We'd imagine massive beer vats packed like copper sardines into a steamy, industrial-aged factory.

Pot-bellied vats would be over-flowing with boiling wort. And because we'd imagine the floor drains were clogged, swells of pre-fermented swill would be roiling down corridors gushing into windowless chambers where unsuspecting programmers were mindlessly toiling away on Microsoft Office automation.

Shut The Filler Down Metaphor

In the intervening years I have wondered how Shut The Filler Down might be a useful metaphor for a few repeating software development scenarios.

Perhaps the best application of the Shut The Filler Down metaphor might come at the moment we detect an anti-pattern in code, or an anti-pattern in team behavior.

Anti-Patterns in Code

Custom software developers frequently weigh the client's value with either the seemingly laudable tendency toward gold-plating, or with the seemingly laudable tendency to get stuff done.

I have coded myself off-the-rails many times by hacking together something marginally useful in haste simply to complete a user story within the confines of an iteration.

Last week I recognized one of my off-the-rails moments. "Super Dave" Osborne looked at the stinking pile of MVVM and Silverlight ooze I had made, then offered a couple of suggestions so that I could then see my way toward turning my malodorous ooze into something tighter, simpler, and better aligned with established patterns in the rest of our code base.

Not every team has a "Super Dave", but when you're coding yourself off-the-rails, remember the mantra
Shut The Filler Down,
then ask someone for a second set of eyes.

Anti-Patterns in Team Behavior

Shutting The Filler Down
by reversing caustic anti-patterns in team behavior (or in corporate culture) might take months (or years). So I suggest starting with the first retrospective. Call out the anti-pattern - respectfully. Rinse and repeat. Be tenacious, but be respectful -- because you're a professional!

Imagine clinging to an over-sized monkey-wrench with like-minded team-members as you incrementally inch the shut-off valve to its closed position. To Shut The Filler Down when it involves human egos is delicate. It requires patience and finesse.

20 August 2011

Agile Adaptations

I've been following the Lean-Startup movement since I wrote about it in Framing Product Development. In the Spring of 2010 I was jazzed up about Lean-Startup following a gathering at DevJam with a small group of friends where we viewed a simulcast of the Startup Lessons Learned Conference --the brain child of Eric Ries.

Yesterday I tweeted:

Several RT'd. Others commented about this distillation of ideas.

My Admission

 My Tweet was cribbed from Abby Fichtner's (a.k.a., Hacker Chick) screencast Pushing Agile to the Next Level. The side by side comparison of Agile and Lean Startup (below) is a concise and helpful representation of an evolution of thinking in the Agile software development realm.

Of Hacker Chicks's excellent slide and presentation, I pass on Alan Cooper's tweet - ostensibly directed at her vision of the evolution of the Agile movement...
Most accurate, succinct, and wise demarcation of the two disciplines.Alan Cooper
Agile 2.0

I share Hacker Chick's vision. For me Lean-Startup has become Agile 2.0. True to the spirit of Agile, movements must adapt and adopt, or die. I recognize that Hacker Chick has shown the Agile community a bridge to the future. The challenge for any ponderous old-paradigm organization producing custom software products is
How to behave like a startup?
Lean-Startup teaches us to create the infrastructure necessary to test our business models (our products). That means getting it into the hands of the users, testing hypotheses (fail early / fail often), and pivoting toward viability -- like a heat-seeking missile follows heat.

Previous Posts About Lean-Startup For those new to Lean-Startup, I've written several posts on my understanding the constituent principles:

19 July 2011

Make Software for People

Whenever software professionals extol the virtues of Lean Manufacturing, I think of the I Love Lucy episode where Lucy & Ethel work the assembly line of a candy factory, then I wonder
What does quantity-based slapstick have to do with people interacting with visual representations of information?

Alan Cooper roasts the auto industry for slipshod telematics in this Cooper Journal post: Will Ford learn that software isn't manufactured?

Auto manufacturers are far from mastering telematics. Toyota might have given birth to Lean, but 10 minutes struggling to make heads or tails of the slapdash telematics and interface controls on my Prius proves Toyota isn't paying attention to my needs, let alone offering a familiar visual metaphor.

Someone at Toyota must have deemed an intuitive dashboard display & interface controls to be one of the original seven wastes.

You don't have to be Alan Cooper or Don Norman to empathize with the people using your software. What's the value and where's the joy in using your products?

Design Serves Human Purpose – from paper clips to pyramids. Make software with people in mind.

15 July 2011

An Old Story of Story Mapping

Agile software development teams who use Story Mapping in the tradition originated in software circles by Jeff Patton and David Hussman will be amused to learn author Eudora Welty was doing her own kind of story mapping back in 1953.

In her correspondence with novelist and New Yorker fiction editor William Maxwell, she wrote:
“I used to use ordinary paste and put the story together in one long strip, that could be seen as a whole and at a glance — helpful and realistic. When the stories got too long for the room I took them up on the bed or table & pinned and that’s when my worst stories were like patchwork quilts, you could almost read them in any direction . . . I like pins."
~Eudora Welty (What There Is to Say We Have Said: The Correspondence of Eudora Welty and William Maxwell)
Note Ms. Welty's visual cues for what her worst stories looked like when pinned into a "patchwork quilt".

From Weird Writing Habits of Famous Authors, I learned of the pre-Agile card-writing used by Russian novelist Vladimir Nabokov. Nabokov wrote most of his novels on 3 x 5 inch index cards, which he paper-clipped and stored in boxes.

Visit Jeff Patton's slide deck Building Better Products Using User Story Mapping from Agile India 2010.

10 May 2011

Relevant Stand-Up Meetings

The stand-up meeting has long been used by the military (e.g., roll-call) to account for and synchronize troops.

Meetings should last as long as needed. No longer.
Nobody schedules a "lunch hour" and then eats nonstop for the full hour, dropping his fork at the 60th minute, with no regard whatsoever to the amount of food consumed. Yet this is the way every meeting works.
~Skip and Dan Heath
The primary motivation behind a stand-up is to apply a force (gravity) to keep the meeting short -- and with any luck, relevant.
Unchecked, a meeting will fill up whatever time is allotted to it.
Out-of-the-box, the familiar Scrum prescription for the Daily Scrum is to tell the team:
  • What I did yesterday;
  • What I'll do today; and
  • What (if anything) I am blocked by…
Please don't let that box you in!

Regrettably, an under-used option is:
  • I pass.  -- I graciously cede my time to a teammate.
Be honest. If you've got nadda, simply pass. Most teammates will gladly give you permission to shut your pie hole.

Most of us have stood through painfully irrelevant stand-up meetings. Why are they irrelevant?

For starters, forget about the Scrum prescription, I don't give a rip what you did yesterday -- unless it impacts me today. Further, I am guessing most of us despise the self-congratulatory tone people use while verbally bullet-pointing all of the story points they burned down yesterday. It's irrelevant. What the hell is a story point any way, and why do I care?

Stand-ups also become irrelevant when there's no highly visible, low-tech story wall to supplement our individual narratives -- when most of the team intelligence is obscured in project tracking software, or in a rarely visited Wiki (my apologies to visionary Ward Cunningham), or worse, neatly tucked away in SharePoint.

When the stand-up become a status meeting, rather than an impact meeting, it loses relevance.

If the purpose is simply a status meeting, then lets insist everyone who wants to give a status update do isometric wall-sits while they regale bored team-members with yesterday's accomplishments.

Over the past decade the stand-up meeting, with varying degrees of success, has become one of the hallmarks of Agile teams. The purpose is to synchronize team thinking and to share a commitment to the tasks at hand. A Scrum, or a huddle, metaphor or not, is to
  • Set direction and 
  • Focus on the next play.
I don't have a prescription for stand-ups. Nor do I believe in prescriptions. Like all process minutiae, the best approach is context-dependent.

While I always hope for something wildly informative to tell my teammates, it rarely happens. So when it is coming around to my turn to speak, I think about
  • What is most crucial for the team to know?
  • How might something I did impact my teammates? 
  • Will my tasks today involve other teammates?
  • Is a teammate dependent on me to complete something?
  • Should I pass?

06 March 2011

Team Intelligence & Tectonic Shifts

Tectonic shifts have become the norm. To cope with tectonic shifts, collaborators might do well to consider
  • Environmental Adaptability,
  • Direction & Approach, and
  • Team Intelligence.
Environmental Adaptability

Smart, adaptable & flexible buildings have a better chance of riding out earthquakes.

The same is probably true for people & organizations. That is,
Building, person, or organization – Rigid will likely fail.

The shake-table simulation of building structures (shown above) demonstrates a powerful innovation in building technology called base-isolation. The materials in both buildings are the same, but the material weaknesses (e.g., tensile strength) of the building on the right are isolated from the sudden shifts of the shake-table.
Software development teams benefit from isolation from extraneous churn and irrelevant chatter.
Rigid materials and rigidly constructed building materials, as well as baking in a rigidly un-adaptable approach to environmental conditions, like tectonic perturbations, increase the chances of failure.
Adaptability is not imitation. It means power of resistance and assimilation.
~ Mahatma Gandhi

Direction & Approach

I learned sailing in a Sunfish. I never graduated beyond a Sunfish, but I learned to jibe.
A jibe is a maneuver where you steer the boat, which is moving in the same direction as the wind, so that it arcs the stern through the prevailing wind resulting in the wind pressure shifting from billowing out one side of the sail to the other.
My intent in navigating the Sunfish might have been to sail from shore to the deepest part of the lake. That required tacking – a back-and-forth series of intermediate and indirect jibe maneuvers.

The sailing lesson in tacking is applicable to software development teams
Stay true to your direction, but remain adaptable & practical in your approach.

An intelligent team, while adaptable, continually checks and confirms direction.

Team Intelligence

Six-time NBA champion Michael Jordan on teamwork
Talent wins games, but teamwork and intelligence wins championships.
Team intelligence requires determining a direction and staying true to that direction, all the while remaining adaptable & being practical in approach.

One way to spread team intelligence is to be vocal about the "gotchas" encountered. Another is to graciously accept guidance from teammates. Yet another is to be vigilant about checking and confirming direction.


Be a student of conditions - study and anticipate environmental conditions. Check your approach and confirm direction. Look for ways to spread team intelligence. And remember, in all likelihood, rigid will fail.

02 March 2011

Legacy of Crumbling Legacy

A software middleman's pitch to work on a re-write of legacy code might read like
This ad was also allegedly placed in London newspapers by explorer Ernest Shackleton (1874-1922). Shackleton's fame followed several harrowing Antarctic expeditions to reach the South Pole -- none of them successful.

The excuse for dishing up the heaping spaghetti bowls of legacy code developers increasingly encounter is short-sighted profit-taking.

Thinking of legacy code, I think of a leg -- a leg dragging a ball on a chain. Few in the business sphere seem to consider a long-view. And to be fair to those folks, what good is a long view when just about everyone is one thin access card away from permanent severance? It's a current cultural deficiency.

Executive Consultants

If you're an executive, executive consultants aplenty are ringing your bell to tell you what you should already know...the obvious.

Amusement and amazement differ by two letters. The made-up word amuzement describes my impression of executive consultants making a living by
Stating the obvious.
In the scholarly sounding article The Financial Implications of Technical Debt, a well-regarded Agilista, Jim Highsmith, states the obvious. Devoid of cynicism, I might imagine an executive's response to reading this article as something akin to
No shit Sherlock
Surprisingly, the apparent reality given the Gartner Group Executive offerings, is that most CIOs must eat this shit up like it's revelatory Kool-Aid.

Mr. Highsmith springs a new acronym on me: CoC or Cost of Change. And to think, I snicker at vacuous acronyms like ROI.

To my amuzement, thinly cloaked business science is music to executives. But here's the executive summary:
If the CoC graph is somehow an ah-ha moment for you, shit's already oozing into your tassel loafers.
Two all-too-common software developer head-scratchers when burdened with fixing the plague of legacy code, or recovering from the prolonged ignorance of technical debt are
  1. How did this crap ever work? and
  2. How could they have waited this long?
There are business sectors notorious amongst developers for letting their software infrastructure crumble while they wring out every copper-wire of short-term gain.

Most seasoned contract developers can tell you what those sectors are. There is something about having wads of funny money to incinerate that somehow manifests organizational stupidity. A startup must spend judiciously. Yet
An organization that falls within the fat, dumb and happy Venn diagram can burn cash for heat.
Do you know who invented the copper wire? Fat, dumb and happy. The legend goes like this
Two fat, dumb and happy managers spotted a copper penny. Henceforth, the copper wire.
In the distant past, the practice of wringing out profit without re-investing in infrastructure was disparagingly known as:
"Running the company into the ground"
Today, turning a blind eye to re-investment is standard operating procedure. Companies decree institutional thumb twiddling until the door handles fall off.

Perhaps the pendulum will swing back to judicious re-investment.

18 February 2011

Cadence is Crucial

There's a delightful book called If You Give a Moose a Muffin. My forthcoming missive on iterative software development is tentatively entitled
If You Give a Clown a Metric
Cadence is the most important aspect of iterative software development. I am weary of misconceptions about velocity. I'm weary of re-treaded PMs turning velocity into a blunt instrument.

The Law of The Swift

Cadence is the vastly under-reported life-force behind iterative development.

So, two days into your second sprint, if your panic-strickened PM adds two new developers, then prods & pokes you about squeezing in another story or two, I advise you to diplomatically offer the reminder that
Half a Swift DOES NOT deliver twice the gas mileage.

This regressive misconception is formally known as Brook's Law. Brook's law says,"adding manpower to a late software project makes it later".

Brooks more famously quipped
Nine women can't make a baby in one month
~Fred Brooks
In the absence of distractive churn, seasoned developers need at least several iterations to establish a cadence. Forget the silly chart.

In honor of the 10th anniversary of the Agile Manifesto, developers who have, year after year, dragged dysfunctional balls & chains to the delivery finish line should not have to view another burn-down chart.

Adding a new developer mid-iteration is disruptive. Adding two new developers mid-iteration is, not surprisingly, also disruptive. Please don't knock us off the beat. Let us play a few bars into the tune before you pull the fire alarm.

All we ask as developers is that succinct stories with a bulleted list of testable assertions roll into our purview like so many chocolate kisses on a conveyor belt. Then, please step away from the conveyor belt so we can syncopate while gorging on chocolate kisses.

12 February 2011

It's a Marriage, Not a Stew

I'll use a horse racing analogy to illustrate a common Agile software #fail scenario:
  • The developers are thoroughbred horses, with rapid metabolisms, who are impatiently cantering.
  • The owners & the trainers over-value the necessity of their contribution. They stumble out of the gates while arguing about the fat and fiber content of the feed.
Some owners & trainers would be better off keeping draft horses. Those needing to stay in the race might consider some of the causes of this churn:
  1. Owners & trainers haven't a clue how to prioritize races.
  2. Owners & trainers involve champion horses in a swirl of the inconsequential.
  3. Owners & trainers segregate their horses into costly horse barns.
Prioritize Races

Much has been written about prioritizing stories for iterations that doesn't bear repeating. Suffice it to say, if you're a business owner who's unable to queue up what needs to be built, please spare us the absurd sauntering by finding another line of work.

Developers sniff out incompetence in a single ill-prepared meeting. They sense when you are in over your head - often before you do.

If you can't establish credibility out of the gate as someone who has a systems view, and who understands how to set priorities, you're toast.

Shelter From the Swirl

Why do managers embark into Agile without bothering to comprehend the principles?
The mechanics of Agile become a weapon when the principles of Agile are disregarded.
When managers are in over their heads, they rope potentially productive developers in invariably unproductive meetings. In those meetings, managers unintentionally expose their shallow understanding of the problem space (what) and their lack of vision (why) about the product. This is near fatal.
IT pros always and without fail, quietly self-organize around those who make the work easier, while shunning those who make the work harder, independent of the organizational chart.
~Jeff Ello
Once developers sense you're a shallow paper horse, all bets are off.

Don't conduct story mapping, iteration planning, daily stand-ups, or retrospectives until you understand their purpose, their necessity, and how they apply to your situation.

Segregation of Expertise

Don't do it. Segregate software expertise at your peril.

Everyone is, or has the potential to be, a soup-to-nuts developer. Good developers are much more than programmers. A good developer can be craftsman-like. I have worked with developers who care as much about test-driven development as user experience.

There is scant justification for separating people into expertise bins. There is scant justification for fire-walling user experience considerations, or data design considerations, from the development team.
If you're a technical person, but not on the development team, you're an outsider with an opinion.
Fahgettaboudit. Forget your data architects. Forget your user interface bozos. Forget your user experience schlubs. Your application deserves the attention of all of those considerations, but not in the form of extra-team "experts" with no skin in the iteration.

Everyone is a developer with varying degrees of exposure to the aforementioned skills.

Do find and nurture well-rounded developers. Better to find and nurture well-rounded developers, multi-faceted people, than to stable a bunch of experts with no skin in your iterations.
This is a marriage, not a stew
~Alan Cooper

30 January 2011

Attention Deficit - An Organizational Disconnect


Wildly productive software developers decompose confusing, and sometimes complex, feature narratives, or stories, into discrete programming tasks with verifiable endpoints.

Deconstruction of complexity, and its superficial step-child confusion, is analogous to the Divide & Conquer Algorithm.

Story tasking is rote work for developers comfortable following Agile principles. Tasking becomes a matter of iteratively (recursively in the case of the Divide & Conquer Algorithm) decomposing a new feature into logical groupings of tasks.

Tasks are deemed small enough when completion can be checked off by verifying simple assertions (e.g., Submitting an ID and Password Gives Access? True or False). Completed tasks, once re-aggregated, fulfill the feature requirements.

Undivided Attention

Divide and conquer feels like an intuitively advantageous problem-solving strategy. An overlooked advantage of divide and conquer is that it provides developers with the luxury of attending to one thing at a time.
Full Attention - attending to one thing at a time without distraction
The more atomic the problem space is, the less overwhelming it is to solve. The more focused our attention is, the quicker we can dispatch with a task.

Further, many craft-minded developers start a task with a test harness that frames the problem space so it can be poked and prodded with the binary confidence of true/false statements.

Remarkable things happen when we allow people to devote full attention to atomic tasks. Stuff gets done.
Attention is the most powerful tool of the human spirit.
~ Linda Stone
So, where's the disconnect?

Attention Deficit

Most organizations undergoing an Agile adoption, or those who have adopted Agile, enable developers to be productive by encouraging (and applauding) full attention to atomic tasks. Yet people on the business side of the software equation are rarely afforded the same luxury.

Organizations foolishly allow (and encourage) business owners, subject matter experts, project sponsors and stakeholders to engage in cross-cutting, superficial skimming.

Skimming is a form of Human Multitasking that subversively derails so-called Agile Software Projects. The developers are agile enough, but the business side is often asked to span products and projects which dilutes attention, thus decreasing effectiveness.

This discontinuity is a common, if not prevalent, red flag in the organizations I have worked with over the years as a contracted developer. I am on the verge of declaring
Agile software development never scales to large organizations.
But, never say never. I don't earn my keep coaching Agility in hostile, change-averse organizations, I just work in them. This assessment stems from unbiased observation - Agile might scale in large organizations, but I haven't seen it scale in the large organizations I have worked with.

Continuous Partial Attention

If Agile doesn't scale, what are the root causes? One root cause is lack of ownership (but that's a future post). Another root cause is the Continuous Partial Attention of stakeholders. Linda Stone created the meme Continuous Partial Attention, or CPA, to differentiate between simple and complex human multitasking.

To illustrate, I have observed a facet of the CPA phenomena where my daughter, could listen to Atmosphere on her iPod, watch Gossip Girl on television, and send text messages to friends while simultaneously solving her high school physics problems. No harm done - she turned in her physics homework on time. But it's a tiny leap to imagine scenarios where CPA becomes massively counter-productive.
"It usually involves skimming the surface of the incoming data, picking out the relevant details, and moving on to the next stream. You're paying attention, but only partially. That lets you cast a wider net, but it also runs the risk of keeping you from really studying the fish."
~Steven Berlin Johnson
How does Continuous Partial Attention impact our ability to execute software projects?

In my experience, the impact is resoundingly negative. There is shocking amount of organizational churn that occurs to frame and extract requirements in most software application problem spaces. The potentially positive impact of organizational experts is often watered down by systematic interruptions along multiple fronts.

Organizational experts must too often cast wide nets. Such wide net multitasking often begets a superficial, counter-productive depth of understanding of the problem space (i.e., you don't know the fish).

Superficial churn, as Steven Berlin Johnson's quote implies, precludes one from "really studying the fish".

26 January 2011

Finding Cadence in Dysfunction Junction

Imagine we are rowing crew-mates. We're sculling a river at an refreshing rate. Our cadence is palpable.

Now imagine adding a silly clown, with a silly clown-sized oar, into the mix. Imagine that the silly clown has no accountability to the crew, but has been ordered by a chief clown to stick his oar in.

The silly clown is ill-equipped since his oar is clown-sized. It's immediately evident he derives no pleasure from helping you or your crew-mates propel the craft. He only wishes to demonstrate his paddlry.

The boat slows, then sharply veers off course.

In the Agile software realm, the clown with the clown-sized oar, is one flavor or another of architect (see The Chicken & The Pig). He fancies himself as a title rather than an agent noun. You can be certain he's not on your team. If he was, he'd be called a developer...a developer who's accountable to produce working software, rather than artifacts.

For every wildly productive Agile project, I wonder if there are about five or so that have gone off the rails into dysfunction junction. It bears repeating that the Agile Manifesto has four easy-to-understand guiding principles:
  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan
Easy to understand, but challenging to implement.

It's a personal quirk, but one of my red flags is when people pronounce Agile with a long "i". There are other red flags, some funnier than others.
Sometimes red flags make me long for the white flag of surrender, then I remember practice and discipline.
I'm not a musician. Yet it's clear there's a distinction between loving the promise of sweet music and coaxing a coherent tune from a Stradivarius. The hard work can't be skipped. The practice can't be ignored.

I'm not an Agile software coach. CIOs who have the foresight to hire a coach to kick off an Agile adoption should be commended. Hiring a coach for Agile 101 sessions is like learning to play scales. Necessary, but not Mozart.

Without continued practice in Agile discipline, well-intentioned people revert to putting in more overtime while getting less done. Stand ups revert to sit-ins.

CIOs who conceive of an Agile adoption as a few cheerfully upbeat coaching engagements are mildly delusional. A realistic Agile adoption probably means a minimum 6-month slog by an embedded coach (or coaches).

If the principles are easy-to-comprehend, why is it so difficult to make it work? One impediment is people don't have ownership. Most organizations pay a bunch of salaried folks to ponder what they'd rather be doing. They don't give a rip about agile-smagile.

I'm glad I'm not talented enough to be a coach, because
What do you do with well-meaning folks who couldn't lift a feather in zero gravity?

Red Flags & Cadence

Your execution of agility might be poised to implode if your organization
  • prefers spreadsheets or software tools over low-fidelity PostIts and a Story board;
  • can't seem to re-purpose the static and limited title of architect into something helpful;
  • separates the people using the software from the people developing the software;
  • seems ladened with command & control management who are cynical about change;
  • doesn't comprehend the poignant parable of The Chicken & The Pig;
  • is reactive & accusatory, rather than thoughtful & nuturing.
If you recognize these, I urge you to hire a long-term Agile coach (or coaches). Ideally this person is half rock-star developer and half rock-star psychologist. With any luck, this person is also willing to slog it out in the trenches for months into years.


I suspect iterative cadence comes from something akin to an athlete's muscular memory. If that's the case, then think about, and retrospectively examine, how your behavior, your team's behavior, and the organization's behavior, reflects the four guiding principles in the Agile Manifesto.

Give it time and practice. Focus on the four guiding principles. Minimize distractions. Row, row, row your boat...every day, every week, every month.

11 January 2011

Agile in Toxic Organizations

Perusing the Agile 2011 proposals, I wondered if anyone in the Agile space addresses coaching Agile in the toxic organization. I'm not a coach, but I feel the coach's pain.

I have seen the Bright, the Lite, and the Dark Side of Agile. Please explain to me how one can be helpful bringing the dark into the light.

Do some organizations have too much of a baked-in reactionary culture to reap the bounty of agility? Are the pathetic schlubs walking the halls with their heads down merely avoiding the shrapnel of IEDs (Iterative Explosive Distractions)?

Do these soul-sucking organizations have enough banked karma to deserve the best intentions of passionate Agile coaches and the elbow grease of super-talented Agile developers?

Overheard on a speaker-phone during Project Chartering introductions:
"I'm Rose. I don't know why I'm here."
A subject matter expert with a meant-to-impress title, Rose made her deadpan introduction to her soon-to-be teammates.

Queue the crickets chirping.

Also remoting in, the speaker-phone voice of the CIO explains Rose's presence in the chartering session and what Rose's hoped-for participation would be on the team. Yikes. Gotta love that business buy-in.

Toxic organization is a loaded term. One characteristic of a toxic organization is that
The people most comfortable with command and control often mistake agility for the more familiar reactionary.
Just bark at me if you think I might ease your slither from the dark into the light. Otherwise, I'll join my heads-down comrades in C-Sharpistan.

02 January 2011

Hello World! in 2011

Knowing I needed less than 40 ASCII characters to pronounce Hello World in FORTRAN, I set about to determine what it would take to do the same in Silverlight using Prism and the Model View ViewModel or MVVM pattern.

Back in the summer of '82, huddled in front of a venerable VAX terminal, I tapped out my first computer program.

Hello World! gave me a chill -- particularly remarkable since this happened in a sweltering computer lab at the University of Minnesota. Our pampered VAX was housed in a chilly meat locker of a room - a room much more accommodating than the undergraduate computer lab with its solitary oscillating fan.

Three glorious lines of FORTRAN. And yes, less than 40 characters of code.

PRINT *, 'Hello World!'

Hello Silverlight, Buh-Bye Simplicity

Fast forward to 2011. This New Year weekend, I have been struggling with adapting a navigation framework for Microsoft Silverlight using MVVM. The stated intent of MVVM, and similar patterns like MVC, is separation of concerns; namely,
separating the presentation layer from the logic layer 
to make code easier to test and to have a pattern that's easy to build upon and to maintain.

Most of my agile colleagues, and mentors like Chris Bartling, are passionate about test driven development. I use TDD, and I think I understand where TDD shines. But I admit I am slightly more motivated by something as mundane as separation of purpose (i.e., old-school layers), because I like an approach to programming that makes stuff easy to create, re-produce cookie-cutter style, and, down the road, will make it a cinch to maintain or extend. Clean. Easy. Life's good.
Forget the complaints against complexity; instead, complain about confusion.
~ Don Norman
I cling to clean simplicity like so many Buckyballs. I despise sloppy confusion. I despise deciphering widely varied code formatting. I loath wringing drops of value from the software anti-patterns I encounter as a contract programmer. And I frequently go ape-shit unraveling spaghetti code.
If I put the hyphen in anal-retentive when it comes to consistent formatting of code, why do I need a machete to cut a path to my desk?
Yet I have struggled with adapting a canned MVVM navigation framework for Silverlight. Ostensibly, all that's needed is simple navigation. We need to register and load views on demand from a navigation framework. Sounds straight-forward. It ain't.

I started with the Prism Navigation Framework developed by Slobodan "Roboblob" Pavkov. Without Roboblob, I'm not sure where I would have started. Microsoft tends to release software tools that are half-baked and then backfill the shoddy effort with spotty documentation - Don't get me started on Entity Framework!

After 3 days of incisor gnashing, I have been able to adapt Slobodan's laudable work to something that just might suit our needs. I don't belittle Slobodan's framework as it must have taken a yeoman's effort.

Perhaps by necessity the solution to what should be a straight-forward problem, seems painful. By painful I mean fragile, almost inscrutable, difficult to debug, and downright confusing for slightly above-average programmers like me - particularly considering we only need to provide hyper-links that load different views on demand.

Why does something that ain't rocket science have to seem so much like...rocket science?

Hello World 2011 in Silverlight

Writing Hello World in Silverlight, I needed 2 projects:
  • a Silverlight project for the application that includes both the View and the ViewModel, and
  • a web project to render the Silverlight. This project has an HTML file with a tag that references the Silverlight object created above.

It seems that Hello World in 2011 via Silverlight requires,
  • a 74 line HTML file that has the tag containing the Silverlight object;
  • a 55 line XAML file that contains navigation and a container for the View; and
  • some 23 lines of XAML in the View to say Hello World!

Perhaps I've exaggerated the effort since Microsoft makes Hello World so easy that even an aging bonobo with cataracts could code it with 3 clicks and a cut 'n paste. What happens when I need more than Hello World?

I am beginning to wonder about confusing & seemingly gratuitous complexity; albeit confusing complexity added in the good name of testability, flexibility, and modularity. My questions are two-fold:
What is the cost of confusing complexity (necessitated by an ostensibly clean pattern)?
How much are we blinded by the laudable lights of testability, flexibility, and modularity?