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

Re: [XP] Task Underestimation and Overestimation

Expand Messages
  • George Dinwiddie
    Hi, Curtis, ... For my part, velocity & yesterday s weather are just as useful. I just get that value for a lot less effort by counting stories than by
    Message 1 of 135 , Feb 3 9:43 AM
    • 0 Attachment
      Hi, Curtis,

      Curtis Cooley wrote:
      > I've really enjoyed this discussion. These kinds of questions don't seem to
      > get asked enough anymore. I especially like how it drives new and
      > interesting information from the "old guard" like Ron suggesting velocity
      > and "yesterday's weather" isn't as useful as we once thought it was.

      For my part, velocity & "yesterday's weather" are just as useful. I
      just get that value for a lot less effort by counting stories than by
      estimating them. I increase the value of velocity & "yesterday's
      weather" by making stories smaller (which also gives me other benefits)
      rather than by trying to estimate more precisely.

      > One aspect of Chris' question that I've not seen addressed or answered is
      > "how do I know my developers are working hard enough?" It seems task
      > estimates and other micro accounting methods are designed solely for the
      > business to make sure it's getting maximum effort from the development team.
      > Playing a little devils advocate,
      > All these touchy feely fit all I can in the five pound bag and see what gets
      > done is all nice, but how do I know what gets in the bag is the absolute
      > most the team can actually do?
      > Disclaimer: I don't believe that, but I see it. It sounds like Chris is
      > under this kind of pressure and thus has wandered down the micro
      > managing maximize efficiency path.

      I can't answer that question, directly. Personally, I'm less concerned
      with efficiency than effectiveness. I don't strive for 100% utilization
      of developers.

      Maybe the best answer is to suggest that the micro-manager ask his
      network administrator what happens when it reaches 100% utilization.

      - George

      * George Dinwiddie * http://blog.gdinwiddie.com
      Software Development http://www.idiacomputing.com
      Consultant and Coach http://www.agilemaryland.org
    • Andrew Wall
      Not on a breadboard, but a previous boss of mine developed RF designs (approx 100-400MHz) in a christmas tree fashion over a copper board, which meant the
      Message 135 of 135 , Feb 27 10:43 AM
      • 0 Attachment
        Not on a breadboard, but a previous boss of mine developed RF designs
        (approx 100-400MHz) in a 'christmas tree' fashion over a copper board, which
        meant the circuit designs were quite malleable. But, I agree, some RF
        technologies in the GHz and above range, I'm guessing, need 'final' hardware
        to be built to see if they work, which then gets thrown away once the next
        version has been tested, and so on.

        When I was designing analogue and digital circuits, I often wished for all
        components to be variable so I could tweak the values while the circuit was
        'running' and when it was right, write down all the numbers, rather than
        powering down, replacing one or more components, powering up, attaching
        probes again etc.

        Andrew Wall (aka quamrana)
        Still not doing XP

        "CHRIS BROWN" <knightstreet@...> wrote in message
        No RF (Radio) design that I know of can be developed on a breadboard.
        Technology has advanced a long way and maybe a spike would be carried out on
        a breadbord for a concept but some circuits just will not work on a

        From: George Dinwiddie <lists@...>
        To: extremeprogramming@yahoogroups.com
        Sent: Fri, February 5, 2010 7:59:19 PM
        Subject: Re: [XP] Task Underestimation and Overestimation

        Ron Jeffries wrote:
        > Hello, CHRIS. On Friday, February 5, 2010, at 9:36:15 AM, you
        > wrote:
        >> What if you are designing hardware along with software as with
        >> many consumer products in the market? You can't design the
        >> hardware in an agile method as well, you can apply some of the
        >> practices but ultimately the circuit board has to be specified and
        >> created based on a set specification which is detailed early on in
        >> a project and in that way you have to 'look ahead'. The software
        >> that works in the hardware (the firmware) can be delivered in an
        >> agile manner but the hardware remains fixed thus constraining the
        >> software by the hardwares limitations.
        > That's one way. It's no longer the only way.

        Actually, it never was. When I was doing hardware development, we used
        breadboards to develop hardware iteratively. Even PC boards were
        designed iteratively, as the first layout was unlikely to be shipped.

        - George

        ------------ --------- --------- --------- --------- --------- -
        * George Dinwiddie * http://blog. gdinwiddie. com
        Software Development http://www.idiacomp uting.com
        Consultant and Coach http://www.agilemar yland.org
        ------------ --------- --------- --------- --------- --------- -

        The new Internet Explorer´┐Ż 8 - Faster, safer, easier. Optimized for Yahoo!
        Get it Now for Free! at http://downloads.yahoo.com/ca/internetexplorer/

        [Non-text portions of this message have been removed]
      Your message has been successfully submitted and would be delivered to recipients shortly.