Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Ovid (2709)

Ovid
  (email not shown publicly)
http://publius-ovidius.livejournal.com/
AOL IM: ovidperl (Add Buddy, Send Message)

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Monday October 04, 2004
10:30 AM

XP Meetings

[ #21180 ]

The problem with XP in our shop, I think, boils down to one thing: I'm the only person on our team (and that includes management) who's read anything about XP, yet we aspire to use "XP like" principles. This is very difficult to correct when no one is willing to learn anything about XP beyond my lone advocacy. Some ideas are enthusiastically accepted but others are rejected. We had one manager (who left the company rather unceremoniously) who was calling two or three meetings a day, so we're very leery about extra meetings. We have an iteration planning meeting and we just started doing stand-up meetings. Sounds good, right?

We do not have release planning meetings. Instead, we have week long iterations and each week a programmer and a manager has a conference call with others and the programmer is forced, on the spot, to estimate how long a particular task will take in "jellybeans." We don't generally get any long-range goals that realistically allow us to estimate many tasks as "ideal weeks." Studios demand a feature, we provide it, one little bit at a time. At the iteration planning meeting, we're told how long the feature should take to implement and the programmer at the conference call explains his understanding of what's involved. Naturally, this often leads to an incomplete understanding of requirements and in one memorable incident, a half-day task that I accepted turned into a half-week task due to "bonus points" included in the task that I had not been informed of.

So I decided it was time to try and convince management to have weekly release planning meetings where all the programmers can learn what the tasks are and discuss how to implement them. I was given a long and thoughtful response. It went something like this: "no."

To be fair, management was concerned about overburdening us with meetings, particularly when we have one-week iterations. As a result, a release planning meeting a week and an iteration planning meeting a week combined with daily stand-ups means seven planned meetings a week. Naturally, the unplanned meetings would put us back to the average of two meetings a day. The compromise was this: we'd combine the release meeting and iteration meeting. Los Angeles would tell us the priority of their work and we'd take all of the highest priority tasks until all were gone. As I was out for surgery last Friday, I didn't get to see this first-hand, but I understand that it didn't work too well. The "carry-over" from last week wasn't taken into consideration, so many tasks that should have been done this week have been postponed. What this means, in reality, is that those tasks will be handed out to whomever has some free time. As I have a light load this week, I have a sneaky suspicion who will get those tasks.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • How burdensome and time consuming are the daily standup meetings? Do they last more than fifteen minutes? Do they solve any problems? What do you talk about?

    When I was team leader during our last big project, I introduced daily team meetings at around 3 PM each day, and most people thought it was useful and a good ting. The subject: "What have we done today, what are we doing tomorrow?".

    One benefit of this round-the-table reporting was that it revealed when people got stuck for a long time on a problem wi
    • The standups have just started, but everyone agrees that they are great. In a nutshell, six programmers stand around and say what they're working on today and maybe a brief explanation of what they're doing to solve it. Implementation discussions are not allowed. I've had to cut people off for getting sidetracked into them. If anyone wants to discuss implementation, they can do so after the meeting. The meeting takes about a minute per programmer, so it's quick and easy.

      We've had a lot of problems wh