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:

• JQuery 1.6 is 90,518 bytes (minified).
• Yahoo.com's home page is 219,583 bytes.
• Apple's base iPhone 4S uses 190,157 bytes.

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.

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.