Tag Archives: Software

Homeland Secured?

The man who would choose security over freedom deserves neither.

-Thomas Jefferson

I’m spending this week with Luke working on Puppet and since he lives a good long walk from where I live, I had to spend three hours on a flight to get here

I haven’t done a lot of traveling in the last few years, and apparently I have been missing out on some real fun at the airports. (For the last few years, work and home have all been in a 5 mile radius, which I was nice.)

Approaching the security check point, as I was being inundated with signs and sounds concerning what is and isn’t allowed through, I realized that I had a bottle of cologne that was definitely over the limit. This isn’t super fancy stuff, but it was a gift and I didn’t want to lose it. Realizing this, I asked the gentleman checking my boarding pass, the last step before the XRay conveyors, and he suggested I pull it out of my carry on and put the cologne through the XRay machine by itself.

So, that’s what I did. I took the 4.2 oz bottle of cologne out of my luggage, put it on the tray, with my wallet and cell phones, and proceeded through the metal detector. I found the take-your-shoes-off shuffle a bit disconcerting and slightly dehumanizing, but that’s the world we live in and I don’t get to make all the rules.

Here is where things get interesting, the cologne gets through without a second glance, but the XRay crew wants to confiscate my 80% empty tube of toothpaste.

Uhmm, Ok, take it, a small sacrifice to balance out the universe and keep my bottle of cologne.

So I re-shoed and went on my merry way.

Now I don’t pretend to understand all the issues of why I can no longer travel with toothpaste, and I certainly don’t begrudge the young man doing his job, I just find a certain irony in the capricious enforcement.

Why is this on my blog about software development?

Does your team have any (silly?) rules about how something should or shouldn’t be done? Are those rules arbitrarily enforced based on whim and circumstance?

Can you not check in a mostly empty tube of toothpaste, but it is perfectly acceptable to commit the 4.2 oz cologne, if you put it on the XRay conveyor by itself?

Problem Solved

I’m sure code everywhere will sleep better tonight knowing that your process protects it. . .


Dysfunction: Inattention to Results

Never mistake motion for action.

– Ernest Hemingway

The final dysfunction from The Five Dysfunctions of a Team is Inattention to Results. This ultimate team dysfunction occurs when members of the team value something other than the collective goals.

This dysfunction doesn’t mean they have lives and balance outside the context of the company (that’s another post. . .) but that the members of the team are focused on highlighting their own achievements regardless of the overall outcome.

You can smell this dysfunction when individuals or groups start to point to everything they did right, even when the overall project is flailing. (maybe especially when it is flailing)

“Product management did such a good job of creating requirements, its those lousy developers that didn’t understand, I mean just look at this pretty document. Don’t you love the font . . .”

“I wrote the code exactly to the spec, not that those idiot clients and product managers know what they want anyway . . . I am a programming god.”

Have you ever participated in either side of that conversation? Played Not-my-fault-I-am-teh-awesome hot potato?

(Quality Assurance gets blamed for everything, cause as everyone knows ‘kwalytee’ starts with the last people who touched the software, duh. . . You do have QA, right?)

There is nothing so useless as doing efficiently that which should not be done at all.

– Peter Drucker

Inattention to Results is most damaging to an organization when it becomes institutionalized processes. When people stop trying to do the best thing and just make sure they go through the checklist.

When things go South, the checklist becomes a buzzword compliant shield, an Agile security blanket.

When I first read the model, I thought the most important dysfunction to address was trust, because it is the foundation of all the other dysfunctions. After a little reflection, I’m starting to think that you need at least as much focus on results, if not more. Sure you need to work on trust, because if you don’t, eventually the rest of the dysfunctions grow to be monstrous, but ‘winning’ gives you the opportunity to work through a lot of trust issues. Especially, if working on trust (. . .conflict, commitment, accountability. . .) is an explicit goal.

This is all well and dandy, but what does that mean? How can I use this?

There is not a formula that you can just plug in and solve this problem. On some level, this is all about culture. On another, an individual, not on top of the food chain, recognizing these dysfunctions has to navigate between Scylla and Charybdis. One becomes faced with the prospect of being at odds with the perception of management, watching and suffering the dysfunctional culture, or finding something else to pay the mortgage.

(eh, maybe that’s why the book’s target audience is executive teams. . .)

Insanity: doing the same thing over and over again and expecting different results.

– Albert Einstein

what to do?

Reflect and adjust my friend. . . Reflect and Adjust

add to del.icio.us :: Add to Blinkslist :: add to furl :: Digg it :: add to ma.gnolia :: Stumble It! :: add to simpy :: seed the vine :: :: :: TailRank :: post to facebook

Dysfunction: Avoidance of Accountability

The ancient Romans had a tradition: whenever one of their engineers constructed an arch, as the capstone was hoisted into place, the engineer assumed accountability for his work in the most profound way possible: he stood under the arch.

Back to The Five Dysfunctions of a Team, so we have built up Trust, Conflict and Commitment. What do we need now?

Accountable: subject to the obligation to report, explain, or justify something; responsible; answerable.

In the model from the book, the avoidance of accountability is a psychological byproduct of the underlying dysfunctions of the team. Without firm commitments, after healthy disagreements are addressed, there is a tendency to not hold people accountable. We have a hard time holding people accountable, when we know they never really committed.

Ok. . . uhm, and?

How many of you have witnessed(participated in) the following scenario?

  • Incredible pressure to deliver a product/feature
  • Developers are hacking their little hearts out (very few tests being written, of course)
  • Quality Assurance is testing whatever they can see flying over the wall (with little or no prior knowledge of what it will be, bless their little hearts)
  • Product Management is doing whatever they do (anything but looking at what is actually being developed)
  • Daily stand ups where no problems are mentioned
  • We are so Agile, yay

Features delivered are a disaster. . . PMs are freaking out, Devs are indignant, QA is whimpering in the corner. What happens next? Rinse and Repeat. . . WTF?!??

I believe one of the fundamental principles of all Agile methods is ‘Reflect and Adjust‘. The built in adjustment is only going to help your team if it isn’t used as an excuse to ‘just do better next time’.

It is not only what we do, but also what we do not do, for which we are accountable.

– Molier

That doesn’t mean I’d advocate command and control shock and awe style, that just puts everyone into ‘cover your donkey’ mode and totally destroys the foundation of trust.

Honestly, Good Product Management is HARD. Good development is a creative endeavor that ebbs and flows. Good Quality Assurance is an acquired skill. All of these pieces are heavily dependent on each other.

Holding each other accountable doesn’t have to be antagonistic, but it does have to be honest. (truth, remember)

Brutally honest… Shit happens, but it doesn’t have to happen all the time.

Around the time of Caesar, there was a European tribe that, when the assembly horn blew, always killed the last warrior to reach his assigned place, and no one enjoyed fighting this tribe.

Don’t settle for mediocre, for yourself or for your organization.

Some people can’t handle ‘Truth’, and that is the seed for every other dysfunction.

Change your ‘organization’, or. . . change ‘your’ organization.

add to del.icio.us :: Add to Blinkslist :: add to furl :: Digg it :: add to ma.gnolia :: Stumble It! :: add to simpy :: seed the vine :: :: :: TailRank :: post to facebook

Dysfunction: Absence of Trust

“I’m not upset that you lied to me, I’m upset that from now on I can’t believe you”

– Friedrich Nietzsche

Trust is a funny thing.

The absence of trust described in The Five Dysfunctions of a Team is essentially the opposite of what Alistair Cockburn refers to as ‘Personal Safety’. Trust is a ‘prediction of reliance’ that your peers intentions are good and any vulnerabilities will not be used against you.

An ‘absence of trust’ can appear to take other forms in software development, for example, ‘we don’t trust those incompetent mother #$%@&ers in product management/engineering/quality assurance’, but I’m going stick with the model in the book for now. (Maybe you’ll get two bonus dysfunctions: ‘Absence of Faith’ and ‘Absence of Competence’, but I digress.)

The book contends that trust is the foundation of teamwork and if a team doesn’t trust each other enough to personally expose weakness or raise concerns without fear of reprisal, then they are condemned to suffer from all the dysfunctions.

How many times have you seen a programmer spend hours, maybe even days, banging away at some problem that the person sitting ten feet away knows cold?

How many time have you endured the strategic conversation about what can and can’t be shared with another team?

How many times have you bit your tongue watching what comes into the version control repository?

Why does this happen? The smug pedantic lesson from someone who learned from banging his own head. The firestorm that happened when information was divulged. The vacant stares and shrugs because the code ‘works’. The seeds of mistrust are planted as a defense mechanism to some unpleasant experience.

The basis of trust is truth. If everyone can focus on the truth, then trust becomes a non issue.

The truth is some people know things you don’t. The truth is you know some things too. The truth is the best thing for the team is to share your knowledge. Ironically, the best thing for the team is to also share your ignorance. The truth is you should try not to be smug when enlightening your team. The truth is you should probably not take things personally when someone is trying to teach you something.

Without the truth, how can you make decisions? Sometimes the truth sucks, would you rather have it dressed up in buzz wordy power points? Is that going to fix anything?

Without trust, a team will waste an incredible amount of time and energy managing their interactions. Without trust, a team will be reluctant to offer or ask for assistance. Without trust, a team will have low morale and unwanted turnover.

What about your team?

add to del.icio.us :: Add to Blinkslist :: add to furl :: Digg it :: add to ma.gnolia :: Stumble It! :: add to simpy :: seed the vine :: :: :: TailRank :: post to facebook

Dysfunctions of a Team

So. . . where were we. Oh, yeah, yeah, software development. . .

The scope of most software projects are such that at least a few people need to be involved to keep the whole thing together and moving forward. (Of course there are exceptions, but the need for people is probably true about most undertakings)

Computers, for the most part, do exactly what the software tells them to; people. . .uhm, not so much.

I’m going to borrow from a model in the book: The Five Dysfunctions of a Team and apply it to software ‘teams’. (The original model is formulated and applied to executive teams and is presented in the context of a ‘fable’. This is a short book, packaged and marketed to executives, but we shouldn’t hold that against it. The model makes sense to me, though I may be distorting things, so I encourage you to read it for yourself.)

The dysfunctions are modeled as a pyramid with five levels, with dysfunction at a lower level ensuring dysfunction on every higher level.

The dysfunctions from the foundation to the apex:

  • Absence of Trust
  • Fear of Conflict
  • Lack of Commitment
  • Avoidance of Accountability
  • Inattention to Results

A software development team is not just the ‘developers’, which have their own special taxonomies of dysfunction. The ‘team’ would include the business analysts/product managers, the testers, the developers and in some Agile Fantasy Land ™ maybe even the customer.

Each of the dysfunctions probably deserves to be illuminated, but for now you get the condensed version. . .

Without trust that everyone involved has good intentions, teams tend to break into silos and bunkers and hide anything that might be seen as a vulnerability from the untrusted. Therefore teams do not genuinely engage and fear healthy conflict. As a result of latent unresolved conflicts, the team will not truly commit. Psychology takes over and we do not effectively hold others accountable without their commitment. And finally no one is focused on overall results; we are too busy focusing on how to frame personal accomplishments in the best possible light, while the disasters all around us are some other’s failing. . .

Notice, there is no mention of software, but I’d venture that most people reading this with any experience in software have seen these dysfunctions ‘in the wild’. Let’s be honest, most of us have probably contributed to the dysfunction.

The first step is admitting you have a problem.

add to del.icio.us :: Add to Blinkslist :: add to furl :: Digg it :: add to ma.gnolia :: Stumble It! :: add to simpy :: seed the vine :: :: :: TailRank :: post to facebook

Perfunctory Introduction

I should welcome myself to web 2.0 or something. . .

Some people might consider me somewhat a technologist but that is misleading and superficial, at least in my opinion.

I’m fairly decent with technical things and thankfully that has allowed me play with some really cool stuff and to cash some checks to feed my family, but I have other interests and abilities involving art, communication, culture, athletics, food and the human condition just to start the list that extends into the horizon.

I think that makes me better at technology, but maybe it just keeps me from being bored

Living in Salt Lake City has also given me the opportunity to absorb Agile software development philosophy and practice from close to the source. Alistair Cockburn‘s Agile Roundtable is an excellent resource for anyone who wants to drink from a well of creative insight. I’ve also been influenced by the local XP community, specifically Zhon Johansen.

I’ve recently dedicated myself to building a life for my family around an Open Source software project called Puppet. (crazy, I know) Puppet was conceived and written primarily by Luke Kanies, after working for years as an operational sysadmin and then as a system automation consultant. I believe Puppet represents a significant step forward in system management. I am not alone.

Puppet is written in Ruby, which is a pleasure to read and write, at least after years of primarily C++ and Java. (with a smattering of bash, python, perl, tcl, matlab and javascript thrown in for good measure) Ruby (and Puppet) also awoke a latent interest in functional languages and declarative constructs.

This blog will capture my thoughts and observations, my trials and tribulations, both past and present, concerning how technology and people come together to create value and opportunity. Maybe it will be useful or amusing to someone else. . .

Sometimes I might just rant 😉

%d bloggers like this: