One thing that I’ve held on to for the past five years or so is a list of phrases that represent things that I believe. When I turned 30 I wrote out 30 things that I deeply believed in (inspired by Tom Peters and This I Believe! – Tom’s 60 TIBs).

I continue to add, remove, and remix this list constantly. Most of these items are things that I’ve read or heard in one place or another. Very few of these items are original, but they are all things that I value deeply.

So – what better way to customize a business card than by printing each business card with a different TIB on the back? I narrowed my list down to 100 and as soon as I come up with a general design that I like, then I’ll have them printed up.

Although they don’t exist yet, I thought I’d share the design since I’ve mentioned them to a few people here and there over the past week…

… and there are 86 others that I plan on printing.

This post refers to an upcoming session that I’ll be facilitating at the RallyOn Conference (on May 10th on the Frontiers track)…

Do you have a Business Model? Chances are that you do.

Can you describe it? Chances are that it’s a struggle to describe – at least succinctly.

Business Model Innovation has been one of the major proving grounds for both existing and growing companies over the past decade. The Wikipedia page on Business Model Innovation indicates that approximately 14 of the 19 entrants to the Fortune 500 between 1997 and 2007 owe their success to business model innovation.

While we frequently talk about different aspects of our Business Models, it’s rare that we ever have a common language that we can use to show the entire system that exists behind our companies and/or products. The Business Model Canvas is a simple way to visualize a business model and explore alternatives while seeing the systemic impacts that tweaks or pivots might have.

Why am I talking about this at RallyOn?

I think we have seen tremendous success with agile over the past decade and I’m confident that given the right environment that teams can succeed with agile principles and practices. My observations over the past few years have brought me to the conclusion that although we can prepare the environment for execution of strategy – it’s rare that strategy is taking advantage of the acceleration in delivery.

The Business Model Canvas is a tool that we can use to help see, accelerate, and pivot strategy in a thoughtful, visible, and intentional way.

I’m not sure it could have been said any better.

Thank you Holstee.

I was recently having a discussion around a set of “This I Believe” statements that I’ve thrown together over the years and the statement…

“Focusing on competition is a waste of time.”

… came up as a point of discussion. It’s certainly meant to be a provocative statement – but it also needs to be followed with some deeper reasoning to fully understand what is underneath it. This is absolutely something I deeply believe, so I thought I’d take a shot at explaining myself in this blog post.

To start with, it helps to understand that I think that most enterprise software sucks. It’s a strong statement – but in my experience it’s true. There are many reasons for this – and as a general statement I think it’s hard to refute. Sure, there are scenarios and there are subsets that might not suck – but on a product-basis it’s rare that I would even say that an enterprise software package deserves to be labeled as anything beyond mediocre.

Feature-matching competitors is common practice in the enterprise software market. My observation is that this mentality leads you to building another me-too product and to enter a downward spiral of commoditization. When this happens then the market naturally becomes crowded, pricing pressures mount, and manipulations are used to push product. I don’t necessarily think that this is wrong – I just think that it “is.”

The tactic of focusing on competition is fine if you are in a market that is being commoditized and if you are focusing on playing the political game and supporting the “I won’t get fired for choosing X”-buyer. Honestly, this is the enterprise software game and the reality is that most companies will do this in order to continue to support growth projections. Typically, prices go down and differentiation becomes non-existent. As the spiral continues then competing on price and manipulations is all that’s left. The product and market have simply progressed along the diffusion of innovation curve.

As an alternative, I’d much rather focus on user goals. I can stand behind adding features and functionality to allow users to accomplish tasks that lead to fulfilling their needs. I think this approach is much more likely to get you beyond mediocrity and existing as just another member of the herd.

Simply stated, my preference is to spend my time trying to build great software.

Building solutions for your customers doesn’t necessarily mean that you understand them. In fact – I’d say that it’s a rare exception that I talk to a software team that has any idea about who their users really are.

This is how the typical conversation seems to go…

Me: How many of you feel like you have a good understanding of your users?
Team: (85 – 90% of the hands go up)
Me: How many of you have ever visited one of your users?
Team: (uncomfortable silence)

Well – I have to say that I’m not really satisfied to believe that you can understand your users by reading a requirements document or by writing code to implement features that somebody told somebody that told you to implement the functionality. Even if you are an Agile team – just putting a “why” at the end of your user story doesn’t mean that it’s valid.

Because this situation seems to be so common (and because I’m really sick of using software that sucks) I decided to try and find some low-effort / high-value ways to start to address this situation. One of these techniques that I’ve been using lately is a concept called Empathy Mapping. This can be a really powerful exercise and I wanted to take a few minutes to share my experiences so far.

I’ve seen Empathy Mapping pop up in a few different places over the past year and I’ve seen multiple people credited for the creation of the technique can be attributed to Scott Matthews of XPLANE. The technique has been described in The d.school Bootcamp Bootleg, Gamestorming, and Business Model Generation. All of the techniques are mostly the same and they all have the same goal of helping you or your team empathize with your users.

The basic technique is simple:

1. Draw a head in the middle of your paper.
2. Give it a name (this could be a role, a persona, a stakeholder, or a real user)
3. Put your place in your user’s shoes and indicate what you see, what you hear, how you feel, and what you think.

As you fill in the sensory areas, it’s common to find yourself guessing or doubting the validity of your answers. If you do the exercise as a team – it’s common to have disagreements and to have different individuals have vastly different understandings (or leaps of faith) about who your users really are or what they see, hear, feel, and so on. It’s very easy to find significant gaps in your understanding of your users. The exercise of filling in the map brings visibility into the gaps and visibility into the unknowns.

The Empathy Map can be a powerful exercise as a pre-cursor to doing any user-centered work (like creating a business model canvas, creating a story map, or putting together campaigns). The resulting map can also result in a wonderful visual to have around a team room or to review as you learn more about your users.

I encourage you to try out this exercise and see where you end up.

I’m always amazed by the lack of understanding that most teams have about the users of their application or service. Rarely do I come in contact with people who are building software or managing a team that have a deep understanding of their users.

It’s easy to make assumptions about the people that are using your software. Do yourself and your users a favor – stop guessing and start learning. Life is too short to be writing shitty software and building mediocre experiences.

Get yourself and your team out of the building and go visit a user. After you do that, do it again (and again, and again, and again).

You’ll be surprised at what you see.

Beautiful boarding pass redesigns. Be sure to view the comments as well.

Here are a few teasers from the article…

When you look deeper, it’s another example of extreme subtraction…

No cords. No buttons.

By loosing the excess, the mouse gains functionality and capability. All of the sudden, lots of new worlds and possibilities open up. We have the capability for multi-touch and a (mostly) unrestricted canvas for rich interaction because of the items that have been removed from the mouse.

Sound familiar?

This is the same design that opened up a new world of phones by removing the physical keyboard.

Thank you Apple

I’ve been spending a lot of time over the past few years thinking a lot about simplicity. Simplicity is one of those things that we mention a lot in passing, but it’s also something that we don’t dedicate much effort to achieving.

We develop software where 60+% of the functionality is never or rarely used. We focus on feature-matching the competition while we neglect listening to our users. We litter our presentations with excessive bullet points instead of focusing on our core message. We write user manuals that rival Atlas Shrugged because we’ve failed at providing usable interactions.

By nature, we tend to add when we should subtract. Evolution has plagued us with reactions that promote complexity and avoid clarity. When we create, we focus on building more – but when we consume, we tend to find the most joy out of having less.

How do we make a conscious effort to find simplicity in a world of complexity? Well, to start, we can start to think about thoughtful reduction.

Thoughtful reduction is an extremely powerful tool in our quest for simplicity.

The next time you are faced with an opportunity to improve or modify your process, or your software, or your life – think about what you can remove instead of what you can add. Take a little extra time to remove root causes instead of adding workarounds. Think about how to communicate more clearly instead of how to communicate more. Think about the things that you can stop doing instead of the things that you can start doing.

When we remove the non-essential then we end up with a stronger focus on the truly essential. Find the core of your application, your message, your purpose – and take away the rest. You might not end up winning the feature-race, but you could find a beautiful product and a renewed sense of focus.

You can also find the video on Vimeo.

The talk includes some discussion of testing, but it is mostly centered around figuring out how to deliver great software.

If you’re in the area, stop by and say hi.

I’ll post the presentation here after the talk.

The presentation is embedded below. If you download the presentation, it will have a summary of what was discussed in the presenter notes.

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.

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.

Don’t ask your users what to build. Instead, focus on understanding what your users “do.” Know the goals of your users, understand what they think, how they interact, what they do in their time-off, and understand what their life is like on a day-to-day basis. You can’t get this information by disconnected feedback, you have to get it face-to-face, side-by-side, through direct and unbiased observation.

Everyone who designs, develops, tests, and manages software products should be spending time with their users. Be an apprentice, observe your software in use in a natural environment, pay attention to the psychology and interactions – then you will understand what needs to be built.

Every interaction with a user in their natural environment will leave a lasting impact in how you understand your users and guide your product.

If you are having a hard time putting together compelling presentations then a great source of inspiration is to look to Wall Wood’s 22 Panels.

The 22 panels are great inspirations for help in designing your slides to tell the visual story of your content or ideas.

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.

Nature is often neglected as a source of inspiration. There are many opportunities to look to nature to find solutions to our problems and inspiration for our thoughts.

Our minds and our thoughts are often shaped and blinded by growing up as children of industry. There was a world that existed before industrialization and there will likely be a world that exists after our impact is felt on this planet.

The next time that you look to any of the standard clichés that tend to rule our thinking – try looking to nature and see what you can come up with. My guess is that you will be surprised in what you find.

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.

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.

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.