Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] Agile software for a nacent project



On 07/12/2012 09:52 PM, David Kramer wrote:
> On 07/12/2012 12:53 PM, Mark Woodward wrote:
>> I think "agile" development is probably the most abusive management
>> technique ever devised. Sure, aspects of it are good software
>> development processes, but the implementation is pretty exploitive, in
>> my opinion. Every "agile" environment I have seen works the engineers to
>> death. The "scrum" meetings are another form of micromanagement with the
>> added benefit of peer coercion.
>>
>> A few years back, a lot of people were excited, but today, I have yet to
>> meet anyone that doesn't think "agile" is a meat grinder. It burns out
>> good people and produces poor product quality.
> Mark, we've had had this conversation before, and you have met me, so I
> can safely say you're lying.
David, yea, we have met and that was some time ago. Yes we have had this 
conversation. Next time I express my opinion on this subject, I will say 
"except for one."


>   I've been working in Agile environments for
> years and I've never felt more empowered to say "no, we can't do that by
> then".
Then your experience is different than that of many of my colleagues.
>   I'm pretty sure the hundred-or-so people who show up to Agile
> New England and Agile Boston meetings every month would agree.  I'm
> sorry you had such a bad experience with what some idiots called Agile,
> but if you were feeling like a slave, then it probably was not Agile.
> Saying that you're "doing Agile"  when you're not is almost as common as
> really "being Agile"
As I have said many times, "Agile" is interesting in that it codifies 
many practices of old-time quick developers. The problem is that too 
often it is used as a tool increase work load. Unless you are careful, 
you overlook proper design because of increased time pressures. You get 
in the "sprint" death spiral where you don't have time to design, but 
you have time to iterate. You end up in a constant state of late with 
the "slot machine" mentality of hope you'll make it up in the next sprint.

>
> Normally I would say "Let's just agree to disagree", but I feel I have a
> bit more of experience in this particular area than you, and I wish you
> would stop trashing Agile when you've not actually done it.
That depends on how you define "experience." You may have had positive 
experience with "Agile," I have not. I have colleagues with whom I 
discussed the problems and had a lot of agreement. While I will respect 
your opinion, it is fundamentally different with my experience. You have 
your experience and no one is calling you a liar. I have mine, and I 
hope you have the good manners to do the same.

>
>> On 07/12/2012 12:16 PM, Doug wrote:
>>> Does an agile development process make sense for projects that are all
>>> volunteer based, with people who don't live in the same states or
>>> countries?  In my job, we use greenhopper, part of www.atlassian.com
>>> set of software.  There are morning scrum meetings, story sessions,
>>> sprint planning and sprint completions.  That makes sense when
>>> everyone drives to the same building.  For a volunteer based project,
>>> those regular meetings are not going to be held.
> - Geographically disparate team members is definitely a hindrance, but
> not a show stopper, if you can counter with the right technologies, and
> the time zone differences aren't too great.  Jira+Greenhopper is a great
> start.  You'll need a wiki for persistent knowledge management, but I
> assume if you have Greenhopper you already have Confluence, too.
>
> - All-volunteer workforce is not really a problem at all.  In fact it
> tends to be a bit less of a problem than some other practices, because
> Agile teams often become meritocracies where good work is rewarded more
> than seniority.  This is especially true if and when the team reaches
> the stage of being self-organizing (people volunteer to work on stories
> instead of being assigned them, and they do what's needed the most but
> also what they enjoy)
>
> Agile New England (which I'm on the Board of) has an event every year
> called Agile Games, which is a 3-day conference.  All volunteers working
> in their spare time.  But we have a backlog, we have weekly standups
> over the phone instead of daily standups, We have retrospectives to make
> sure we're doing things the best we can.
>
> There are concessions you have to make in that environment, though.
> We're not strictly following one flavor of Agile, but we are using a
> complimentary and comprehensive set of practices that are Agile to the
> best of our abilities; We communicate very frequently and freely, we
> focus more on solving problems than placing blame (shared ownership of
> the product), and we record the status of tasks so everyone knows where
> everyone else stands.  We don't have sprints, but we do have milestones
> that we associate with tasks and stories.
>
> The biggest challenge is going to be frequent *but focused*
> communication.  Lots of people need to interact in a way that
> effectively conveys the information to the right people in a timely
> manner without swamping people who don't need that information, ruining
> the S/N ratio.
>
> The way we do that in Agile New England (and in Agile Games) is to have
> *lots* of mailing lists.  There's one list for all volunteers, and one
> list for just the Board, then there's separate lists for each team:
> marketing, sponsors, speakers, IS, hotel, finance....  Separate channels
> means rapid communication with retained sanity.
>
>>> I can imagine a planning board being of use.  "Look, here,
>>> specifically is what we want done next."  That could be overkill
>>> however, with say a newsgroup, twiki and github being sufficient.
> Part of Agile practices is the balance of power, like the government
> used to have.  And you can't have balance of power without interactive
> planning.  So having the work all documented on the wiki is great, but
> the planning itself needs to involve all involved parties.  A wiki can
> sort of do that (as you do planning during a teleconference call,
> someone updates the wiki and everyone else can refresh at will.  I've
> come up with a specific table layouts in Foswiki that works well for us,
> using some of its very advanced form/table tools, and that works well
> for us.
>
> Sadly, tools that do this very well are pretty expensive.  You can do it
> in Greenhopper better than in a Wiki, but we don't have that option in ANE.
>
>>> If you do think some aspects of the agile process make sense, what
>>> software would you use?  I could pony up $20/month and use atlassian's
>>> hosted service.  I don't think I will have 10 people who want to code
>>> in a year, but one never knows.  If it does take off, then the costs
>>> jump.
> I personally would not use a service hosted on someone else's machine
> simply because I am a privacy nut and I've seen too many companies
> discontinue free services with no way to export your existing work.
> Everything we do is hosted on a virtual web host (HostGator, who I
> adore).  We don't have the ability to install Java, and that prevents us
> from using certain tools.  Most everything we do use is Perl or PHP based.
>
> There are free Agile planning tools out there.  We've found them
> insufficient for our fairly complex needs, but you might find them
> sufficient.  One of them is https://seenowdo.com/
>
>>> The project of course involves quaternions, thinking about making
>>> animation software using the multimedia Java platform known as
>>> processing (http://processing.org/) for web sites and android phones.
> Sounds cool!!
> _______________________________________________
> Discuss mailing list
> Discuss at blu.org
> http://lists.blu.org/mailman/listinfo/discuss





BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org