Friday, September 24, 2010
11:19 PM | 
Posted by
Michele |
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!]
| 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!]
Labels:
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:
"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.
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'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?
- 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.
Tuesday, September 14, 2010
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.
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.
Saturday, September 11, 2010
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.
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.
Subscribe to:
Posts (Atom)
Subscribe To GR Squared
Posts
All Comments