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.
Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
Read Where should I post X? if you're not absolutely sure you're posting in the right place.
Please read these before you post! —
Posts may use any of the Perl Monks Approved HTML tags:
You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
- a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
Link using PerlMonks shortcuts! What shortcuts can I use for linking?
See Writeup Formatting Tips and other pages linked from there for more info.
| & || & |
| < || < |
| > || > |
| [ || [ |
| ] || ] ||