I've been following a very interesting series of posts (starting here) from Matt Grommes detailing his experiences managing his first agile project; today he posted a sort of team retrospective.  Having cataloged my own successes and failures during by brief attempt at agile project management, I was eager to see how Matt's experiences compared to my own.  I was surprised to see that the problems he lists are either identical or orthogonal to mine (I was expecting one or the other, but not both).  For instance, Matt found as I did that keeping the backlog tasks and estimates accurate became an issue as the sprint wore on, and that failing to discuss and estimate the product backlog caused significant problems.  But while Matt's team concludes they did too much planning up-front and not enough later, but I think we had too little forethought and too much ad hoc cram-it-in work later.

In any event, Matt seems to have at least one very good thing going for him: his team is committed to improving themselves.  I hate to admit it, but we've reverted to the neverending ground-and-pound routine we've been maintaining for almost four years now.  We calling it "scrum," but I know it's not scrum and it's not agile because these things give it away:

  • we rarely estimate anything, we just beat on features and bugs until they're completed;
  • we almost always miss deadlines, which are fairly arbitrary anyway due to the lack of estimations;
  • we don't have much "team spirit" - or perhaps I'm simply excluded from it.  Instead specific indivuals are recognized as the owners of various parts of the system, and it's a bit of a political battle to be involved outside of your sandbox;
  • we generally have four or five projects ongoing, with team focus split between several of them at any given time;
  • we don't iterate or increment, we go dark for weeks, develop like madmen, and throw it over the wall to QA when we're done;
  • we don't retrospect projects anymore, we move immediately to the next project without discussing what worked or didn't work so things get better over time.

I find it odd that we would shun the beneficial aspects of scrum and agile - the transparency of our work, clarity of tasks, the focus on communication, the postponement of details, the sharing of labor, the confidence of cycles, the leverage of teamwork, the push to improve the team - while at the same time embracing a commitment to work full throttle to meet a deadline.

Well, good luck with it Matt, and keeps those posts coming - seems to me like y'all are off to a good start.