(GR)²

I wanted to have posted this review a week ago, but missing a couple days of work for the sake of the class sort of threw my schedule off.

In mid-October, I took a Certified ScrumMaster class offered by Solutions IQ. It was the same as this class, except it was offered locally to me and in mid-October rather than November.

Now, I do not believe that two days -- even two very long, very full days! -- of training will make anyone qualified to do the job in question. I do plan to go on and take the Berkeley program in Agile (five or six courses, depending on the electives chosen, and about 175-200 class hours).

That said? This was vastly more useful than I had anticipated -- and I had anticipated that it would be valuable to me, since I haven't yet had the chance to work in an Agile environment.

The material was concise, clear, useful, and even entertaining; the entire class was paying attention, because paying attention wasn't difficult -- it was fun.

But for me, the most valuable part of the experience was the chance to see Agile behaviors in action. Reading it is simply not the same. A game with a simple goal and short rounds with a chance to re-evaluate team strategy between rounds; a couple of chances to emulate a scrum process in low-risk, high reward circumstances; and the regular retrospective on the class itself all made the Agile/Scrum processes so much clearer. And the whole thing seems much less intimidating than it did -- estimating, choosing a backlog, doing stand-ups, demo-ing the sprint, and doing a retrospective on what went well, what could go better, and how, all seem less mysterious and far more do-able than they did before the class.

I wish we'd had another couple of hours, if not another full day; I'd have liked to have more active practice with retrospectives, for one thing, and how the scrum master's role in the retrospective works in practice. But SIQ's class has certainly whetted my appetite for more, and even given me the confidence that I could, push come to shove, do well in an Agile environment even today.

As I understand it, one of the underpinnings of Agile is transparency -- it's always possible to see what's going on, from the perspective of the team, the client, or management. In waterfall projects, a lot of time is dedicated to designing and delivery reports of various sorts: reports get a lot of management attention, but not necessarily a lot of management understanding.

How can I make my reports actually useful to my management, and to my projects, and to me?

For any report, I need to understand what management actually needs from the report, and what I need to communicate to management. And I need to do that so clearly that someone who's spending 90 seconds looking at the report can see what I want them to see. Agile burn-down reports are extremely informative, but I know that I struggled with understanding them correctly when I first saw one; in Schwaber's Agile Project Management with Scrum, he tells a story about a company where the easiest solution to reporting for management that wasn't familiar with Agile or Scrum was to treat stories as tasks and show a normal-looking Gantt chart of progress.

For project reporting, management needs to know two kinds of things:

1. Progress
• what the goal is
• what has been done to reach that goal
• what remains to be done to reach that goal
• some estimate of the time frame
2. Where the current issues, blocks, or risks are and
• how they can be handled

Burn-down charts, once you're familiar with them, do a good job of communicating the first of these; if management isn't familiar with them, it may be useful to offer simple lists of goals, steps accomplished, steps to be accomplished, and estimated step durations. The second, when it's necessary, can be trickier; but the most useful thing I've found is to give the best available evaluation of the risk and present the options with the technical data the manager(s) in question will expect and the associated impacts -- what each option will cost and return in terms of time, resources, and money.

---

It's easy to feel as though the time spent writing reports -- especially in a waterfall environment -- is wasted; there's often a sense that no one will read or really care about a report unless it doesn't show up on time or makes it clear that there is bad news. People who ask for reports often seem uncertain how to extract useful information from them, beyond "everything looks ok" or "um, we may not make our deadline."

If I can keep a report clearly laid out and concise, I have a much better shot at getting it read. If, on top of that, I can make sure that the most important information is presented in the first half a page or so, and that there's enough white space on the page that it's easy to pick out the important bits, then the information I want and need to communicate can actually make it to the people who need to see it.

A clear, simple layout, with the critical information (what's the time frame, what issues need to be resolved and how, and whether progress is continuing as expected) at the top makes it easy for me to write the report, and easy for management to understand and use it.

Right now, I'm working in a waterfall environment -- gather the requirements, get sign-off on the requirements, manage any change requests after the requirements are signed off, move to design, then development, then test, then production.

And I'm not the CEO, or the CIO, or even the director of my group; I'm an individual requirements manager. So the degree to which I can push change is pretty limited. But so much of what I'm reading and hearing about how Agile approaches development projects makes so much sense! I've been talking to people like my friend Mickey, and pondering how I can apply this attitude in the waterfall environment I'm currently in.

Nancy Van Schooenderwoert has an article at Agile Rules in which she talks about empiricism as the essence of Agile. It's often referred to as "inspect and adapt," but it is basically the scientific method, as far as I can tell. Here's how I understand it:

1. Come up with an initial approach (theory)
2. Try out that initial approach (testing the theory experimentally)
3. At the end of a set (short) period, evaluate the results of that approach (the results of the experiment)
4. Refine your model

And that is a basic analytic tool I can use under any circumstances.

So my current goal is to look at the projects currently on my plate, determine where I can cut short the definitional process by giving a clear and clearly limited summary of what we need to do next, and doing that thing followed by immediate evaluation and refining of the model.

The other piece of "Agile Attitude" that this will depend on is the frequent brief touch-base with all project team members, to find out where things are working effectively and where we need to adjust or adapt. So the other thing I'll be trying to do over the next week or two is move from weekly hour-long meetings toward shorter (half hour? twenty minute?) meetings held twice a week, or eventually more frequently than that.

And then I'll inspect the results of that effort, and adapt accordingly.

As I start talking about Agile and Scrum, I'm beginning to use the specialized terms associated with them. But as I mentioned in the last post, failing to have a clear mutual definition of terms can lead to fundamental errors that can be very difficult to correct. So -- here is what I currently understand to be the meanings of these terms. I would love to get clarification, disagreement, elaboration, or other commentary -- I'm at the very beginning of this learning curve, after all!


So - that's how I'm currently using these terms, when they show up in what I write. Disagreement? Elaboration? Commentary? Comment, please!
[and thanks to Mickey Phoenix for his clarifications!]

I'm continuing to make my way through the Schwaber text that will be one of the two used in the October CSM training I'm attending, and continuing to want to scribble things in the margins. Since the copy I'm reading at the moment is the library's, it seems wiser to make my notes here.

I'm finding myself really drawn to his description of what's needed to start a Scrum project:

1. A vision
2. A product backlog

There's a little more detail than that --

1. A vision
• why are we doing this? (what problem are we solving?)
• what will we have when we're done?
2. A product backlog
• goals for the first sprint
• anticipated goals for the second sprint
• a rough idea of what sprints are currently expected to produce what items from the product backlog

"Be careful what you ask for -- you might get it." It's true; ask with care. Listen with care. Define your terms -- be sure what you say means the same thing to the person you're asking that it does to you. This one thing is critical no matter what kind of project management you're doing -- and for pretty much anything else, too.

---

I told them I wanted scarves;
they gave me silks and fine-woven cambric, gossamer clouds of color.
How could I tell them, then, that I was cold?

---

---

I dream of snow-crunch, twig-snap, soft thud of snow falling from a branch;
I want to walk in that cold, ice-bound landscape.
Down coat, warm red mittens, stout boots, and -- joy! --
a cloud-soft woolen scarf around my neck, tucked deep into my coat.

---

It's hard to remember to ask the client not what they want, but why they want it. But if you don't know that, it can all fall apart. John Bauer's notes on the Agile Boot Camp he attended include this (approximate) quote from Rod Ashton: "When asking why, consider 5 level of 'why’s to get to the bottom of the real need." The rest of his notes from that Agile Boot Camp were valuable too, but that's the one that's ringing like a bell for me. Find a way to keep asking "why do you want that? what will it do for you?" until you're positive you have the root need -- and then ask one or two more times, just to be sure.

Then you have a vision you can be confident will ground the whole project.

I just finished a six-minute meeting.

Prior to that meeting, we had had three or four rounds of e-mail with increasing frustration on all sides; even getting the meeting scheduled required multiple re-schedulings. Everybody thought the problem belonged to someone else.

But the meeting itself lasted six minutes, and everybody left it happy with the result. (And with the 54 minutes they got back on their calendars!)

What happened?

Of course, there are some specific factors relating to the actual question at hand in that particular meeting; but I've seen this kind of thing happen too often to think that that's all there is to it.

I love e-mail. I can send an e-mail when I'm thinking about it, even after hours; in an e-mail, I can take my time and phrase things as carefully and accurately as I can, I can stop and research a question if I'm not one hundred percent confident of my answer, I can re-read and make sure I'm not leaving out important information, or saying something in a way that will be easy for the recipient to misunderstand. And of course, e-mail lets me interact conveniently with people who aren't on the same schedule I'm on, or whose time is so limited that catching them "live" is really difficult.

E-mail works really well for a lot of things. When the parties know (and trust) each other, when the issue is straightforward, or when all that's needed is to communicate a lot of information fairly efficiently, e-mail is wonderful.

But where the parties haven't interacted a lot, where the issue is confusing, where there's disagreement about the basics, or where there's a need to share information back and forth, a six minute meeting can replace hours of reading and replying to increasingly frustrated, and frustrating, e-mail.

(How to make that meeting efficient, useful, and productive? That's a whole other topic.)

The solutions we found in our six-minute meeting this morning will be implemented by the developers and the client; my take-away is that the next time I see an e-mail exchange that boils down to "can so!" "can not!" I'm scheduling the meeting right then, not waiting for another round or two of e-mail first.

Is it so simple?
Make it clear, pay attention,
modify -- succeed?

Know what you need now;
Keep it small enough to see;
and -- oh -- show your work.

Evaluate: Done?
What do you really still need?
Do the next thing.

All animals are
not equal: Pigs give bacon;
chickens? Only eggs.

So put pigs in charge --
since it's their butts on the line!
Still, do heed the hens.

The Product and the
Sprint Backlogs, and the burn-down --
um. One more time, please?

Sheep scatter, drawn to
the newest, greenest grasses;
Wolves threaten. Dog guards.

But sheep are not as
dumb as they are said to be;
they train the dog, too.

And the shepherd learns
from dog, from sheep, and from wolves;
Best keep the touch light.