LiveCode and SCRUM tools

[Richard Gaskin]

Mark Wieder wrote:

> Pete-
>
> Saturday, January 4, 2014, 10:07:39 PM, you wrote:
>
>> I guess it's a different world these days.  The thought of trying to assess
>> progress on a daily basis seems like a major case of micro management to
>> me.  No matter what the reporting period is, if someone isn't good at
>> estimating their progress, the project slips. Splitting a project into such
>> small tasks that they can be measured on a daily basis seems practically
>> impossible.  Plus, back to the critical path issue, if a sprint or whatever
>> you want to call it takes twice as long as estimated but still doesn't
>> affect the overall project end date, so what?
>
> Here's a big part of what makes that work for us: if you have a
> backlog of 200 points and your team is working at a velocity of 20
> points per week, you've got ten weeks of work ahead of you. If a given
> story can't be done, it goes back into the backlog and you know
> there's going to be some extra time needed in addition to those ten.
> The key is to get good at estimating the time needed for the stories
> themselves, and that's *much* easier than estimating the size of the
> whole project.

Both sides of this have merit, since estimating specific tasks is easier 
than estimating the whole, but on the flipside we rarely if ever attempt 
to estimate the whole anyway; any useful estimate has already gone 
through some process of identifying individual elements of the work and 
accounting for them as separate units, with the estimate for the whole 
being the sum of those parts.

The challenges with any estimation effort are the same as McConnell 
describes, and all the way back to Brooks, and on many fundamental 
levels haven't changed much over the decades since Brooks outlined them 
in "The Mythical Man Month".

Agile methods can help mitigate such risks, but not magically.  Any 
effort to break a work down to improve estimating is itself a form of 
work, and carries a certain overhead of its own.

The key, and indeed the focus of so much PM literature over the decades, 
is balancing the benefits of that overhead with its costs.

The cost-benefit of agile methods is generally not in question, but as 
with any process it's helpful to remain mindful of the trade-offs, and 
remain willing, as Geoff's team has, to take liberties when tailoring 
other people's processes for your own team.

--
  Richard Gaskin
  Fourth World
  LiveCode training and consulting: http://www.fourthworld.com
  Webzine for LiveCode developers: http://www.LiveCodeJournal.com
  Follow me on Twitter:  http://twitter.com/FourthWorldSys