My Dad was the stereotypical golf fanatic. I like golf, but Dad loved it. Over the years, we shared a good amount of time on the golf course, and I loved every minute of it... except perhaps those rare occasions where the ball didn't go where I wanted. Yes, that was frustrating (and actually not very rare at all), but the rest was pure gold!
Dad gave me lots of pointers about various aspects of the game that I use to this day. By far the best was after I strutted up to the 1st tee one day, determined to show Dad just how bloody far I could hit that ball. Yes sir, that poor dimpled piece of plastic & rubber would rue the day it was made! I know what you're thinking... I swung and missed the ball completely. Well that's absolutely not true. The ball travelled at least 20 yards, and plopped into a creek.
Dad & I are a lot alike, temper included. Knowing this, he thankfully didn't laugh out loud. He did say, though, that I should try again, except this time just take a nice easy swing. I hit the ball about 175 yards (which was good at that age) right down the middle of the fairway.
Years later, when I would go to a driving range I would invariably take a couple of rips with the driver. They would either dribble ahead 20 yards or would hook or slice horribly. Perhaps 1 in 20 would go straight. I would then follow Dad's advice and just take a smooth, rhythmic swing. In those cases, probably 15 out of 20 would go straight down the middle about 200-210 yards.
In the end, slowing down that swing in order to take consistency over raw performance improved my score dramatically. But damn it was cool when I absolutely crushed the ball that one time out of 20! :)
Coaching Point
In my experience, software teams are obsessed with going fast. Technology has certainly obliged, making it much easier than ever before to quickly throw together unmanageable piles of crap. Teams and even whole organizations are constantly trying to "grip it and rip it" to get that 350 yard drive that impresses the gallery. The problem is that they may actually pull this off... 1 time in 20. The other 19 times the teams are just trying desperately to get their ball back on the fairway, let alone on the green.
Golf analogies aside, you need to help teams understand that going fast isn't necessarily that good. Velocity is important, but remember that it's a vector consisting of both speed and direction. You may be going very fast, but completely the wrong way!
Teams will initially have difficulty with the concept of the Done State, i.e. getting their work (Stories, Minimal Marketable Features, etc.) completed to a point where it could be released upon an unsuspecting public. They will feel like they've slowed down, and in some ways they have. This perception of slowing down is quite disconcerting, and you need to ensure that the team, their management, stakeholders and possibly even customers know that they are slowing down in order to go fast. Pushing quality practices to the beginning of a development cycle and maintaining those practices throughout will allow the team to deliver more functionality at a much higher level of quality, and in turn move much faster in the long run.
Update - July 2011
I took my son golfing for the first time today. He spent a good portion of the 1st hole trying to hit the ball as hard as he could. On the 2nd tee, I talked him through relaxing and just taking a "smooth, rhythmic swing". He hit the ball 150-160 yards dead straight down the middle of the fairway.
I guess some advice is timeless.
Oh, and I hit a great drive about 240 yards down the middle, just like my Dad did 30-some years ago after giving me the same advice. :)
Dad gave me lots of pointers about various aspects of the game that I use to this day. By far the best was after I strutted up to the 1st tee one day, determined to show Dad just how bloody far I could hit that ball. Yes sir, that poor dimpled piece of plastic & rubber would rue the day it was made! I know what you're thinking... I swung and missed the ball completely. Well that's absolutely not true. The ball travelled at least 20 yards, and plopped into a creek.
Dad & I are a lot alike, temper included. Knowing this, he thankfully didn't laugh out loud. He did say, though, that I should try again, except this time just take a nice easy swing. I hit the ball about 175 yards (which was good at that age) right down the middle of the fairway.
Years later, when I would go to a driving range I would invariably take a couple of rips with the driver. They would either dribble ahead 20 yards or would hook or slice horribly. Perhaps 1 in 20 would go straight. I would then follow Dad's advice and just take a smooth, rhythmic swing. In those cases, probably 15 out of 20 would go straight down the middle about 200-210 yards.
In the end, slowing down that swing in order to take consistency over raw performance improved my score dramatically. But damn it was cool when I absolutely crushed the ball that one time out of 20! :)
Coaching Point
In my experience, software teams are obsessed with going fast. Technology has certainly obliged, making it much easier than ever before to quickly throw together unmanageable piles of crap. Teams and even whole organizations are constantly trying to "grip it and rip it" to get that 350 yard drive that impresses the gallery. The problem is that they may actually pull this off... 1 time in 20. The other 19 times the teams are just trying desperately to get their ball back on the fairway, let alone on the green.
Golf analogies aside, you need to help teams understand that going fast isn't necessarily that good. Velocity is important, but remember that it's a vector consisting of both speed and direction. You may be going very fast, but completely the wrong way!
Teams will initially have difficulty with the concept of the Done State, i.e. getting their work (Stories, Minimal Marketable Features, etc.) completed to a point where it could be released upon an unsuspecting public. They will feel like they've slowed down, and in some ways they have. This perception of slowing down is quite disconcerting, and you need to ensure that the team, their management, stakeholders and possibly even customers know that they are slowing down in order to go fast. Pushing quality practices to the beginning of a development cycle and maintaining those practices throughout will allow the team to deliver more functionality at a much higher level of quality, and in turn move much faster in the long run.
Update - July 2011
I took my son golfing for the first time today. He spent a good portion of the 1st hole trying to hit the ball as hard as he could. On the 2nd tee, I talked him through relaxing and just taking a "smooth, rhythmic swing". He hit the ball 150-160 yards dead straight down the middle of the fairway.
I guess some advice is timeless.
Oh, and I hit a great drive about 240 yards down the middle, just like my Dad did 30-some years ago after giving me the same advice. :)
Comments
On my tweet I was thinking of a case similar to a Business Analyst that can also code some small features. Rather than writing requirements and pass them to developers, this BA just went ahead and wrote the code. This was considered as a problem because didn't follow the process. And I was looking for a way to say that process is in place for BA that do not write code. For BA that do write code, maybe this team needs a new process in place. This BA is not the problem, the current process is the problem and is preventing the team moving forward faster because BA needs to stop and write requirements. That's all :)
Maybe is like saying that if you are leftie, you should swing differently from righties