|
in reply to Nobody Expects the Agile Imposition (Part V): Meetings
The more I read about Scrum, especially in your fine nodes here at Perlmonks, the more I find an odd and funny disparity between the "agile" ideal and the rigid enforcement of pomp and false tradition. I say "false tradition" because it's being enforced from on high and hasn't really had a chance to become an organic observance of the people involved. Does all of this rigidity in the coordination points really add to the fluidity and adaptability of the team in completing projects? Would a daily group chat log achieve all of the benefits of an in-person meeting in this context? There are many questions raised by these rules imposed on the process.
I understand the importance of frequent status updates. If someone has a task estimated at a month, you don't want to find at 27 days that the task is off-course and will take two months to complete. These daily meetings are useful as articulation points. Up to a point, the more rapidly you can get information about the accuracy of your estimates the more you can adjust.I'm not certain the fixed schedule, place, and format of the meetings is necessary to make the team members accountable for their estimates and to adjust the implementation schedule, though. Reporting to the whole team rather than just the project manager is good, and for some people a face-to-face meeting will make them feel more accountable perhaps. I think reporting to the team is the bigger feature, though, compared to doing so face-to-face.
The importance of always having the meeting at the exact same time and in the exact same place are clear. However, they are only important for a face-to-face group meeting. Keeping the group waiting in person or having half the team in the wrong room is bad for getting the information shared.
However, there are other ways to share information. Imagine a scenario with me. Have each team member answer the three core questions of Scrum every day. Have them do so into a log (minutes are just the transcription into a log anyway) readable by the whole team. Make sure they make their entries by a certain time. Have the whole team actually read it every day, before they start on their own entry for the next day. This scenario and its contrast to the prescribed ritual of Scrum for me leads to several questions. First and foremost, in what way does this detract from the quality of the information or its effective use? Do questions have to be raised interactively during a face-to-face meeting? Can a team member not ask another about his answers to the three main questions on a bulletin board or forum? Is the main problem with using technology to facilitate the transfer of information in this way that it violates the time box? Is the time box actually as important as getting full answers to the questions that are important enough to ask in a meeting? Isn't the time box important mainly because group in-person ties up all the resources of the team at the same time in the first place? Is there actually a concern that the team members will waste so much time communicating about the project that the implementation will fall behind from that one factor?
The frequent exchange of information is the goal here. That much is clear. However, the rest of the meeting information in Scrum seems to be just potentially useful tips for how to conduct the meetings in an orderly way. It almost feels like the authors of the method felt they were short some material after stating all the other rules to Scrum. The added detail beyond which questions are to be answered daily and which parties are to be actively involved in the discourse and which are to be observers (which are excellent ideas) seem to me to be filler for the books. At best they are reasonable defaults, and in no way do they seem to be absolute necessities for every team.
|
Re^2: Nobody Expects the Agile Imposition (Part V): Meetings
by JavaFan (Canon) on Dec 13, 2010 at 13:06 UTC
|
I understand the importance of frequent status updates. If someone has a task estimated at a month, you don't want to find at 27 days that the task is off-course and will take two months to complete. These daily meetings are useful as articulation points.
But that's not the point of daily standups. In an "out-of-the-book" sprint, the team has at the beginning of the sprint split the project into small tasks without deciding who is going to do what. Tasks can be in a small number of states: "not worked on", "being worked on", "blocked" (or impeded), "done". Many teams use a board with columns for the states, and sticky notes for the tasks. During the standup, people move sticky notes from one column to the other. The standup is important to avoid having the same people work on the same task, and to know which tasks can now be worked on because they first need other tasks to be finished. (For instance, if a project involves installing an OS and a database, the task for installing a database cannot be done before the task of installing the OS has finished (which needs to be done after taking the machine out of the box and into the racks (which can only be done after ordering the box (which depends on the task of securing funding, etc)))).
Note also that in out-of-the-box scrum, you don't estimate how long a project will last, then adjust the estimate during the development. It's the other way around. "We have a month (or 2 weeks, or 2 months, usually nothing longer), what can we do in that period". Traditional project management is usually "We want X, we have Y developers, hence we estimate it's going to take Z days", or "We want X, the deadline is in Z days, hence we estimate we need Y developers". Scrum is "We have Y developers, we have Z days. Product owner, split X into smaller X' features, and we'll estimate how many X's we can do". (Note I'm not giving any judgement whether this is a good idea, and I'm sure everyone can come up with at least one scenario where it isn't going to work - I'm just telling what the reasoning behind scrum is).
| [reply] |
|
|
Bah.
If you have actually succeeded in “breaking the work down into small tasks,” it doesn’t really matter “who does what.” The real issue, neatly avoided by all this quasi-sports talk, comes down to exactly two things:
-
Are you correct in your breakdown of the tasks?
-
Will the target ever change position, or otherwise change in any way at all?
Imagine, if you will, the task of shooting arrows at a target in a tornado. Most of the arrows that you shoot are going to fly off course: it doesn’t matter at all if, or how, you “track” those arrows. Either the arrows were mis-aimed, or the target moved, or you somehow just wound-up with an arrow in your butt (but don’t quite know just how it got there...), or some combination of the three.
Or maybe you have a “magic arrow” that will zip this way and that, gradually “homing in” on that moving-target. But, how long was the course taken by that arrow, and how many trees and other obstacles did it have to blast its way through on its magical, determined effort to “finally hit the target?”
An experienced marksman would wait for the tornado to pass. She would size up the situation carefully, place herself at the position she had chosen, and fire one shot. Only one. And she would not walk up to the target to see if her arrow had done its job.
I say (and not without experience to back me up...) that, when you are actually ready to write software code, writing the code is easy. After all, “the code” is simply an expression of the design ... the most-rigid and inflexible expression, but comprehensible to a digital computer. This should be the last incarnation that your completed design will take, and you should delay putting it into that form as long as possible.
But of course, people who are paying a dreadful amount of money for something want to see “progress.” And people who are working on that something, want to “progress.” Building meticulous blueprints doesn’t feel like “building a house.” And, Home Depot didn’t get to be a big, fat company by selling materials to people who draw blueprints.
(I don’t say this to be persnickety. I say this as someone who has written more than three quarters of a million lines of source-code in about twenty programming languages... while silver-bullets came and went, and were in their turn discarded.)
| |
|
|
So they wrote a book on managing a to-do list?
There's nothing that can be done with overpriced slightly tacky paper squares that can't be done in software more reliably. If you must meet in person, at least get a projector and use scheduling software. In/out status of the team members, completed/incomplete/not started status of a subproject, Gantt modeling, dependency tracking, and more are very simple software tasks. If your team can't find software to do those things and can't knock that together in a week then they have no business writing projects that need it.
| [reply] |
|
|
So they wrote a book on managing a to-do list?
Scrum is more than standups.
If your team can't find software to do those things and can't knock that together in a week then they have no business writing projects that need it.
Been there, done that. Haven't seen any software that isn't sucky. Would prefer sticky notes over software. Note that scrum doesn't mandate the medium (note also that I'm not advocating scrum in this thread - I'm just explaining how it works). If a team prefers software, it uses software. Our team started with in-house javascript based software, progessed to a wiki-page and now uses nothing at all to keep track of "tasks".
| [reply] |
|
|
|
|
