Stories about Software


Agile for Introverts: Re-Imagined Programmer Collaboration

As I mentioned in a recent post, I’ve been listening to Susan Cain’s, “Quiet: The Power of Introverts in a World that Can’t Stop Talking.” I also mentioned that I’d be saying more on the topic, and here comes some more.  Today it’s going to be the idea of Agile for introverts.

In recent weeks, I’ve spent some time running a bootcamp of sorts that covered, among other things, XP and Scrum principles. Personally, I find that I light up when talking about clean coding practices and that I’m a bit more tepid when it comes to explaining process particulars. Reflecting one evening, it struck me that a lot of the practices involved in Scrum ceremonies and some of the XP practices aim to draw people “out of their shells.” In other words, a lot of agile is the Extrovert Ideal brought to programming.

This made me wonder what some Scrum ceremonies and/or XP practices might look like if they were introvert-friendly. That is, how could one accomplish the goals of these activities in ways that didn’t assume “let’s all get together and collaborate always!” was the right way to think.

What is introvert-friendly?

Before I can offer thoughts on how to make something introvert-friendly, I want to define what I mean by that. I feel it’s important to do so because the definition most people would assign by default is “things that don’t require interaction with others,” and that’s not right.

I’m going to go out in a limb here a bit and assume that I’m a good representative of the introvert population as described by Cain. I don’t feel that this is too much of a reach, since I got a 20 out of 20 on the informal “are you an introvert” quiz. So, I’ll explain my own psyche and trust that you find it reasonably representative of how you feel if you are also an introvert.

I don’t seek to minimize social interaction, per se, but I do shy away from unpredictable situations with a large amount of stimulus.  I also have an intense preference for a sort of social order that is predicated upon minimized conflict and a world in which information and opinions aren’t generally shared unless solicited.  You can actually read back through my blog posts and see a lot of this described before I’d ever heard of Susan Cain’s book.

There are probably more, but these certainly capture some of the themes at play here.  And from this basis, I propose the following concepts as introvert-friendly.

  • Differences of opinion are resolved by folks having time to process different viewpoints and build a case rather than by extemporaneous argument/debate.
  • Meetings and gatherings are limited in size.
  • In professional situations, it’s better to remain silent unless you have something high value to say, especially in larger groups.
  • Interpersonal interaction is primarily for camaraderie and logistical resolution (e.g. knowledge transfer or merging code), rather than important work.
  • The most productive work happens in a state of flow when you can tune the world out and concentrate.
  • It’s worth letting a group make a sub-optimal choice to preserve social harmony.
  • It’s good to be able to opt out of groups that frequently make sub-optimal choices.

Notice that none of this is, “I want to be home, alone, always, with no interaction.”  That’s not introversion — that’s being a recluse.  Rather, this is “I prefer orderly interactions, a cap on external stimulus, and time and space to form my ideas.”

Read More


If You Promote Bad People, You Promote Bad Culture

Most of my cynicism toward the corporate world is safely directed into my new book these days, so there’s not a ton of spillage onto the blog.  But I’m going to make an exception today and talk about corporate culture.  To understand some of the terms I’m about to use, you can buy the book, if you’re so inclined, but you can also see an original definition here in this post.

I originally intended for my notes on this topic to make it into the book, but one of the main uplifting themes of the book is that I see programmers creating a professional working arrangement in which the corporate idealist doesn’t exist.  And since deliberate company culture, which I’ll refer to as “corporate religion,” is largely theater for idealists, spending a lot of time talking about it in the book would be somewhat superfluous (I do mention it, but not extensively).  But that’s not to say that corporate culture and religion don’t matter.  And, all these half-formed notes I have ought to go somewhere.  So, here they are.

Corporate culture is more or less defined by three things: what it takes to advance within the company, and what it takes to stay in the same role within the company, and what it takes to be walked out by the company.  Paintball outings and “bring your pet to work” don’t define or even describe company culture.  Perhaps more surprisingly, neither do things like company “mission,” “values,” and “principles.”  These things, which constitute corporate religion, are mainly orthogonal to culture.  Corporate religion consists of ceremonies, outreach activities, and the official canon (mission statements and expressions of “official values”).  But none of these things are culture, any more than the Ten Commandments, New Testament, and church bake sales are the ‘culture’ of a rural evangelical town in the USA.

If you look up the definition of the word culture, you’ll have to scroll all the way down to definition number 5 to get to an actual definition of corporate culture.

The behaviors and beliefs characteristic of a particular social, ethnic,or age group: the youth culture; the drug culture.

For our purposes here, we’re talking about the social group “people who have opted to work at this company.”  This means that we’re talking about behaviors and beliefs of employees when we talk about culture, and this is why culture and religion are disparate and sometimes orthogonal entities.  Corporate employees are forced to attend religious ceremonies and memorize the canon, but what they actually believe and do outside of structured activities is another matter altogether.  Plenty of people who show up to church every Sunday go forth immediately afterward and pound beer and gamble on football.

ArmchairQuarterback Read More


Your Old Language Version is Costing You Money

Editorial note: this post was originally written for the Infragistics blog, and you can read the original here.  Check it out on their site and read the rest of the stuff there, as well.

Imagine that you walk into a company, and take a stroll through the software department.  All around you, as far as the eye can see, developers toil away, staring into 17 inch CRT monitors.  What would you think of that?  Would you have to restrain yourself from jogging over to the HR department, enthusiastically, to apply for a job?  Or would you thank your lucky stars that you worked somewhere else?  I’m betting the latter.

One of the most penny wise, pound foolish strategies that a company can pursue is hiring a team of software developers, whose mean salary may be in the six figure range, and saving a few bucks by forcing them to do their work on obsolete hardware.  It’s foolish because the productivity lost by these expensive workers far outpaces the cost of updated computers and monitors.  Of course, this is pretty commonly known these days.  You don’t see or hear about nearly as many companies skimping too much on a second monitor or new machines for software developers.


And yet, it’s still fairly common to make developers use older versions of programming languages and frameworks.  Now, this isn’t a completely direct parallel.  Companies historically have let hardware age on developers’ desks mainly as a cost savings strategy, whereas continuing to work on a “stable” version of a language or framework is generally a risk minimization strategy; why port your code base to v-next when that could introduce bugs and it doesn’t matter to the users?  That’s a fair argument, but the thing is, when you pull back a level of abstraction, risk minimizing is, at its core, still about cost savings.  In a company, everything comes down to top line revenue minus bottom line cost. Read More


Scrum Master + Team Lead = Team Master?

Last week, I gave the Scrum Guide a fresh read.  I did this for the simple purpose of making sure I was remembering the rules of the game correctly, and not just having conversations based on echoes of memories.  It turns out that my understanding and recollection had not drifted very far, which was good news.  But it also turns out that I still think of “Scrum Master” as somewhat silly.  I re-read the manifesto, had the same impression, and was somewhat gratified to learn that I have the same taste as myself.

What is a Scrum Master, Anyway?

There’s a lot to like in the Scrum guide, but Scrum Master, in my opinion, just isn’t in that bucket.  At best, it’s a built in sales role for Scrum, and one that should become unnecessary as time passes.  The guide itself is pretty unambiguous about this: “the Scrum Master is responsible for ensuring Scrum is understood and enacted.”  Presumably, once Scrum is “understood and enacted,” the role need not exist.  At its worst, “Scrum Master” is an escape hatch for non-technical project managers in an agile world that largely proclaims them unnecessary (unless re-cast as BAs, product owners, or line managers).


Unfortunately, and in far too many organizations, I think that Scrum Master winds up at its worst.  Scrum falls under the umbrella of agile methodologies, and it says something right there in the agile manifesto (or, at least, the principles behind it) about how to organize teams: “the best architectures, requirements, and designs emerge from self-organizing teams.”  This describes a scenario in which empowered and engaged technical folks figure out how to deliver value to interested stakeholders without relying on traditional command and control structures.

In other words, agile teams (and, by extension, Scrum teams) don’t need managers or masters.  They need a “product owner” to represent the interests of the business and… well, that’s it.  They need someone to explain to them what’s needed out of the software and then it’s up to them to go do it.  It’s refreshingly grass-roots.

Read More


Prediction Markets for Software Estimates

The ongoing kerfuffle over the “No Estimates” movement is surreal to me.  So before I get to prediction markets for software estimates, I’ll discuss the surreal a bit. Instead of attempting to describe it, which, I can only imagine, would be meta-surreal, I’ll make use of an allegory of sorts.

No Wedding Estimates

Imagine that wedding planners have long struggled with an important issue.  For years and years, their clients have asked them to help pick a date on which it would not rain so that they could have outdoor weddings.  And, for years and years, their predictions have been spotty at best, resulting in irate clients, wet formal wear, and general heartburn.

In all that time, wedding planners have pored over weather patterns and diligently studied farmers’ almanacs.  And yet, the predictions did not substantially improve.  It got so bad that a group of upstart wedding planners met one year in the mountains and authored a document called “The Contingency Manifesto.”  This resulted in an important advance in wedding planning for outdoor weddings: reserving a backup plan not dependent on the weather.


And yet, not all was fixed.  People still wanted outdoor weddings, and continued to be disappointed when it rained, contingency notwithstanding.  They still demanded wedding planners help them figure out months and months in advance whether or not it would rain on a particular day.  And, this is understandable after all — weddings are important.

Quite recently, a group of wedding planners emerged under the hashtag #NoOutdoorWeddings.  Their message was simple: “we can’t predict the weather, so have your wedding inside and stop whining.”  The message was, of course, music to the ears of frustrated wedding planners everywhere.  But some planners and most clients balked.  “How can you tell the clients not to have weddings outside?  They’re the ones paying, so it’s our obligation to facilitate their wishes!”

This schism, it seemed, was irreparable.  And surreal.

  • Why is it necessary for wedding planners all to agree?  Can’t the ones that don’t want to deal with weather contingency just not do it and the ones who want to can?
  • Why can’t people figure out that trying to predict a chaotic system like the weather is a fool’s errand?
  • Why would you ask a wedding planner to make a prediction that could easily be influenced by his own interest?
  • Frankly, if one person is dumb enough to ask another to predict the weather on a day 9 months from now, and the other person is dumb enough to do it, can’t we just agree that the two deserve each other and the inevitable lawsuit?

How Estimation Actually Works Today

Read More