The Bowling Game

Sometimes the “toy” examples we build lead to something real. A few years ago, I wrote a 13-part article series for Informit, demonstrating TDD using the game of hold ’em poker. Shortly thereafter, I received a call from a company looking for Java developers to help them build an automated poker application for in-casino table. The pitch was that this would eliminate the need for costly human dealers; it would also speed up gameplay, allowing more hands and thus increasing the house’s rake. Someone at the small startup had read my articles and figured I at least knew the domain!

That work never materialized. Today I received an email (probably broadcast to wide distribution) from a headhunter with an interesting need: “We’re looking for someone in DFW with C# and C++ development experience who loves to bowl! They will be creating software for the sport of bowling and should have an interest in OR knowledge of the sport…” Ha! I don’t know that this is for an agile shop, but is there a hardcore agile developer out there who hasn’t coded the bowling game at least once? I wonder if that qualifies. 🙂

I’d alert Ron, but I’m sure he wouldn’t consider moving to Dallas. Well, if you’re interested, let me know and I’ll forward the recruiter info. Or if you’re looking for work in an agile shop elsewhere, check out the agile jobs list.

ScrumAlliance ™

On the scrumdevelopment Yahoo! group, a discussion revolves around user group concerns over the trademarking of the phrase “Sc*um User Group.” (Note that I’ve starred the name in order to avoid trademark violations.) A few inquiries resulted in an official response from a Sc*umAlliance representative.

I find it odd that (a) no one belonging to the “Sc*umAlliance” (whoever they really are–I’m suspecting maybe Mars, but given their legal nature, maybe Uranus) frequents the scrumdevelopment group, (b) none of them chose to respond directly on the group once apprised of the concerns, and (c) Ken Schwaber didn’t have an immediate answer (regardless of his affiliation with the Sc*umAlliance). I suppose there must be people (lawyers, no doubt) who don’t have to be at all interested in the product they support, but it just seems wrong somehow.

Agile requires lots of communication and continual negotiation. Bits of command and control have their value at times, but in most cases C&C begins to eat away at the trust relationship required for continual negotiation. I suggest people considering or doing Sc*um dispense with the trappings of a trademarked process and look instead to understanding what agile is really about.

The progenitors of agile–i.e. the agile manifesto signatories–rightly eschewed “heavyweight” processes–processes centered around lots of documentation and meetings. I think there’s a new category of “heavy” that should be spurned, and that includes processes controlled by people so heavily wrapped up in legal and licensing protections that they can’t bother discussing changes with the community who would be affected.

On Email Lists and Advocacy

I try to keep up with all of the various agile “Yahoo! Group” lists: extremeprogramming, scrumdevelopment, refactoring, testdrivendevelopment, agile-testing, and so on. I post once in a while when I see a topic I feel qualified to respond to or that I’m passionate about. Lately I’ve been getting a lot less value out of these lists, some of which I’ve been following for ten years.

Many of the lists degrade into passionate statements of position, i.e. advocacy. Inevitably, people get burnt. Tempers flare, people get upset, some stomp their feet, some simply withdraw. I myself have gotten burnt on this same list, feeling that someone (probably not coincidentally, the same person who is withdrawing now) was looking to simply piece apart every single word written to find as much fault as possible with it.

I withdrew completely from that discussion. I’ve also withdrawn from perhaps a couple other difficult discussions (out of the hundreds I’ve engaged in over the years). Sometimes it’s because I felt the environment was too hostile, and I justified it to myself by thinking that the individuals involved were being immature or offensive or whatever. But that’s not courage speaking. I looked back at my most recent example and regretted how I handled it. Withdrawing didn’t solve anything.

Sometimes a simple statement, meant to be innocuous by who wrote it, is taken as a stab and affront. We can pout and take our toys and go home, but that’s not at all useful or commendable. Courage can help us find a way to face the challenge and learn how to get past the issue. We don’t have to agree with everyone or get along with them, but sometimes a sour incident can lead to a valuable relationship.

So how is this at all relevant to anything? Well, if we are to succeed, agile software development requires that we face challenges and not bury them in isolated cubes. Similar clashes occur not only on email lists, but in real life, and we’re particularly going to see such clashes more frequently in highly collaborative teams. Conflicts that are not handled properly will detract from a team’s ability to deliver. The XP value of courage is still essential to learning how to regularly deliver quality software.

Agile in a Flash

Make sure you check out the Agile In a Flash blog, where Tim Ottinger and I will be cranking out an agile flash-card deck.


Iterations are the heartbeat of agile–a consistent pulse, something that can be measured. If iterations are the heartbeat, the heart is retrospectives, representing the core and true spirit of agile: How do we adapt, how do we continually improve?

Too many teams don’t run retrospectives, and many of those that do fall off quickly. Often they fell into the trap of running a consistently boring meeting: What things did we do well, what things do we want to improve upon? Worse, they treated the outcome of the retrospective as a bunch of vague promises. I’d certainly stop attending them if that’s all they were.

A solution to the first is the Esther Derby/Diana Larsen book, Agile Retrospectives. The biggest value of this book is that it provides a number of activities to help you run your retrospectives. It provides a great starting point to devising your own activities–being creative is an important way of keeping people interested in attending retrospectives. There are a number of areas that remain to be explored with respect to retrospectives. For example, I’m currently continuing to explore distributed retrospectives.

With respect to the second challenge–lack of commitment–I like treating the retrospective items as stories, or experiments, that are introduced for the upcoming iteration (but these are not project stories). Thus acceptance criteria are required, and the stories must be specific, concrete things that people will (or won’t) do. During the subsequent retrospective, the team can’t consider the experiment complete if the acceptance criteria has not been met, and thus shouldn’t base subsequent actions on that experiment.

There’s always someone who wants an agile litmus test. “You aren’t agile if…” I feel comfortable in saying that “you aren’t agile if you aren’t consistently doing retrospectives and adapting the process based on them.”

Distributed Project Retrospectives

Recently I’ve done three distributed project retrospectives. I’ve heavily used the ideas in the Esther Derby/Diana Larsen book Agile Retrospectives to provide a foundation for these online meetings. Here’s their general flow with a few comments and one addition:

  • Establish base rules They need to “own” the rules but you should expect to kick off with a few of your own.
  • Safety exercise “I am planning on being very open and vocal during this retrospective.” – strongly agree, agree, neutral, disagree, strongly disagree. Answers to this will help you hold at least some people to their promises to talk. It may suggest the need to do even more anonymous polling during the meeting.
  • Gather data For project retrospectives, the Time Line activity has been especially useful. I simply share my desktop, put Excel up and start filling in events, with some dates, from left to right.
  • Generate insights, locate strengths
  • Commit to improvements I solicit as many variant solutions as possible for a given challenge, and then let them vote on what they think the best one is to carry forward on a new project.
  • Close

Here are some brief suppositions and observations:

  • Use “online only.” Everyone on the line should be at a separate station, not meeting together in a room. While this can increase phone line costs, it prevents “phone vs. live” dominance issues. Everyone sees the same thing.
  • Use some sort of communication software with polling capability. I used WebEx for each of these three sessions. It’s flaky but works. Make sure you try creating some questions ahead of time and understand both ends: How are questions defined, and what does the end user see?
  • Some of the problems with WebEx polling:
    • No scaling/ranking question type available
    • Easy to create a screwed-up poll and not know until answers are submitted
    • Crummy interface overall. Too many opportunities for “user error”
    • Can’t easily share anonymous answers to “free form” questions
    • Lame file-based save/load interface
    • I didn’t see how to change the amount of time a poll was open
    • No way to limit the number of “votes” on a multiple-choice answer
  • Come prepared with some good poll questions, but also look to create them on the fly. For example, after soliciting things that went poorly, it’s useful to find out the top three or so to concentrate on. You might normally do this with dot voting and cards. Here, you can create a poll and ask people to select a certain number of items from the list.
  • No matter how hard you try, many people will choose to not talk in a larger (> 15) meeting. With a meeting of ~15 or less, the idea (Derby’s?) of starting the retrospective by asking everyone to express their hopes for the meeting is a very good one; it gets people talking.
  • Get an assistant to take notes, type questions, monitor chat, etc. They will allow you to focus on listening and steering the retrospective.

It’s never the same as everyone being there! I view online retrospectives as a microcosm of doing the whole of agile in a highly distributed fashion. Effective communication becomes very difficult.

The Right Profile

I’ve been feeling a little dirty recently from dealings with people who might most kindly be called duplicitous. “I’m agile,” they state at the same time their ass backs up into a cave-cube, looking to grab an ugly stick with which to beat down team members.

My wish is greedy and unreasonable: I want nothing more than to expect that if people say they are supportive of something, then they actually understand what they’re supporting and actively try to do so. (It’s asking a lot, given that millions of US citizens just did otherwise.)

On days when I feel like Catbert, I want to use a personality-profile-based litmus test for agile attitude. Does the use of personality profiles in business derive from mistrust, from people being burned? Are they a tool for evil when used as a factor in hiring?

Employing such a test would require sufficient data demonstrating a correlation between personalities and agile. Is there correlation? A study is warranted; what would that look like? I imagine in its simplest form there are two questions.

  1. What is your Meyers-Briggs type indicator?
  2. Do you really buy into agile? (… or however you ask this and get an honest answer)

I have two suspicions hypotheses: One, for the most part, there is little correlation, and agile-capables are all over the personality map. But two, I suspect there are one or two personality types (out of the 16 Meyes-Briggs types) for whom agile is a bad match.

Complete Stories, Not Iterations. Again.

No matter how hard I try, there’s always a hammer in my life. Sure, I try to use all those other new-fangled tools that are perhaps more appropriate to the problem, but I find that my hammer is a versatile tool that helps me bang my way out of many trouble spots. My recent agile hammer is “complete stories, not iterations.” In other words, collaborate! I’ve made a few blog posts and written at least one article on the topic.

Everything seems to keep coming back to this. A focus on completing stories as a team, and not moving on until the story is “done done,” tends to eliminate many of the questions that otherwise exist.

For example, “Should we create stories for defects?”

The glib answer is of course, “Well, if you’re doing agile properly, you don’t have defects.” But the more satisfying and less annoying answer is, “Well, if you’re collaborating to get stories completed, you don’t have many defects that survive the iteration.” If you can deliver a story every day or two through an iteration, the story can move into preliminary testing, and odds are that you’ll uncover many defects before the iteration completes. That means you can either fix them before the iteration completes, or you haven’t finished the story (it’s not “done done”), and the story is slotted wholesale into a subsequent iteration.

Voila. Concern over whether or not to create defect stories? Poof! (If you still have the question, the answer is “yes,” because they can be estimated, and because they take development effort that adds into team velocity.)

Five Violations of Agile

(aka Five Core Reasons Why Your Attempts at Agile are Failing)

  • Developers work as individuals, not a team, and refuse to collaborate on stories
  • Emphasis on iterations over stories, instead of trying to deliver “done done” stories every day or two
  • Automated ATs are not the focal point of negotiation and completion
  • Unwillingness to adapt the process as a result of retrospectives
  • Acceptance of incomplete work at the end of an iteration

Spotting Agile

I know that a team is on the right track when they:

  • deliver on the majority of their commitments each iteration, and at most a portion of one story is incomplete at the end of an iteration
  • deliver stories every 1-3 days, on average, throughout an iteration
  • can tell you relevant statistics about the code base, for example, how many unit tests are there and how long they take to run
  • commit to improvement, and deliver on that commitment, without having to be told–they just do it
  • don’t fear open conflict
  • can be seen talking about the code

What other indicators do you have?



How about- they don’t have any person on the team that is a bottleneck for completing work.