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.
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:
- 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
- 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.
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:
- Come up with an initial approach (theory)
- Try out that initial approach (testing the theory experimentally)
- At the end of a set (short) period, evaluate the results of that approach (the results of the experiment)
- Refine your model
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.
|Agile||A philosophical approach to project management, and particularly to software development project management, that emphasizes the importance of human interactions and collaboration and responsiveness to a changing environment. The goal of an Agile approach to software development is to create a strong collaborative team including traditionally isolated functions (development, QA, customer) as integral members, encourage that team to direct itself in response to the customer's needs and priorities, and produce complete, useful, working software as quickly and frequently as possible. One reason for the goal of frequent software releases is that the quick turn-around time for development means that feedback occurs on a much faster cycle, and errors or misunderstandings are corrected promptly, saving time and effort in the long run.|
|Iteration||A single development cycle of one to four weeks, at the end of which some amount of complete and working software is presented to the client. Changes to priorities or designated goals are made between, not during, sprints, unless a change is sufficiently important to justify ending the iteration early.|
|Scrum||Scrum is an approach to software development that relies on empirical feedback during the development process to fine-tune and improve the choices made during development. The goal of Scrum is to "guide work toward the most valuable outcome possible." [Schwaber, Ken. Agile Project Management with Scrum, Washington: Microsoft Press, 2004. p. 2.]|
|Sprint||A Scrum take on an Iteration: because a Sprint includes formalized, heavy-weight planning and review (typically a day each), a scrum is typically two to four weeks, rather than one to four.|
|Product Owner||The person responsible for setting the priorities so that they're consistent with the needs of the business; this is the person who represents the interests of the business and (if they're different) of the customer.|
|Scrum Master||It's almost more important to say what the Scrum Master isn't. The Scrum Master is not a project manager, is not responsible for assigning work, is not responsible for setting priorities. A Scrum Master has two major responsibilities, and those are quite enough to keep anyone busy: 1. Enforce Scrum practice. 2. Clear bottlenecks and roadblocks. The Scrum Master doesn't set priorities, but does ensure that a kickoff meeting is held for the sprint, and that the product owner works with the team at that meeting to set priorities for the sprint. The Scrum Master doesn't assign work, but does ensure that the daily standups are held and are useful for ensuring that everyone knows what work is getting done and where help may be needed. Managing the Scrum process and removing the team's roadblocks are the responsibilities of the Scrum Master.|
|Product Backlog||The Product Backlog lists the requirements for the product or system being developed. However, rather than being a complete list of requirements established and sealed at the beginning of the project, the Product Backlog is a dynamic list of the functional requirements, performance requirements, etc., that is expected to change over the course of the project. The Product Owner is ultimately responsible for the maintenance and prioritization of the Product Backlog, but the whole team contributes in analyzing the items in the backlog and providing relevant information about each. During a specific sprint, the backlog should not be changed; but at the beginning of each new sprint the product backlog must be revisited as the priorities for the upcoming sprint are determined.|
|User Story||A user story is a way of framing a specific requirement such that it clearly reflects the end user's interest in the feature in question. It should consist of only one or two sentences -- certainly small enough to fit on an index card. They're often phrased as "As a [role], I want to [task], so that [benefit]." -- for instance, "As a blogger, I want to save a draft post without publishing it, so that I can close my browser without losing my work." Sometimes the "so that..." is taken for granted - "As a user, I want to be able to log in to the system" doesn't really need "so I can use it" tacked on -- but (see the previous post) I'd always rather see it included than left out, if there's any doubt.|
|Story Points||Story points are a way of allocating "level of effort" to a story without connecting the effort to an explicit time frame -- rather than saying a task will take seven days, or three hours, or a month, you assign it a number of story points. (This apparently becomes clearer and easier to do with practice.)|
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 finding myself really drawn to his description of what's needed to start a Scrum project:
- A vision
- A product backlog
- A vision
- why are we doing this? (what problem are we solving?)
- what will we have when we're done?
- 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.
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!)
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.
Make it clear, pay attention,
modify -- succeed?
Know what you need now;
Keep it small enough to see;
and -- oh -- show your work.
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.
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.