The Sherpa Project

Another great TED presentation by Tim Brown…

Video here.

If you haven’t seen the work of Chris Jordan, I highly recommend taking a little while to explore his work. Lightly put, it’s amazing.

Chris combines statistics and visualizations to produce a variety of thought-provoking, insightful, and beautiful visuals.

His most recent work can be seen in Running the Numbers - An American Self-Portrait.

I’d also recommend taking a few minutes to watch his talk from TED.

As part of my job, I travel around to lots of new companies helping get teams started with Agile methods. It’s something that I’ve done for a long time in a lot of different companies. I’ve coached a lot of Agile teams and I’ve worked as a delivery team member on a lot of teams as well.

Something that I’ve noticed more and more lately is an increasing demand for “rules” in applying Agile development. Honestly, this has concerned me for the past couple of years. I always silently gritted my teeth and provided guidance backed up by a lot of “unless” clauses. I’ve usually taught from a “principles-based” approach and encouraged creativity around the principles.

Although I think that I’ve done a solid job in communicating the benefits and application of Agile methods and practices, I also feel like in many ways that I’ve left teams begging for prescriptions, rules, and best-practices. In my mind - those things have always been more problematic than helpful.

On the plane today, I started reading Pragmatic Thinking and Learning by Andy Hunt. By the second chapter, I had that OS!M (oh shit! moment) where a lot of things start to pull together in my mind. This all happened while reading through Andy’s explanation of the Dreyfus Learning Model. Suddenly, a lot of things started to make sense to me from a coaching standpoint.

The Dreyfus Model is a five-stage model that shows how individuals make the progression from Novice to Expert. The Dreyfus Model explains skill acquisition and the related ramifications of how we learn at different stages. This model was originally developed by a couple of brothers that were researching how we learn for some work they were doing around artificial intelligence.

An interesting insight from the Dreyfus Model is that at the Novice stage (the first stage), individuals need recipes. Novices are concerned about their ability to succeed and they don’t have any experience to draw from. Novices aren’t necessarily interested in learning, they simply want to accomplish an immediate goal. They are most effective when they are given the exact instruction of how to proceed. Take out context, take out the edge cases, take out the “it depends” scenarios and that’s what individuals that are new to a concept really care about.

When we move through the stages then context, the edge cases, and the “it depends” scenarios really start to matter and understanding the big picture plays a more relevant role in our learning. This explains a lot of what I have been trying to understand with the desire to have a “one size fits all” or “best-practices” approach to applying agility. In looking back at my own progression, I can see the exact characteristics that are defined in this model.

When I “prescribe” a practice or I provide exact steps for achieving an outcome then I feel like I’ve somehow cheated. This is because I know that there are not any universal truths in how we approach problems with software delivery and with agility. Maybe this feeling that I get should be re-evaluated. Maybe it’s ok to be prescriptive. Maybe it’s ok to provide recipes to new teams. At the very least, this is a great opportunity to re-think my assumptions and my world-view on how to be a great Agile Coach and to spend some time learning more about learning.

I’m looking forward to finishing the book and thinking through the information that Andy has provided in the book so far (I’m only through the first two chapters). It looks like it’s going to be another great release from the Pragmatic Bookshelf.

A beautiful presentation by the wonderful Tara Hunt…

I often hear people use the words effective and efficient interchangeably. While the two definitions are close, they are not exactly the same and they have different contexts where each is appropriate.

Here are the two definitions from the New Oxford American Dictionary…

The way I usually differentiate between these two terms and their accompanying mindsets can be partially described by thinking about taking a road-trip.

If I am trying to determine the best route to take to get from point A to point B then I have a variety of ways that I can reach my destination. When I choose which route to take - then I am thinking about effectiveness.

If I drive a specific route frequently then I can focus on efficiently navigating that specific route. If the road is paved then I probably want to drive my car (better gas mileage), if it’s a dirt road then I might need drive my SUV. When I apply the context of my route - then I am thinking about efficiency.

The differences in these definitions is slight, but important. When I focus on effectiveness then I’m looking at ways I can achieve a specific goal. When I’m looking at efficiency then I’m looking at optimizing the way I’ve chosen to achieve the goal.

If you think about the subtle differences between these two mindsets then it’s fairly obvious that software development almost always focuses on efficiency. Unfortunately, there are many times that we focus on optimizing our gas mileage while we are taking the wrong route to get to our destination.

When you need to focusing on doing the right thing then focus on effectiveness. When you need to focus on optimizing the right thing then focus on efficiency.

If you’re in a situation where things change frequently then effectiveness should be your focus. After you solve the effectiveness problems then you can focus on efficiency.

Jim tagged me for the meme, so here’s how I got started…

How old were you when you started programming?
I wrote a few games (when you had to type in the games) on the TRS-80 when I was in elementary school. I think I wrote two or three of those games as a kid. I really didn’t start programming though until I was in college. I think I was 20 when I took my first programming class.

How did you get started in programming?
I took an internship to be a network engineer. I was lucky and got the internship, but there weren’t any projects for me to do. One day, the company I was working for asked me if I’d like to go hang out with the developers and see if I could help out. Fortunately, the developers were great mentors and they taught me how to write code. When a real networking position came up I declined it and kept hanging out with those same developers.

What was your first language?
Those TRS-80 games I wrote were in basic. The code I wrote in college was mostly VB.

What was the first real program you wrote?
I wrote an application for a law firm to track their hours for billing clients. Apparently, they had a hard time finding a time-tracking and billing application that would let each of the lawyers bill over 24 hours a day.

What was your first professional programming gig?
Doing (the hell that was) Windows DNA for a consulting firm while I was still in college.

If you know what you know now, would you have started programming?
Absolutely.

If there is one thing you learned along the way that you would tell new developers, what would it be?
Focus on the quality of the people that you work with and use it as a guide to find the right job. Your best bet for progressing in the field is to work with people that are better than you and have the ability and the desire to mentor others.

What’s the most fun you’ve ever had … programming?
My first agile project. XP by the book. I was very close to burning out and it re-ignited my passion for writing code and building valuable software. There were a ton of new things to learn and many things to re-think.

I just recently updated BVC for a few requested features (options dialog, live skin switching, configurable polling, keyboard shortcuts, et cetera). None of these are big changes, but they do make the tool a little easier to interact with (no more modification of xml files).

I have a handful of things that I would like to change (mostly related to usability) and some code that I want to clean up before I put out a version 1.0 drop and I’ll probably get around to this sooner than later.

The one additional thing that I’d like to see are some requests for different types of visualizations that can be built into the tool. The current visualizations (there’s only two) are very simple and they seem to work very well. While these two visualizations are nice and simple, I’d like to put a few extra skins in place before doing the 1.0 drop.

If you’ve got any ideas or have any inspiration for what can/should be done, please head over to the GetSatisfaction site and put your ideas on the thread that was just started.

Currently, the two views are LiveStackedStatus and LiveUniformStatus (these will be given friendly names before the release). Here are the two views…

LiveUniformStatus

LiveStackedStatus

Both of these views are only relevant if you have multiple projects being hosted by your cruise instance. If you only have a single instance hosted, then you’ll only see one large box with your project status. The best view typically depends on the number of projects that you have available. If you have more than four projects hosted then LiveUniformStatus tends to give you the best view and four or fewer projects tends to look best with the LiveStackedStatus.

If you have non-visualization requests, you can also feel free to post them and I’ll take them into consideration as well.

If you’re anywhere near Raleigh on May 6th, be sure to check out the Agile RTP meeting. We’ve got Andy Hunt coming to talk and I’m sure it’s going to be worth your time to attend. The title of the talk is Refactoring Your Wetware.

If I could point to two or three people that have shaped my thoughts about programming and development, Andy would be at the top of that list.

If I could only recommend one book to anyone doing development, it would be The Pragmatic Programmer. The book certainly changed the way that I think and has certainly shaped my career. Interestingly, it’s the only (at least partially) technical book that made my list of books that changed my life.

If you’re in the area (or if you feel like taking a road trip), be sure to come by and see Andy talk and participate in the discussion at Agile RTP.

I’ve turned into a Twitter junkie. There’s just something about it that makes me smile.

If you don’t get it (I didn’t at first either), check out this great video that I just ran across from Common Craft … on Vimeo…

Twitter in Plain English from leelefever on Vimeo.

I’ve been very quiet on my blog for a while now, but I wanted to get everybody up to date on a few things…

#1) First and foremost, I’m a dad

Whitney and I had our first child (Haley Kay Carey) on January 30th. Everyone is doing wonderful and I’m loving being a dad. Right now, this is where the majority of my focus has been channeled. Haley is doing awesome, Whitney is doing awesome, and I’m doing awesome.

You can find our pictures of Haley on Flickr at: http://flickr.com/photos/thecareyfam/tags/haley/

#2) If you’re interested in what I’m doing (until I get back to blogging more), I’m using Twitter frequently. It’s much easier to do the micro-blog thing with Twitter.

You can find my Twitter profile at: http://twitter.com//bencarey

#3) I created a small web page to hold the links to my small projects and experiments. There’s not much on the site right now, but there will be as time moves on. I have a lot of little experiments that I’d like to try and this will probably be where I link them up (I’m sure I’ll blog about them as well).

The new site is: http://www.hellokensho.com

#4) I launched Omakase. This was a little idea to experiment with Rails, iPhone development, and some ideas for exploring ways to make micro-applications. Omakase does one thing… it makes decisions for you. I’ll post more about it after I finish cleaning it up a bit. The site was written for the iPhone, but it does have a traditional browser version as well. Currently, the browser site looks the best in Safari.

You can find Omakase at: http://www.iloveomakase.com

#5) I moved my blog and site host over to Media Temple. As part of that move, I wiped out all of the categories for my old blog entries. I did this on purpose. I do blog about a mixture of items (technology, business, development, life, travel, etc.) and I decided that all of the categories just weren’t worth the effort to maintain them.

I’ll get back to blogging, speaking, and the various communities before too much longer. For now, I’m enjoying a bit of a break and soaking up the new addition to the family.