Sunday, October 24, 2010
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.
Monday, October 11, 2010
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.
Sunday, October 3, 2010
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.

Search

Loading...
I've been working as a technical writer, business analyst, and project manager for more than twenty years. I've worked on many projects in many industries, and I've come to believe that the top-down culture and the CYA process design that's common to many companies regardless of size is profoundly counterproductive, and I'm looking for ways to change that culture and those processes.

In looking for a different way to organize people and projects, I found the Agile Manifesto. The Agile principles of valuing human interactions, collaboration, and openness to change sound wonderful; the focus on sustainability, simplicity, self-organization, and flexibility sounds good too.

I'm starting to study Agile; I'm taking a two-day class in October 2010, and planning to begin an Agile Management program at Berkeley in November 2010. I'll be talking about what I'm learning as I learn it; comments, feedback, questions, and advice are all very welcome.