- Consulting / Coaching
- Jeff’s Blog
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.
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.
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.
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.”
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:
Here are some brief suppositions and observations:
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.
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.
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.
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.)
I know that a team is on the right track when they:
What other indicators do you have?