LiveCode and SCRUM tools

Geoff Canyon gcanyon at gmail.com
Sun Jan 5 13:49:21 EST 2014


On Sun, Jan 5, 2014 at 1:07 AM, Peter Haworth <pete at lcsql.com> 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?
>
> But once again, I'm "old school" so if that works for people, that's all
> that matters.
>
> Sorry, I guess this is getting wildly [OT]
>

Maybe, but just in case: teams using scrum are likely doing web
development, e.g. in PHP, which is fairly high level, so think in terms of
LC -- there are very few handlers that should take more than a day to
write, so breaking up a project into one-person-day chunks should be not
just do-able, but necessary. And once you have a list of <1 day handlers to
write and developers let you know when they complete them, you have
progress tracking on a daily basis.

Standups aren't about tracking progress, they're about fostering and
enabling it. Developers report each day on what they've done, what they're
doing, and anything stopping them or that they need, and the scrum master's
job is to get them what they need, and remove obstacles.

Finally, the work is elastic, but the sprint isn't.  If your sprints are
two weeks, they're two weeks. If you misestimate you still close the sprint
on schedule with whatever *deliverable* functionality you can produce in
that time period, and start the next sprint fresh.



More information about the use-livecode mailing list