Absentee Management

I heard the report “3 Weeks After Quake, Shelter A Main Concern in Haiti” on NPR recently.  It made me quite sad to hear about all the people that want to help (from inside and outside Haiti) and those that want to get started with rebuilding their lives, but are unable to do so with any sort of efficiency because of a lack of any sort of management direction (from the government of Haiti or the UN or anybody).

If you don’t have time to listen to the report (only about 4 minutes long), some of the phrases in there are:

• Some feel that they “should be focused on a longer term solution”
• Some reconstruction is taking place but “not under any sort of coordinated plan”
• Some are working on their own but it “can be quite dangerous”
• The government is “working toward a plan, discussions taking place”

“Discussions taking place”?  One of my favorite phrases lately has been “talk does not cook rice”.  In this case, talk does not save lives or rebuild a country.

So what does this have to do with software development?  In agile we often talk about “self-organizing teams”.  Often we talk about “getting out of the way of the team”.  This does not mean that management has no role in agile.  In fact I would argue that management’s role is even more important!  At the very least managers are responsible for:

• giving parameters for the work to be done (may be in the form of backlog, a product vision),
• providing necessary resources to the team (monetary or people) and
• removing the team’s impediments (make sure the team isn’t stuck).

This means that they should be doing, not talking.  Mapping out a course, not just discussing it.  Figuring out which way to point the team next and getting them the resources to get there.  Otherwise the teams will start taking things into their own hands and that “can be quite dangerous.”  At the very least it will result in wasted effort. 

Even in an extreme case like Red Gate’s “Down Tools” experiment (which I’m curious to see what the results are) you can see these elements:

• “The only aim is to create something relevant to Red Gate that you wouldn’t have created otherwise.” – but there is a clearly stated aim and “The only rule is that you have to complete something by Thursday lunchtime.”
• “Each team will have a discretionary budget of £500 for hardware / software / other stuff we don't already have in the building” – while this may not be enough for a super ambitious project, it should be more than enough for 4 days and it does set some parameters.  Most importantly it says “we’re behind this… with our pocketbook”

A team that is trying to self-organize without management’s direction and help is going to fail almost by definition as they won’t know what to look for in success.  Obviously the stakes for the people of Haiti is much higher, as in many cases we are talking about survival, not just another software project.  But just like the people of Haiti, if a development team has no direction, no resources and no help with impediments, the journey will continue to be bumpy.

Blame tied to Responsibility

When code with a major defect is released to the customer, who’s fault is it?  Who do we blame?  Scott Bellware just posted basically saying “it’s not the tester’s fault”.  I think it’s fair enough to say that the “QA missed something” syndrome is not healthy, but neither is “there's nothing that QA has ever missed that developers didn't miss first”.  The problem with the argument that “It's less of a tester's job to check that a developers' code is right, but that their tests are right” also implies that the tester didn’t “do their job” because they didn’t find the holes in the tests that lead to the defect not being caught and therefore, released.

This finger pointing usually happens in organizations where “QA” is the “gatekeeper”.  Sometimes that is the role that the organization has given them or the one that they have set up for themselves.  Either way they have implicitly set themselves up as being blamed for any defects that are released.  Is that fair?  Maybe not, but you can’t have it both ways.  You can’t simultaneously be responsible for it and not get the blame.

Of course this is coming from a programmer. So what’s my point?

The attitude on an agile team should be the team missed something.  And in an agile organization, “the whole organization missed something.”  To pin responsibility for any particular failure on any one particular individual or role in an agile team is to absolve the other members of the team from responsibility for success or failure of the team.  The attitude becomes, “if QA is responsible, I can’t get blamed.”  Or conversely “if the programmer is responsible, I (the tester) can’t be blamed.”  Take away the “safety net of blame” and attitudes change… but more on that in the future.

So when a defect is released, who failed?  The programmer failed, the analyst failed, the tester failed, the user during UAT failed.  In reality the whole team failed, agile or not.

Good Grief Charlie Brown

If you are familiar at all with the Peanuts comic strip, you’ve seen this frame in various forms over and over again…

This situation was described aptly in The West Wing episode “The Drop In”:

"You are the Charlie Brown of missile defense. The Pentagon is Lucy." When Leo says he doesn't read the comics, the President explains, "Charlie Brown wanted to kick a football and Lucy would hold it except that she'd pull it away at the last minute and Charlie Brown would fall on his butt. . . . Each time Lucy would find a way to convince Charlie Brown that this time she wouldn't pull the ball away, but she would and once again Charlie Brown would fall on his butt." As the President predicted, Leo's high hopes are dashed, and the President tells him, "By the way, the words you're looking for are, 'Oh, Good Grief.'"

(summary provided by http://westwing.bewarne.com/second/34dropin.html)

So is Charlie Brown right to continue to trust Lucy or is he unable to learn from his mistakes?

A friend recently posted Cynicism & Professionalism which this is a kinda sorta response to.  Here is a partial quote of my comment that I posted there:

But I think it's always useful to keep in mind that most people are mostly trying to do the right thing most of the time.
Whether or not people's intent and their results end up in the same place or not, well that's another story (says the cynic ;) )

While “past performance is not an indicator of future results”, I think that we are unwise to ignore past experiences in formulating our response to the future.  Forgiveness is important.  Giving someone the benefit of the doubt is important.  Trusting that people’s intent is generally good is important.  But the lesson I get from Charlie Brown and Lucy is "Those who cannot remember the past are condemned to repeat it."

Sometimes you need to leave Lucy there holding the ball so that you’re not left saying “Oh, Good Grief.”

Programmers’ Mecca

Other than big sites like Microsoft and Google, this has to be the ultimate programmers’ Mecca…

 

(note: if you’re in a feed reader, you might need to go to the site to see the video)

Wipe the drool… and control the envy…

Failure

Sometimes failure is the path to success…

Do you understand the words that are coming out of my mouth?

Often when discussing a disagreement, the two (or more) parties involved will stop communicating.  The natural reaction of most people is to start to defend their position vigorously while ignoring anything the the others are saying.

This frustrates me to no end.

The common case is that both sides have valid points to be made and that usually, if both parties are really communicating (read: listening) and intelligent, one side will either realize that they are in error or both will adjust their positions to another better common position.  I have had numerous occasions when I have been arguing a point and finally started listening and realized that there was a way to get to “win-win” that wasn’t even on the table originally.

If you understand my position and reject it, I’m happy to “agree to disagree”.  But before we get there, we’re both going to need to get to a point where we understand the words that are coming out of each other’s mouths.

“I don’t have enough time”

Recently the Utah .NET User Group had a roundtable discussion where anybody could ask or answer any relevant question.  At one point the conversation drifted to “why aren’t there more people here” which is a valid point given that there were about 30 of us and there are certainly more .NET developers out there along the Wasatch Front than 30.  One would also think with the economy and job market as it is, that people would jump at the opportunity to get some free trainig either because they had lost their job or were worried about it.  There were various theories proposed but they were mostly based on the group speculating on others motivations which at a certain point became a somewhat futile exercise.

So in the next development meeting at my work, I through out the question, “why do you not go to the once a month user group meeting?” to find out what those .NET developers that weren’t coming thought.  I was a little bit disappointed that the common answer was “I don’t have enough time.”

Why was I disappointed?  Because this answer is a cop out.  Consider these questions:

• Why don’t you exercise? I don’t have enough time.
• Why don’t you read (more) technical books? I don’t have enough time.
• Why don’t you watch more movies?  I don’t have enough time.
• Why don’t you play more video games?  I don’t have enough time.

So why is “I don’t have enough time” a cop out?  Because what it really means is “I refuse to prioritize that high enough to do it” or “I’d rather be doing something else.”  And even that is not good enough, I think.  I think, for you individually you have to use the five whys technique.

Of the above list, those are all things that I’d like to do.  Recently (almost three months ago) I decided to prioritize exercise and have been getting up early to do it.  It’s something that I’ve known that I needed to do for some time but “I didn’t have the time.”  Which really meant that I 1) valued extra sleep over exercise, 2) valued staying up playing games over exercise and 3) valued all the other things I was doing in life over exercise. 

Now is that strictly true?  Did I really value video/computer games over exercise?  If you were to ask me a year ago, I probably would have said “exercise is more important that Civ IV” but my actions betrayed me.

So should I look down at my fellow developers that don’t attend the user group meetings?  No, I don’t think so.  If they have found other ways to develop their skills and forward their careers, that’s great.  There are many activities out there that will give you a lot of value.  If they don’t care and have other things that are more important in their lives, that’s great.  But if they think it’s important (and specifically more important than some of the other things that they’re doing), then they need to get their actions in line with their priorities.