Anger isn’t good for anybody

I had a weird sort of realization recently about some anger that I’ve been carrying around for some time now.  Up until that moment of realization, I had seen myself and completely justified in my anger.  It has become such a good comforting friend over the past few months that I almost feel threatened at the thought that I should lay it down and walk away.

I’m not saying that I suddenly believed that my anger was not justified.  I still think that I had a right to be angry… but I think that my license expired months ago.  I need to let it go and move on.  Anger isn’t good for anybody, not for the person on the receiving end of the anger and even worse for the person that is carrying the anger around.  I know this, but it’s often hard to see what’s right in front of your face or, in this case, in the mirror.

I do remember reaching a point a few months ago where I was tired of carrying it around before and wanted to let it go because it was weighing me down.  But I don’t think that I saw it in the same way as I do now.  Then I was just tired, I didn’t worry about it anymore.  But now I see it as a personal failure that I have not been able to let it go and spend effort on more important things.  So much wasted energy!  For what!?!

Now, I know that I can’t magically make things all better (nor should I have to), but I need to do something to heal myself.  I must work to consciously not pick up the anger again.  I need to put down the anger and walk away because it’s sapping my strength, and I need that energy for more important things.

Movement != Momentum

Momentum is an interesting thing.  One of those cheesy “motivational” posters states “Momentum: It is not of importance where we stand but in what direction we are moving”.  Cheesy?  Yes.  Partly true?  Sure.

The problem is that movement can cause the illusion of momentum.  Let’s do a little physics refresher.  The equation for momentum is:

   

• p = momentum
• m = mass
• v = velocity

If you have friction, you might be able to exert enough force to overcome that friction and move for a brief period of time, but as soon as that force is removed, the counterforce of friction quickly slows things to a stop. 

This stop and start movement does not equate with momentum. In terms of your life or team, if you have momentum, one change can trigger another change, can trigger another change, like an avalanche.  Working to get some movement is important, but do not mistake it for momentum.  To get momentum, you need to increase force or reduce friction.  Probably you’ll need both!

Stop and start movement can yield positive results, but it requires too much effort and is not sustainable.  Getting “the big Mo” (as Josh Lyman calls it) is very important to any effort.

Impractical != Impossible

Recently at Utah Code Camp, I got into a conversation about which solution should be used to solve a problem (given that there are multiple solutions… and there normally are).  Somebody (yeah, I didn’t get his name… my bad) mentioned that he had a boss that always looked for the “third best” solution.  This was based on the assumption that 1) the “first best” solution was “impossible” and 2) the “second best” solution was too expensive.  That was supposed to make the “third best” solution the “best” solution.

Well, somebody else commented that an “impossible” solution wasn’t really a solution and I agree!  What he really meant (after some additional explanation) was that it was impractical as he commented that it might be a viable solution in a few years.  Things that seemed impossible only a few years ago are common! 

Think about some examples:

• Imagine telling someone a few years ago with dialup about streaming high definition video.  Impossible!
• Imagine telling someone in the era of tube TVs about high definition flat panel displays.  Impossible!
• Imagine telling someone in era of computers that filled rooms that you would one day have a gigahertz processor and gigabytes of storage in your pocket.  Impossible!

To me this emphasizes the fact that we should be careful how we use absolute terms such as “impossible” or “never” or even “always”.  Using these terms can limit your credibility as it takes only ONE counterexample for you to be proven wrong.  Use them with care!

Featured on Management 3.0

I recently had my first guest post and was featured on the new Management 3.0 site that is being run by Jurgen Appelo of http://www.noop.nl/ fame.  It’s my post on Absentee Management, check it out!

Recommended Reading

I’ve been wanting to put together a recommended reading list for some time now, so I guess I’m going to not let “best” be the enemy of “better” and just do it.  I have added a small link to it below the “about me” side bar (which I will work on making more prominent soon… need to clean up the sidebars at some point).

Or you can use this link to view my recommended reading list.   None should be a terrible surprise if you’ve read any of my posts.  I’ll go back and elaborate on them more in the future (give my reasons and analysis) as well as expand (and possibly contract) the list.  Enjoy!

Good vs. Great; Better vs. Best

In Good to Great, Jim Collins states that “good is the enemy of great.”  In Working Effectively with Legacy Code, Michael Feathers states that “we can’t let ‘best’ be the enemy of ‘better’”.

On the surface these seem contradictory, but I would argue that they are, in fact, complementary.  I have been very much guilty at times of getting “analysis paralysis”, being overly concerned with the “right answer” or the “right way”.  In that case, where you have nothing, doing something is better than doing nothing.  At the very least, doing something, even if it’s wrong, gives you feedback that it’s wrong and you can move on.  The trick is to do something that is low risk.  The smaller your something is, the faster you can get feedback and adjust.

This goes with the “release early” philosophy of agile.  The other part of that philosophy is “and iterate” which is important as well.  Getting something done allows you to take it and improve it.  Having something concrete via quick prototyping or tracer bullets and iterating can get you there faster than waiting for the “right way” to become apparent.  If we always think “I don’t have time to make it perfect so I won’t do anything” we will never do anything.  “Best” becomes the enemy of “better.”  Martin Fowler said as much:

When you actually sit down to write some code, you learn things that you didn’t get from thinking about them in modeling terms. There is a feedback process there that you can only really get at from executing some things and seeing what works.

Once we get something good enough, the problem then becomes the attitude that “I don’t think it’s worth the effort to improve it, it’s good enough.”  And here is where “good is the enemy of great.”  The problem becomes when everything is humming along “well enough” that we become complacent.  That is until something shakes things up.  Like when the weight of defects reported become overwhelming because the code was not kept clean and non-legacy (no automated tests).  Or when an economic downturn hits and you realize that you didn’t take the opportunity during the “good years” to fine tune things or expand and improve and are now faced with tough decisions.

We need to be constantly improving (in code, in business and life), not settling for good, striving for great, but not so worried about best that we don’t pursue better.

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.