Re: Nobody Expects the Agile Imposition (Part IV): Teamwork

[talexb]

This whole investigation into agile programming is fascinating, and having been exposed to it at my current job, I'm beginning to wonder about what the overarching goal is. Certainly, one of the goals is to make sure the required productivity objectives are met -- bugs are squashed, and features are implemented. But that happens in a normal development process. So how is agile different?

I think the answer is that it allows management one level above the teams to keep a very close eye on what's happening at the ground level. The problem, of course, is that reality intervenes, with its expected delays on the carefully planned schedule. A production emergency arises, a high level feature must be implemented right away; someone is sick -- and the carefully drawn out schedule gets re-written.

What I don't think is covered by the agile process is what happens when the developers are done their due diligence, and the software needs to be staged and then deployed. You might do a small fix (less than a day of development) that needs days of testing. If the developer had to be on hand for the testing, whose budget does that come out of?

However, I agree with some of the agile ideas -- I think the daily stand-up meeting (where everyone on the team talks about their first three priorities of the day, and any possible roadblocks) is an excellent idea. I also think it's important that team members keep the team lead informed throughout the day, if their rate of progress changes dramatically (either "I got this done early" or "I'm having a problem with Vince again").

But I'm not so sure that making up estimates for each individual task is such a great idea, since estimating how long writing a piece of code is tough to do. Certainly, we can guess it will take 4-8 hours, but from a scientific point of view, that's hilariously imprecise (6 +/- 2 is an uncertainty of 33%).

I think I have a Meditation brewing. Great post, thanks so much!

[eyepopslikeamosquito]

I also think it's important that team members keep the team lead informed throughout the day

Agreed. However, that is not Scrum, as prescribed by the (recently updated) Official Scrum Guide: "Scrum recognizes no titles for Development Team members other than Developer". So, if you have a "team lead" title, you are not practicing Scrum.

I further noticed that the Scrum Update (July 2011) clarifies that "Development Teams do not commit to completing the work planned during a Sprint Planning Meeting" ... which agrees with my opinion, expressed (strongly) above in the "Team Commitment" section! :) Maybe our (certified) Scrum Master back then didn't know the Scrum rules as well as he claimed. However, after comparing to the official Scrum Guide of February 2010, my reading is that he was accurately applying the 2010 Scrum rules and that this July 2011 "clarification" is actually a rule change.