Loading ...
Sorry, an error occurred while loading the content.

Re: Part-timers and Projects

Expand Messages
  • David A Barrett
    I think the part-timer issues are a probably a bit of a red herring. To me, a part-timer is a full member of the team who only has a limited number of hours
    Message 1 of 2 , Jun 2, 2004
    View Source
    • 0 Attachment
      I think the part-timer issues are a probably a bit of a red herring. To
      me, a part-timer is a full member of the team who only has a limited number
      of hours to devote to the sprint. We're really all part-timers in that
      respect since we're only going to spend 40 hours a week doing sprint work.
      To me, the key differentiator is that the part-timer is still a pig, and
      not simply a resource devoted to a particular aspect of the sprint. We
      talked earlier about our web developer, who we usually need for some
      aspects of our scrum work but who wouldn't be used for anything else and
      wouldn't be expected to help do documentation for some other sprint backlog
      item (or whatever) if the sprint was falling behind. We also have users
      doing UAT, communications people vetting web content, business department
      SME's and the like that we need to use from time to time. We just treat
      them like a resource and put a real team member in charge of them who
      reports back to the team in the scrums.

      As to "Projects". Fixed Cost projects are obviously a thorny issue, which
      Ken has addressed to a least some degree. For all the others there is more
      latitude. Scrum puts aside the fallacy that you can sit down at the
      beginning of a project and accurately map out all of the detailed
      specifications for the final product. This leaves the question of, "How do
      you know when you are done?". When you think about it, Scrum or not,
      this isn't really something you can answer at the beginning of a project
      because things will change during the course of the project that will
      change the requirements and, therefore, the meaning of "done".

      A better question is how to deal with outside time constraints. I think
      our standard planning method works great for that. We do enough evaluation
      of the Product Backlog items to assign a rough size to them (tiny, small,
      medium and big). From there, you could probably ballpark how many sprints
      it would take to complete all of the items in the PB. Of course, stuff
      will get added, changed and removed in the PB over time so you'll need to
      keep reviewing the projected number of sprints required to complete a
      certain amount of functionality and compare it to the outside time
      constraints. We find that we tend to leave the "Big" size items as bigger
      question marks than the other PB items ("Big" is more than 5 days, but
      could be 20, 30 or more days). You would have to put in a little more up
      front evaluation, perhaps breaking down the Big items into several smaller
      items in order to reduce the uncertainty contained there.

      "Can we do it on time?" That's probably the most critical question at the
      beginning, and I be willing to bet that most experienced systems analysts
      can get a reasonably accurate feel for that in a surprisingly short period
      of time. Obviously, the bigger the project, the harder it is to do this,
      but I doubt that detailed gant charts are going to give a significantly
      better answer.

      Remember "Fuzzy Logic"? There's a little bit of that here. Initial
      "requirements" are usually more like a feature list. Which features are
      really necessary for delivery before the deadline? It can be hard to say,
      because an approach taken with some other features may make a particular
      feature more or less necessary. Regardless, at the very beginning it's
      easier and less critical to find the right something to start on. Roll up
      your sleeves and get started, and as the users see what you've done they'll
      add input and start shifting priorities which will shape the following
      sprints.

      To someone from a traditional PM approach this must sound very
      unsatisfying. How do you know it will be done on time? How do you budget?
      In my opinion, for a software development project of any size, you're just
      kidding yourself if you think you know the answers to these questions any
      better with a waterfall approach. The problem with any estimates at the
      beginning is that you are always working with partial information, the rest
      of that data is going to be created as the project moves along. Scrum
      acknowledges this up front, makes it visible and pulls the customer into
      the process which deals with this uncertainty.


      Dave Barrett
    • William R. Nichols
      ... Actually, we are all part timers in that we all have just 15 to 20 hours of actual time per week directly on work tasks! That is part of the difficulty
      Message 2 of 2 , Jun 2, 2004
      View Source
      • 0 Attachment
        David A Barrett wrote:

        >
        >
        >
        >
        > I think the part-timer issues are a probably a bit of a red herring. To
        > me, a part-timer is a full member of the team who only has a limited
        > number
        > of hours to devote to the sprint. We're really all part-timers in that
        > respect since we're only going to spend 40 hours a week doing sprint work.
        > To me, the key differentiator is that the part-timer is still a pig, and
        > not simply a resource devoted to a particular aspect of the sprint. We
        > talked earlier about our web developer, who we usually need for some
        > aspects of our scrum work but who wouldn't be used for anything else and
        > wouldn't be expected to help do documentation for some other sprint
        > backlog
        > item (or whatever) if the sprint was falling behind. We also have users
        > doing UAT, communications people vetting web content, business department
        > SME's and the like that we need to use from time to time. We just treat
        > them like a resource and put a real team member in charge of them who
        > reports back to the team in the scrums.
        >
        >
        Actually, we are all part timers in that we all have just 15 to 20 hours
        of actual time per week directly on work tasks! That is part of the
        difficulty with including someone who has only half nominal time to
        apply. The hour per week in scrum meetings plus the one day monthly
        planning session are overhead that are doubled for the unfortunate who
        has been applied to two projects. Switching between tasks is a bother,
        opening different documents, answering two sets of mail, switching
        trains of thought, possibly changing the work environment. You end up
        with about 0.8 persons applied to two projects. Another problem is
        conflicting project needs. Unless there is a strong spirt of cooperation
        between the projects, one or the other will usually dominate the part
        timer's time. Then the smaller number of applied hours make for a
        smaller sample size and progress becomes more difficult to evaluate.

        I recommend against part timers where possible, but given the reality,
        strictly limiting work scope and carefully monitoring progress makes the
        best of the situation. I've had most success where the part timer is
        either a consultant or applies full time for short bursts.

        Bill Nichols
      Your message has been successfully submitted and would be delivered to recipients shortly.