8 Responses

  1. bateleur
    bateleur June 23, 2009 at 4:49 pm |

    If I were to use that methodology I’d want to add another action:

    * Declare a task to take irreducibly longer than 30 minutes and schedule a slot in which it can be performed.

    This is pretty much essential for some programming tasks. Although perhaps people with a better memory than me might be able to split any task between multiple slots without dividing it into conceptually distinct parts, I simply can’t do it.

    Reply
    1. undying-admin
      undying-admin June 23, 2009 at 5:04 pm |

      Mm — for me the 30 minutes would have to exclude any required get-back-up-to-speed time, otherwise I’d never accomplish any of the complex tasks 😉

      Reply
  2. mrlloyd
    mrlloyd June 23, 2009 at 7:47 pm |

    He has, in essence invented another version of agile development, and one which looks quite well suited to the solo programmer. He’s got an iteration where the length is defined by the outcome, not the time spent which got him into trouble. But he has got simple granular requirements, a clear prioritisation mechanism and so on. He’s also got a nice way of recording his progress, and the ‘list getting longer’ and ‘negative progress’ phenomenons are both accepted in most agile methodologies. (They happen on all projects, but until you accept and manage the problem it’s, well, a problem)

    The interesting thing is where he hits the wall. In a traditional agile process he’d have reached the end of that week and said ‘didn’t get task x done, it was way more work than I thought.’ Then you’d say ‘given that its way more work – is it still worth doing?’. This is why having your iterations bound by time rather than whether the work is done is a good thing – it makes you assess whether the cost/benefit of a given task has moved as you learn more about it.

    Reply
    1. undying-admin
      undying-admin June 24, 2009 at 7:52 am |

      Interesting, thanks! I’d previously wondered what agile devpt might mean for a solo dev.

      Reply
  3. mrlloyd
    mrlloyd June 24, 2009 at 5:32 pm |

    I’d say the most useful bits for the solo developer would be writing requirements as user stories, and applying a ruthless business value driven prioritisation.

    Things like test driven development are going to be a matter of personal choice, but the focus on having releasable product as soon as possible could be very handy for the one man business.

    See

    http://www.amazon.com/User-Stories-Applied-Development-Addison-Wesley/dp/0321205685

    and

    http://www.amazon.com/Agile-Estimating-Planning-Robert-Martin/dp/0131479415

    for more.

    Reply
    1. undying-admin
      undying-admin June 25, 2009 at 9:06 am |

      Ah, ta!

      Reply
  4. dr_bob
    dr_bob June 26, 2009 at 10:02 am |

    I reckon I need one of these plans for scientists. Exploring ideas is fun. Writing them up (which necessitates a story to tell, and thus extra bits beyond what I’ve done) is deadly dull. And keeps me out of the lab where new shiny projects are bursting to be started.

    I’m a terrible finisher. Which is an issue.

    Reply
    1. undying-admin
      undying-admin June 26, 2009 at 11:16 am |

      That seems to be the pattern with quite a lot of scientists of my acquaintance. Which either says something about the kind of people who become scientists, or about the kind of people with whom I become acquainted. Or both.

      Reply

Leave a Reply