Modeling vs. The Model

It’s interesting to me how much people rely on formal tools for modeling. I frequently talk to individuals that tend to assert that just because a model is made in some modeling tool (like Visio) that it is *right* or at least superior to whiteboard sketches.

The Visio fan-boys and fan-girls seem to snicker and generally doubt the effectiveness of a sketch done at a whiteboard. Why is this?

Is it because of the appearance? Is it the lack of gradients? Is it the lack of the drop shadows? Is it the lack of the standard company logo in the upper right-hand corner? Is it because of how straight the lines are?

My view is exactly the opposite. If I had to summarize my stance, I’d say that the straightness of the lines has an inverse effect on the understanding of the problem.

In my experience, most of the models created with modeling-tools are done by one individual. If others collaborate on the model, it’s usually in a serialized fashion. It’s “tossed over the wall” to someone else who follows a similar process. It’s also my experience that many people spend more time worrying about the polish of how the output looks than spending time thinking about what is being modeled.

Contrast this to a whiteboard-session:

When a model is explored on a whiteboard it’s usually done with more than one person. It’s usually done collaboratively with at least two participants, a variety of view-points, and it’s iterated on quickly. Because it’s being done collaboratively, it also frequently results in break-through ideas or understanding.

Unfortunately, the modeling tools also tend to focus our attention on the output, not the creation of the model (where the real learning occurs).

It’s important to remember that the modeling, learning, and understanding is what provides the real value, not the model.

Photo courtesy of Doc Searls.

User Stories For User Experience

I’ve always found it interesting how a simple change in semantics can make a huge difference for a team. One area that I’ve been thinking about for a while is the structure of user stories.

In it’s basic structure, a user story follows the format of:

Most teams (at least in my experience), use the format:

An interesting assumption of this format is that we know what the feature that we will be implementing should be.

In many cases, this format neglects the tasks of taking some time and dedicating some effort to think about a suitable implementation. In some cases this might be ok (commoditized software, maintenance modifications, a thorough understanding of the solution space, et cetera). But, in cases where we are innovating or focusing on providing a differentiated user experience, this assumption can lead to a me-too product or mediocre software.

In the event that we need to think a bit about the solution, I’ve found it very useful to change the story format to be goal-oriented. My recommendation is to use a slightly different format:

This is a minor modification, but it certainly changes the focus.

The goal-oriented story format encourages empathy, understanding, and exploration. When we are in a situation where we are focused on delivering an optimal experience to our users, I think that the latter format is appropriate.

TIB #22: Use An Exchange Program

If you are working with a distributed team, especially if that team is offshore, you should implement an “exchange program” to bring remote people together. The phone, email, instant messenger, and other similar tools can help with collaboration but they don’t have a fraction of the power of face-to-face communication.

Do you work with people in India? Then go to India. Do you work with people in the China? Then go to China.

Making eye contact in a high-bandwidth environment can do wonders for teamwork and cohesion. In addition to the face-to-face time there is also the understanding and feeling of culture. Culture provides the basis for viewpoints and actions and without understanding the culture of your co-workers, how can you ever understand them as individuals?

As you make your budget for your project, always remember that your best tool for collaboration is a plane ticket.

The Dreyfus Model of Skill Acquisition

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.

Effectiveness vs. Efficiency

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.

Announcing: Big Visible Cruise

Over the past couple of days, I’ve been pulling together a simple Information Radiator for CruiseControl.net. The idea behind the project is to use the power of visualizations to provide simple, visible, and informative displays that expose the current-state of your automated continuous integration builds.

I threw this app together very quickly a week or so ago and I’ve been amazed at how addictive it’s become. In our team room, we have a dedicated monitor that is always running the application. The result is that you know exactly where the builds stand as soon as you enter the room.

I initially wanted to put this together as a temporary solution to picking out what items we will use to show our build status. We always bounce back and forth about Nabaztag, orbs, lava lamps, and other physical things to show our build status. It’s usually easier to find an extra monitor than it is to get a purchase request approved for a wireless-enabled rabbit. Big Visible Cruise is the same idea, it’s just a visualization instead of a physical device. Judging by how much we all enjoy seeing it, it will probably stick around in addition to any physical device we pick up.

You can find out more about the project at http://code.google.com/p/bigvisiblecruise/. After the holiday I’ll post some pictures and explain how we are utilizing the big display in our team room.

In the meantime, you can likely get an idea from looking at the display while it’s monitoring three different projects in the following screen shot…

This shows that I have three projects (Foo, Bar, and Some Project) being run on my CCNet server. In this example Foo and Bar are successful and Some Project is broken.

The other state that isn’t represented in the pic above is the “building” state. When a project is building, the row representing the project will turn yellow.

By default, BVC will poll every 15 seconds. I recommend using BVC with CCTray so that you have a big visual display along with auditory clues about your build process.

Big Visible Cruise is being released under the MIT license.

If you’re interested in WPF and/or information visualization, I’d love any contributions

I plan on providing some interesting visualizations over the next couple of months. Let me know what you’d like to see on the RoadMap page.

Remote Pairing

I’ve been spending roughly 4 – 8 hours a day doing remote pair-programming lately. Although there are always connectivity issues (usually once or twice per day), it’s still only a minor nuisance. Overall, I’m really enjoying the experience and it’s starting to feel pretty close to side-by-side pairing.

The tools that I use on a daily basis include Microsoft SharedView for screen sharing and Skype for voice and video. The combination of these two tools seems to work very well (even over wireless).

SharedView is still in beta, but it is a very nice, minimal, and responsive tool. With the exception of the ads (integrated into the tool), I’m impressed. I’ve used many other tools in the past but this one just seems to fit the way I work better. The features like the ability to see other mouse pointers, clicking, and highlighting is a very nice feature.

Right now, the only thing that consistently bugs me is the quality of my headset (junk). I’m hoping to pick up a new one in the next couple of days.

Learning From Journalism – The Inverted Pyramid

In developing and envisioning software, it’s easy to forget about prioritizing value. Even with agile development teams, it’s common to see “sets” of functionality prioritized instead of rank-ordered. One idea that I’ve been pushing hard on lately is to not let anything into the backlog that’s not prioritized (as in rank-ordered).

Why? Well, one place we can pull ideas from is the inverted pyramid approach to journalism. The inverted pyramid approach is a common metaphor in journalism to avoid “burying the lead.” The “lead” of an article is the beginning of the article that conveys the core information of the story.
Journalism (and the publishing models of newspapers and periodicals) is a great place to look for ideas and inspiration for agile approaches. When a newspaper has to be distributed, it has to go. A newspaper isn’t held up for individual journalists to finish their articles. Sound familiar? This is exactly the same as doing time-boxed activities in agile approaches.

The essence behind the inverted pyramid (from Wikipedia):

The triangle’s broad base at the top of the figure represents the most substantial, interesting, and important information the writer means to convey. The triangle’s orientation is meant to illustrate that this kind of material should head the article, while the tapered lower portion illustrates that other material should follow in order of diminishing importance.

This makes perfect sense for a couple of different reasons (all of which have their own parallels in agile development):

1. If everything doesn’t match up perfectly in the layout or limited real estate of the paper, the end of the story can be cut out without sacrificing the important essence of the story. This also allows for the staff to quickly make room for late-breaking news or for additional advertising.
2. The reader of the story doesn’t need to read the entire article to understand the core elements of the story. In fact, they can usually get almost all of the information by just reading the first few sentences.

In addition to using this as a guiding principal for the prioritizing of the backlog (see reason #1 above), we can also apply this technique to our own writing for any documentation that we need to create (see reason #2).

I first ran across this concept while reading Made to Stick. One of the quotes from the book is by Dan Wycliff (an award winning editorial writer) who says:

“I’ve always been a believer that if I’ve got two hours in which to write a story, the best investment I can make is to spend the first hour and forty-five minutes of it getting a good lead, because after that everything will come easily.”

Practicing this approach can help us steer towards generating revenue faster (through prioritized features) as well as clear writing (by focusing on the important information).

The Power Of Silence

An interesting facilitation technique that I’ve learned to frequently rely on is silence. The first time I ran across the technique was in a CSM course taught by Hubert Smits and Tamara Sulaiman. One of the exercises that we explored was Silent Grouping. The exercise was great and worked very well in the context of the training session.

When I returned to work I started trying various techniques with silence and most of them went very well. The majority of our facilitated sessions were very large and it was usually a constant challenge to move off of side conversations and keep the group focused. One of the techniques that frequently returned good results was using time-boxed silence alongside various other techniques that are used often in agile meetings (brainstorming, prioritizing, sorting, grouping, etc.).

There just seems to be something about the ability to become rational, absorbed, and focused on the task when the “no talking” rule is in effect. It frequently seemed easier to drive towards consensus when the group used silence as a method for creating, grouping, and processing information.

Be Careful With Your Numbers

A couple of years ago I put together some collateral to use when “selling” agile to potential clients. As part of the effort to educate our sales team about agile methods I wanted to provide some strong evidence for our sales team to use.

The only numbers that I had seen at this point were the numbers cited in Agile and Iterative Development: A Manager’s Guide by Craig Larman. To say the least, the numbers were very impressive: Of those polled, 93% saw increases in productivity, 88% increases in quality, 83% improved stakeholder satisfaction, 49% reduced costs, and so on. I dropped these numbers in the collateral and I made every one of the sales members happy.

A few months later I was looking for some deeper numbers and I started to dig deeper for more quantitative data. The first place that I went to look for numbers was the study used that came up with the above numbers (by Shine Technologies in 2003).

When I started digging deeper, I realized that this survey has huge room for error. I’m not an expert on surveys or quantitative methods, but what I read didn’t leave me feeling convinced that it was worth publishing and standing behind the results.

After digging a little deeper, I noticed that these numbers (that I had been advocating) were based on a web-based survey that had only been taken by 131 people. Yes, 131 people and web-based. Ouch.

You can find the survey here.

Now, I don’t want to completely discount the survey and/or the results. This is important information; but I’m just not comfortable presenting these findings as “evidence” that agile works. I’m just not comfortable putting them up on my company website and I’m not comfortable putting them in my presentations. I believe in agile methods, I just don’t believe that this study “proves” that they are a valid alternative.

An interesting thing that I have noticed is that many individuals and many companies have used this survey as justification for agile initiatives. Last week (at Agile 2007) I saw these numbers presented multiple times in slide decks and I’ve seen them on plenty of web sites of vendors that are offering agile services.

Anyway, I just thought that this was an interesting bit to share about how you should always know more about the survey results and numbers that you use to backup any claims. Make sure you can stand behind your numbers and that you find out the information behind the numbers.