Agility through discipline

I've read some things lately about Agile software development or project management lacking discipline. In my experience, Agile methods require MORE discipline than traditional methods when properly practiced.

For example, consider software project planning and estimating . On a traditional project, I often saw a detailed project plan that listed specific tasks, dates, assigned resources, and so on. The strange part is that this plan was rarely modified to reflect the learning we did later on in the project. Instead, the entire project often became a continous scolding opportunity for the project manager. "We need to get back on schedule. Where are we on Task XYZ that was slated to be completed by Friday?" and so on.

By constrast, the Agile projects I've been involved with did some planning up front, but at the level of business value, not of development tasks. We worked with project stakeholders to determine what items to do first, and were able to put a schedule in place based on consistent, reliable delivery of working software. When new requirements emerged, or we faced unforeseen technical challenges, we were able to update the plan based on that information. This kept everyone able to adapt and communicate about where we REALLY were.

It takes more discipline to face reality consistently than to avoid having difficult conversations, and following a rigid, hopelessly inaccurate plan. Fear is more commonly associated with traditional project management than courage.

I propose a new definition for Agile: creating freedom through courage and discipline. What's your definition?


For more on agile tools and techniques: http://www.extremeplanner.com
(Tags: agile, software, project management)

Get your copy of the new book! Agile Thinking: Leading Successful Software Project and Teams

Why Worse Might Just Be Better

For years, I was puzzled by the strange reaction of customers to nice-looking software prototypes. It went something like "This is great! Looks like you're pretty far along. Can I have this by the important conference/board meeting/presentation next month?"

Why would they do this? I clearly stated that I was showing a prototype. Something I put together to demonstrate a concept, not a production-ready, working system. Which syllable of pro-to-type didn't they understand?

And then, after several more painful episodes, it hit me. My prototypes looked good. They looked like something you would want to use at a sales meeting or conference to impress someone. You'd have to be impaired not to want to use it as evidence of progress, innovation, or in a word, sizzle. I've started calling this the "sizzle syndrome."

Whoops.

For my next prototype, I went more low-tech using paper sketches, and some in-person whiteboarding to demonstrate the concepts. This worked almost as well for feedback, without the "sizzle syndrome." I recommend this approach when you have an engaged customer at your location.

When dealing with either extremely busy or remotely located customers (like the ones more than 20 feet down the hall), sometimes you still need a more interactive prototype that they can play with without your involvement. HTML prototypes can serve this purpose, but I try not to get bogged down in look and feel details. Keeping things clean and simple helps me get feedback on the areas I'm interested in, while minimizing the noise that colors, fonts and shapes can generate ("Are you really to make that yellow? I hate yellow.")

Interestingly, with actual software, the effect I've seen is often the opposite. A perfectly functioning, but unremarkable-looking piece of software often elicits opinions on the color scheme, layout, use of certain types of widgets and more. A beautifully designed look and feel can generate great praise and excitement, even if the underlying functionality is mediocre or even suffers from usability problems.

So is worse really better? For early conceptual prototypes it can be, as long as you're getting the kind of feedback you want. Warning signs of too good a look are that you get lots of non-specific glowing praise ("This looks great!"). If you skew too far in the other direction, you'll know by the very pointed feedback ("I don't think this is ready for prime time", or "Perhaps we should bring in a graphic artist").

The point of prototyping is to get rapid feedback about the user interaction and how well it solves the problem at hand. The more you can eliminate obstacles to getting that feedback by removing user interface distractions (either positive or negative), the more meaningful your feedback will be.

Sometimes that means making something look worse, so that the final product will be better.


For more on agile tools and techniques: http://www.extremeplanner.com
(Tags: agile, design, prototyping)

Get your copy of the new book! Agile Thinking: Leading Successful Software Project and Teams

Designing software with your phone?

I just ran across an interesting new web service called Scanr (how very Web 2.0). It let's you take digital photos of documents or whiteboards from your cell phone camera, send them to an email address, and it will mail you back a cleaned-up version as a PDF or JPEG.

One of the things they've figured out is how to take bad whiteboard photos and make them look sharp and clear. This could really come in handy when designing user interfaces on your whiteboard. I can't wait to try this with EasyPrototype!

Not quite sure what the business model is on this one, but for now it appears to be a free service.


For more on agile tools and techniques: http://www.extremeplanner.com
(Tags: design, Web 2.0, prototyping)

Get your copy of the new book! Agile Thinking: Leading Successful Software Project and Teams