El Kahuna

I keep losing my Hudson instance so I am making this my memory for what to do each time

• Proxy
  • export http_proxy=”<address of proxy from browser>”
• MySQL
  • Much of this for MySQL is stolen from Yet Another Blog. Thank you.
  • yum install mysql-server
  • /usr/bin/mysqladmin -u root password 'new-password'
  • /usr/bin/mysqladmin -u root -h <hostname> password 'new-password'
  • service mysqld start
  • mysql --user=root mysql
  • CREATE DATABASE <dbname>;
  • CREATE USER '<username>'@'%' IDENTIFIED BY 'some_pass';
  • GRANT ALL PRIVILEGES ON <dbname>.* to '<username>'@'%';
  • FLUSH PRIVILEGES;
  • SOURCE createdb.sql;
  • exit;
• Jetty
  • wget "http://dist.codehaus.org/jetty/jetty-6.1.22/jetty-6.1.22.zip"
  • unzip and put it on the attached volume
  • cd /usr/local
  • ln -s /mnt/installs/jetty-6.1.22 jetty
  • don't forget to create tools and static dirs and
  • don't forget to chmod all dirs allow hudson access
• Fitnesse
  • wget "http://www.fitnesse.org/fitnesse.jar?responder=releaseDownload&release=20100103"
  • rename the crap you get and put it where you want

  • cd /usr/local
  • ln -s /mnt/installs/fitnesse_20100103 fitnesse
  • don't forget to chmod all dirs allow hudson access
  • java -jar fitnesse
• Gradle
  • wget "http://dist.codehaus.org/gradle/gradle-0.8-all.zip"
  • unzip and put it on the attached volume
  • cd /usr/local
  • ln -s /mnt/installs/gradle-0.8 gradle
  • export GRADLE_HOME=/usr/local/gradle
  • Then go into Hudson and add the Gradle plug-in and define a gradle build task

After finding the 5 Whys of the previous post a colleague reminded me of “The 5 Questions”.  We used to work on a team that was responsible for rolling out and training people on the use of Agile Methodologies.  During that time I stumbled across a set of questions that I found useful when working with Agile teams.  These questions are directed at someone who is playing the role of Coach (in Extreme Programming (XP) parlance) or Scrum Master, but they are useful regardless of what methodology your team is using.

1. What task are you working on? - Part of any style of planning process is to create a list of things to do.  As a developer I should be concentrating on completing one of those tasks.  Unfortunately is is far too easy to follow a rabbit trail that leads you down a path that isn’t progressing the task you are supposed to be focused on.  This question allows the coach to determine if the person is maintaining the necessary focus.
2. Where is your pair? - As a proponent of Agile, I believe in Pair Programming.  It was something that we coached and stressed.  The purpose of this question is simply to find out if the person is off working on their own.  If they aren’t pairing, why?
3. Have you written a test yet? - Another important practice in Agile is the use of Unit Testing.  Whether your team has decided to try Test Driven Development (TDD) or not, a well structured umbrella of Unit Test is important to any software effort.  The purpose of this question is to reinforce the notion that any code written without covering tests (we can argue about spikes later) is not moving the task at hand forward.
4. Did you talk to the customer about this task? - Even if you “think” you know all about the problem being solved, it is a good practice to talk to the customer before you begin a piece of work.  Often time the customer has refined their understanding of the problem (which is a nice way of saying that people change their minds) between the time it was originally discussed and the time that the team begins working on a task.  By talking to the customer and reviewing the acceptance criteria, and maybe even prototyping with the customer, you make sure that your thinking is in line with the customers.  Who know, you might not even need to complete the task.
5. Can you describe your design? - Communication is quite possibly the most important values of any team.  If the team is communicating then the coach should be able to ask any member of the team to describe the design of the system being developed and get very similar pictures.  The purpose of this question if for the developer to be able to describe how the task at hand fits into the overall design of the system.  This is critical to keep the organic growth of any system in line with the overall objectives.

I love this.  The 5 Whys.  I’ve used this technique for years without knowing that it had a name or that it was associated with Toyota, Kanban, etc.  It just seemed like the right response to (usually) very talented people who come into work and say something like, “We should use ‘X’”  My rule was that if I could get to the 5th why without hearing, “I don’t know, I thought it would be cool”, then it was probably an idea worth investing in.

Use this technique with your teammates (or yourself) the next time someone has a great idea.

Can it survive the 5 Whys?

Of late I have been thinking of goal setting.  It’s such a simple and yet powerful idea.  Where do I want to go?  I think I want to go there.  How do I get there?  I think I’ll go that way.  Answering these simple questions provides a framework for tracking progress (when are we going to get “there”) and reacting to change (what do you mean they closed the pass?).  And yet I find in both personal and professional settings that “we” tend to go day to day without making use of this simple concept.

A road trip in the near future got me to thinking about analogy between a road trip and the setting of goals.  And how this analogy applies to life, work, and the software development process (which *is* work - at least for me).  On a road trip how do we know when we are “there”?  Well, likely as not we have a destination (the Grand Canyon, Rome, the mall) and we are “there” when we get there.  We have achieved our goal.  And likely as not we were checking our progress along the way.  Did we reach Albuquerque by noon?  Are we ahead of schedule?  Are we behind?  Are we lost?  And likely as not it allows us to react to change (want to see the world’s largest pistachio?  how about going to Las Vegas instead?).

In application of agile methodologies in the software development there is a similar pattern.  There are many destinations/goals (tasks, stories, sprints, releases, …) to use to guide my progress.  Using Test Driven Development (or Design if you prefer) (TDD) I write my test first.  I know that I am “there” when the test passes.  As I write more tests (and make them pass), I’ll begin to know if I am going to make Albuquerque (or in this case completion of my task/story) by noon.  As my tasks and stories progress I’ll begin to know if I am ahead of schedule or behind.  I will know how I am progressing relative to my goals.  Using this knowledge I am in a better position to react to changes / problems / issues.

I’m not talking about Gantt chart style travel (if its Tuesday it must be Belgium) style travel.  Nor Gantt chart task management (I’m 80% done on that task - what is it again).  That isn’t fluid decision making based on changes in your environment.  That is not reacting to change.  That is not open and honest communication.  Maybe that is why setting quarterly / annual objectives set via the HR process seem so disingenuous.

Set yourself guide posts.  Use them to guide (not dominate) your journey.

Leadership is a hard topic.  I often say that when I am interviewing people that I am looking for “IT”.  I can’t describe “IT”, I can’t tell you how to get “IT”, but I know “IT” when I see “IT”.  Leadership is something like that.  I know a leader when I see one.  I don’t see many.

Dilbert Style Leadership

So what is leadership for me.  Good question.  In a word, Motivation.

At a simple level a leader is someone who identifies a set of goals / objectives and has the ability to motivate a group of people to achieve those goals.  A leader has the ability to demonstrate to people how accomplishing the group’s goals allows them to achieve their goals.  A leader finds ways around roadblocks, celebrates success, and shoulder’s blame.  I believe the “best” leaders do so by example.

I’ve never been fond of Machiavelli style fear as a motivator.  Perhaps that is because I have had the pleasure to work with talented craftsmen.  It is my experience that such people are often immune to carrot / stick style motivation.  They respond instead to that feeling that one gets when accomplishing things.  Instead of fear of losing their job or not getting a raise / bonus, they are motivated by accomplishments.  Set them challenging goals and allow them to achieve those goals and you have a highly motivated group of people.

Too often people equate power with leadership.  As I have progressed(?) in my career I have found that far too often those in power lack any real ability to lead.  They tend to be so busy managing perhaps they forget to lead.  Perhaps they never had the ability to begin with.  Perhaps it is inevitable that we promote those who have to ability to manage instead of those who can lead.  It is my experience that those who can lead are often unaware of their own abilities.  They often don’t want the responsibilities and constraints that come with management.

Instead of a management track and a technical track, perhaps companies need a leadership track to identify, promote, and reward leaders.  Don’t conscript them to the repression of management.  Allow them to set goals.  Allow them to build teams.  Allow them to succeed.  And then get out of the way.

Wow.  Two years.  What a slacker.  Well during that time I can assure you that I have been paving a path to heaven (good intentions and all).

So, let’s try this again and see how long it lasts.

I hate learning things I already know.

And yet, I seemed doomed to repeat some lessons.  Communication.  Open and Honest communication as Kent Beck put it in his Extreme Programming Explained book is, in my mind, the cornerstone for any team to be successful.  It is a truth so obvious that we sometimes take it for granted or forget about it.  I try to lean towards over communication with my teams.  Though I’m not always successful, for I too get caught in the trap, I have found that this strategy leads to more team cohesion and improved performance.  People feel more free to communicate with me and each other.  Ideas flow more freely.  Expectations are challenged and reset more often.  Friction gets reduced.

I am coming off a … rotation where I allowed that principal to be compromised.  A situation where we were unable as a team to co-locate (which increases the need for communication) working with a remote groups (more communication) in different timezones (more communication).  A situation where we eventually discovered that communication was not a strength of the guiding umbrella organization.  As a result, friction increased, directions changed, and expectations were not reset when necessary.

Initially we tried to use our agile methodology roots to try to make a go of things.  Stand up meetings, retrospectives, acceptance meetings, trying to bring the wider team into these practices.  But at some point we realized as a team we were only talking to ourselves and not communicating with the wider group.  Even the communication within our team was suffering.   The distributed nature of the wider group lead to issues and problems that grew.  Issues that had we all been together would likely have been resolved with less effort, less force of will.  Eventually these issues lead to people leaving the team out of frustration.

This problem of communication was recognized and vocalized almost simultaneously by different parts of the organization.  A plan was put into place to replace our remote development team with a local team.  And while that plan took far too long to put into place.  And while it has lead to the disbanding of “my” team.  It was the right thing to do.

And yet.  Will it lead to a real change?  The guiding umbrella organization still has communication issues.  A localized team will hopefully lessen the impact of those issues, but it will not remove them.  It will not cause people to change existing behavior, in fact it may reinforce those behaviors (you must have known that, you were in the office that day weren’t you?).  People tend not to change unless there is pain.  While there is pain, I’m not sure that people see the root of their pain as poor communication.  They may choose to work harder (not smarter).

But ultimately this is about me.  How will this experience change me?  I have often been accused of being an a$$hole unwilling to compromise.  Did my desire to make this rotation work taint my views?  Did I choose to compromise on the wrong issues?  I think so.  A friend recently asked me for advice on leading a team.  I put Open and Honest Communication at the top of the list.

It is going back to the top of mine.

As a proponent of Agile development methods I am supposed to recognize that change is inevitable and to therefore embrace it. In the context of software development this idea is supposed to free the developer and the customer from a rigid, signed off requirements document and allow them to alter their plans as the system evolves.

Change is also inevitable organizationally. The old story about three envelopes appears to drive every “big stupid” company I’ve had the pleasure of working for. In many cases the only thing that changes is who your boss’s boss is. You still work at the same desk, you still work with the same people, you probably work on the same project.

Regardless of how change happens or when it happens, pain is change’s constant companion. Most likely something isn’t going right (or at least as well as it should) and someone in the organization decides that things must change to address the issue (pain). In my early days of trying to implement Agile Methodologies across the company we would often discuss that unless a group felt they had a problem, they would be resistant to change. That is, if they felt no pain, they had no motivation to change.

Now that was a long winded way to get to the point of this post. Somewhere in your organization someone feels pain and now here comes the change (envelope number 2). The question is…do you like your pain slow, or do you like it quick? Should the new process / organization be implemented as a rapid paradigm shift or as a series of small incremental steps?

I have lived through paradigm shifts and am currently experiencing a slow change. I am finding that I would just as soon have someone rip the band-aid (plaster?) off already. Because experiencing each incremental pain, knowing that there is more yet to come is killing me. Be done with it already. Let’s get to the next steady state quickly. Let people adjust (or not) to the new reality and move on.

What do you think?

Many people assume that my passion (or obsession) for wearing Aloha shirts on Friday stems from that popular geek cult film Office Space. “If you want to go ahead and wear a Hawian shirt and jeans”. But that isn’t the case. For me its about a memory. In February of 2000 we took a vacation (or holiday depending on where you are reading from) in Lanikai, Oahu, Hawaii. One of the most relaxing and beautiful places I’ve ever been to. White sand beaches, lovely little shops in nearby Kailua, snorkeling, sea kayaks…priceless.  As an aside, Lanikai is where Ann Margaret drops off Elvis in the film Blue Hawaii.

Anyway, after two glorious weeks we returned to the snow and the cold.  The following Friday I wore my new, straight from Hawaii (with wooden buttons), Aloha shirt.  It was my way of reminding myself that only a week before I was relaxing on a white sand beach with a good book and a cold beer.  And thus began an obsession.  Every Friday is Aloha shirt Friday.  Every Friday is a reminder that I work to live, not live to work.

This is my first attempt at creating a blog. I have been trying to encourage people who work in my area to write more. Writing is a habit, and like all habits it is best acquired earlier rather than later. (Best can be debatable in the context of say smoking, still if you start young it’s hard to stop). We give people financial rewards for publishing articles and giving public presentations as a mechanism of that encouragement. Most likely the reason that you have heard of <insert you favorite geek celebrity> is because they have bothered to take the time to write down what they think.

The other day one of the directors in our organization asked me why I wasn’t blogging. Well, I didn’t have a good answer (especially as he has a rather well known blog http://confusedofcalcutta.com/). I have always meant to start (just like I mean to loose this spare tire). So the cross roads of do as I say, not as I do and “pressure” from above have led to this foray.

Why El Kahuna? It is an amalgamation of nicknames that I have had recently (it sure beats Dirt Mole). I always liked Kahuna. We had a boat named the Big Kahuna when I was quite young, and I’ve always liked the thought of being an evil witch doctor. The other was L.K. () or elK. Plus, hey it was available.

Right so let the journey begin.