I also noticed several things that I’ll call “pattern vs. antipattern” tugs of war. Quite often during the meeting I felt the group trying to move our discussion in one direction that I, for better or for worse, thought was ineffective. I would then redirect us on to what I felt was a better path. In true catalog form, here’s the list:

• Understand the Problem vs. Jump to the Solution – only a couple of minutes into our discussion solutions were being flung about like drunken darts. This situation almost always leads to suboptimal or faulty solutions. As a facilitator, try to ensure that the problem has been clearly stated. If at all possible, write it down on a whiteboard. Make sure everyone agrees that the problem as stated is the problem the group is there to solve. Sure enough, after performing this exercise, we all had a very different and clear understanding of the problem than that with which we walked in the door.
• Assume the Worst vs. Assume the Best – occasionally the exact details of a requirement are unclear, and not assuming something will totally derail the design discussion. You have a couple of choices. The first is to halt the discussion and get the details cleared up. This is clearly the best solution, as you’ll no longer have to assume anything. However, it can be the case that the person who can clear things up isn’t available. Or in some cases, the question you’ll be asking will require another meeting at another level of the organization. If you find yourself in that spot, and you can’t wait (we couldn’t!), then the best approach is to work from the worst possible case scenario. You’ll then be in the best position to handle whatever answer comes your way. However, our tendency is often to assume the best (“That will *never* happen!”). Fight that tendency. However, whatever you choose, follow up at your earliest opportunity.
• Basing Decisions on the Current Situation vs. Basing Decisions on History – many times the group wanted to veer off into safer territory. In some cases, a possible solution departed significantly from the current design. While this is a valid concern (we do want consistency of design across the system where possible), it is certainly not a trump card. Occasionally the situation at hand will merit a significant departure from the current design. Another way history can rear its ugly head is the assertion that we’ve always solved similar problems like ‘x,’ so we should do so with this problem as well. Again, note the word “similar.” All problems are somewhat different and have their own eccentricities. So, rather than working from history, I pushed us back to a clean slate with the statement “Let’s stop thinking about the past and start from scratch. We may very well come up with the same solution you guys are proposing, but I’d rather do so through our own objective analysis and not instinct.” Guess what. We came up with a different solution that we all felt better about.
• Shooting for the “Best” Solution vs. the “Easiest” Solution – now sometimes we can’t afford the best solution. I grant that. However, I’m trying to fight the tendency to immediately jump to the “easiest thing that could possibly work.” Often this pops up in the first P vs. AP – if we don’t clearly understand the problem, sometimes an easy solution jumps out that doesn’t deal with the underlying details we’ve yet to uncover. Also, sometimes the best solution is quite simple and elegant. It doesn’t necessarily have to be harder and more complex than the easiest solution. In fact, sometimes the “easiest” solution leads to the most accidental complexity in the long-run. So, shoot for the best solution you can come up with and only then, optimize for cost.
• Present Possible Solutions Objectively vs. My Solution is the Best! – one would hope that we all start here, but we don’t. We tend to like our own solutions to problems and want them to “win.” Our ego can get in the way of even hearing an alternate solution presented by another team member. I point you to my colleague Ted Neward’s post for more on “egoless programming.” So, as a facilitator, you’ve got to make sure that all solutions are presented objectively. I often had to say things like “OK, let’s assume before we ever get started that this is a good solution to the problem and not hack away at it until its fully presented, and we all understand it.” In the end, this insistence led us to choose a solution that none of us (myself included) originally thought we’d pick.
• Validating from Code vs. Validating from Memory – more often than not, questions about the existing design/code/behavior will come up. Rather than scratching your head and trying to remember what you wrote six months ago, pull up the code and find out. I can’t tell you the number of meetings I’ve attended where baseless assertions were made about existing code, only to require another meeting the next day to revisit the whole discussion once those assertions were proven wrong. Again, as a facilitator, I directed us to solve every problem for which all of the facts were available. We inserted placeholders in our solution where questions remained. Guess what we’re doing now? Well, I’m blogging about the meeting, but the rest of us are validating from code. Tomorrow will fill in the blanks!

Join members of the growing Selenium community for 3 jam-packed days of talks, workshops, lightning talks, and hack sessions. Hear speakers from around the world talk about the present and future of automated testing, share ideas with fellow Selenium developers, including Core Committers, and take part in shaping the future success of the Selenium project.

When: April 4-6, 2011
Where: Marines’ Memorial Club & Hotel, 609 Sutter St, San Francisco, CA 94102 USA
Register now to be a speaker or sponsor. More details: http://www.seleniumconf.com/

The Blog-Health-o-Meter™ reads Fresher than ever.

Crunchy numbers

A Boeing 747-400 passenger jet can hold 416 passengers. This blog was viewed about 6,600 times in 2010. That’s about 16 full 747s.

In 2010, there were 15 new posts, growing the total archive of this blog to 115 posts. There were 24 pictures uploaded, taking up a total of 979kb. That’s about 2 pictures per month.

The busiest day of the year was June 4th with 139 views. The most popular post that day was Don’t build software that’s TOO smart!.

Where did they come from?

The top referring sites in 2010 were agile.dzone.com, java.dzone.com, twitter.com, Google Reader, and javablogs.com.

Some visitors came searching, mostly for matt stine, groovy http post, groovy post, groovy url post, and groovy url encode.

Attractions in 2010

These are the posts and pages that got the most views in 2010.

Don’t build software that’s TOO smart! June 2010
1 comment

Groovy: Post to a URL April 2009
4 comments

Resume March 2009

Deploying Grails with Groovy March 2009

LOTY Time Again: Scala or Clojure?!?! April 2009
17 comments

If you’re looking for your next automated testing tool for browser-based user acceptance tests, download the card and let me know what you think!

• Modular Agile: Loosely coupled, highly cohesive ceremonies
• Think You’re “Doing Kanban?” Think Again.
• On Gaelyks and Golden Hammers
• Automation for the People (because Everybody Doing It Manually Hurts)
• Build Scripts? We Don’t Need No Stinkin’ Build Scripts!
• Automated Browser Testing: What’s in Your Toolkit?
• To Selenese or not to Test? That Seems to be the Question.
• Is the Apple JVM an “Extra Feature?”

• The Seven Wastes of Software Development – Introduction
• Waste #1 – Partially Done Work
• Waste #2 – Extra Features
• Waste #3 – Relearning
• Waste #4 – Handoffs
• Waste #5 – Delays
• Waste #6 – Task Switching
• Waste #7 – Defects

Here’s a list of the complete set of articles for your convenience!

• The Agile Guerilla
• Show (Don’t Tell), Persuade (Don’t Preach)
• Going Guerilla: Where to Start
• The Guerilla’s Workflow
• Guerilla TDD
• Guerilla Continous Integration
• So What Are You Waiting For? GO BANANAS!

• Yes You Kanban!
• The Guerilla’s Workflow
• Feedback is the Key!
• Going Guerilla: Where to Start

In the near future you can look forward to a few more episodes of “The Agile Guerilla” series, as well as a brand new series I’ll be starting entitled “The Seven Wastes of Software Development.”

Got any topics you want to hear more about? Post up in the comments and I’ll see about covering them at Agile Zone in the coming weeks!

I recently accepted the role of Agile Zone Leader at DZone.com. For the past few weeks I’ve been publishing a couple of articles a week on various agile development topics. I’m very happy to get the extra exposure and I hope that folks are getting some value out of my posts. On the downside, I have virtually zero time to write anything here, but on the upside I’m definitely writing more regularly. Nothing like positive pressure to deliver!

Here are some links to my recent articles:

• You Are Your Software’s Immune System!
• Interview: Alan Shalloway on Lean Agile Software Development, Part One
• Interview: Alan Shalloway on Lean Agile Software Development, Part Two
• Show (Don’t Tell), Persuade (Don’t Preach)
• But the ScrumMaster said I had to!
• The Agile Guerilla
• Use Stories to Deliver Business Value

Enjoy!

The first talk is entitled “The Seven Wastes of Software Development.” We’ll begin by examining one of the key tenets of Lean Software Development, that of eliminating waste. We’ll then walk through the seven wastes identified by Mary and Tom Poppendieck in their books:

• Partially Done Work
• Extra Processes
• Extra Features
• Task Switching
• Waiting
• Motion
• Defects

We’ll examine each of these wastes and look at some of their common manifestations, both in our coding practices and in our development methodologies. We’ll also examine strategies for eliminating each of these wastes from our development efforts.

The second talk is entitled “Yes You Kanban!” Kanban is sweeping through the agile software development space. Is it hype? Or is it a useful tool to add to our belt? In this session, we’ll walk through the following topics and I’ll let you be the judge:

• What is Kanban?
• What is Kanban NOT?
• Comparison to SCRUM
• Roots of Kanban
• David Anderson’s five essential elements/principles of Kanban (Visualize workflow, Limit work-in-progress, Measure & manage flow, Make process policies explicit, Use models to recognize improvement opportunities)
• Examples of Kanban systems

I hope to see some of you in these talks this Fall and I look forward to our discussions!