Speaking At Agile Carolinas

I’m going to be speaking at Agile Carolinas on May 21st (this Thursday). My topic will be: Adopting a Whole-team Approach To Quality

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.

Posted in community | Leave a comment

Modeling vs. The Model

Whiteboard Session

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.

Posted in agile, architecture, design, learning | 3 Comments

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:
As who, I want what, so that why.
Most teams (at least in my experience), use the format:
As a role, I want feature, so that benefit.
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:
As persona, I want to goal, so that value.
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.

Posted in agile | 1 Comment

Your Users Don’t Know Best

You don’t build great software by putting your users in the driver’s seat. Techniques that focus on asking users what they want in your product or asking users to “vote” on the functionality that they would like to see in your product are recipes for mediocrity.

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.

Posted in design | Leave a comment

Wally Wood’s 22 Panels

wallywoods22panels

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.

Posted in design, presentations | Leave a comment

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.

Posted in agile, teams, tib | Leave a comment

Tivoli Model Three

Is there another alarm clock radio that’s more beautiful than this?

I stayed at a hotel recently that had one of these at the bedside. In a world full of horrible hotel alarm clocks, it was a welcome change.

Usability++

Posted in design, usability | 1 Comment

TIB #16: Listen To Nature

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.

Posted in tib | Leave a comment

The Link Between Creativity and Play

Another great TED presentation by Tim Brown

Video here.

Posted in design, innovation | Leave a comment

Picturing Excess

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.

Posted in art, design, visualizations | Leave a comment