Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options
 
PerlMonks  

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

by talexb (Canon)
on Dec 11, 2010 at 16:09 UTC ( #876604=note: print w/ replies, xml ) Need Help??


in reply to Nobody Expects the Agile Imposition (Part IV): Teamwork

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!

Alex / talexb / Toronto

"Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds


Comment on Re: Nobody Expects the Agile Imposition (Part IV): Teamwork
Re^2: Nobody Expects the Agile Imposition (Part IV): Teamwork
by eyepopslikeamosquito (Canon) on Jul 23, 2011 at 04:40 UTC

    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.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://876604]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others studying the Monastery: (12)
As of 2014-09-18 18:28 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (120 votes), past polls