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.

Retrospectives

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?

 

Comments:

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

Scrumalicious

The Scrum Yahoo! group is again undergoing some minor turbulence about proper use of the list. Someone from the Scrum Alliance laid out the law with a number of rules about what could and could not be posted to the list. Many people reacted poorly–supposedly this is the poster’s first post, and he’s not even a Certified Scrum Master (CSM). (gasp!)

Oddly, a year or so ago when there was similar agonizing over the use of the list, it appeared as if L. Ken Schwaber “owned” the Yahoo! group and thus controlled(an important word in the Scrum community) appropriate content. Not that there’s anything wrong with that. For those who like command & control, with the additional potential of being part of a good multi-level marketing machine, the Scrum system provides a wonderful starting point.

The nice thing is that you can still do Scrum and talk about Scrum without succumbing to the controlled community that is S©rum. As far as I know, there’s no licensing scheme required to be able to say, “I’m doing Scrum.” And that’s exactly what I’d recommend. No annual maintenance fee required! No required trainer tiering! Yes, you need a Scrum Master in order to successfully execute Scrum. But I don’t believe they must be “certified.” (I could be wrong–perhaps I need a lawyer here!)

Where might you find a good Scrum Master? Well, you should probably read L. Ken Schwaber’s book, Agile Project Management With Scrum (that link is my piece of the Scrum machine’s gravy train, by the way). You’ll quickly discover, through a number of case studies that L. relates, that Scrum and S©rum are mostly a matter of executing to common sense, best done by someone with good experience in people-oriented problem solving and leadership. Find someone who can do that well, and hire them. It really doesn’t matter if they’re a CSM.

Agile and PHBs

We all think Scott Adams has worked in our offices, given how often conversations between Dilbert, his co-workers, and his PHB (pointy-haired boss) seem like conversations we’ve just had. I remember some discussions with management about metrics; the very next Dilbert strip read like someone had recorded our conversation.

Today, Dilbert’s PHB paraphrases agile programming to mean “no more planning and no more documentation.” The PHB directs the team to “just start writing code and complaining.”

That’s precisely what many people think agile to be. It’s why I often curse the notion of big-A “Agile.” Buzzwords almost always end up suggesting equally succinct negative connotations. I spoke recently at a BA conference, and my audience quickly confirmed their perception of agile met these the big myths: no planning and no documentation.

I won’t belabor an argument. Basically, to do agile well, you must plan all the time. And with respect to documentation, agile generally says that documentation is a cost that must be recognized. It doesn’t say don’t do it; it says prioritize documentation with respect to its business value.

In the final panel of today’s strip, the PHB says to Dilbert, “That was your training.” In fact, that’s often all training is nowadays. A concept is distilled into an article, or even two sentences, and the corporation feels that it has adequately trained its people. I’ve actually heard management suggest that its people should be smart enough to seek out and understand new concepts completely on their own.

Yes, agile is a fairly simple concept. Yes, training courses only provide so much value. But there’s enough in agile to get wrong and misinterpret that you’d be a PHB were you to ignore the need to properly train your teams.

Comments:

Hear hear!

Sadly, in process as well as in politics, often you are stuck with nothing more than the sound bite.

Atom