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

Re: [XP] Agility v Speed

Expand Messages
  • RonJeffries
    ... Planning is good. Velocity is not a very good way to plan. Of course, if your projects are all going swimmingly, you should keep doing what you re doing.
    Message 1 of 63 , Mar 27, 2012
      On Mar 27, 2012, at 8:00 AM, M. Manca wrote:

      > As I recognize and use agile methods I recognize also that a lot of
      > times in the embedded software applications it is difficult to finish
      > the software as is at delivery date because time elapsed or money is
      > finished. Surely we can't discover the problem on the last day so
      > planning help us to know the situation well before the delivery date.

      Planning is good. Velocity is not a very good way to plan.
      Of course, if your projects are all going swimmingly, you should keep doing what you're doing.

      > Also agile/XP teams involved in embedded projects run out of time and
      > budget (in my experience less then traditional teams) the advantage is
      > that the system is a part of the full product but the part is full
      > working and full tested so generally is more simple to predict how much
      > time we need to implement missing stories.

      Yes. The best way to do that is to look at your rate of producing actual stories. Not at your "velocity".
      >
      > I embrace the idea to develop a product with a fixed time and budget in
      > this way I will have something to sell at a known date so I will rise
      > some money and I will think about to complete my product with things
      > didn't fit in my fixed scope in the next release, when it is possible is
      > a very good idea but it isn't always possible.


      If by "isn't always possible" you mean "I don't always know how to do it", I agree.

      If you are doing fixed scope and fixed budget, you're on your own. I predict that you will generally fall short of "expectations", no matter how many large constants you multiply your "estimates" by.

      And have you ever noticed that they TELL you what your budget is and what your scope is, more often than they actually pay attention to your estimates? Have you ever noticed that they say "can't we have a little more", and "we need you to be a team player"?

      I've only been doing software for a half-century, so perhaps there is a way out of the iron triangle that I've neither discovered nor heard about. I can tell you this: working for higher productivity is not the way out.

      Ron Jeffries
      www.XProgramming.com
      There's no word for accountability in Finnish.
      Accountability is something that is left when responsibility has been subtracted.
      --Pasi Sahlberg



      [Non-text portions of this message have been removed]
    • JeffGrigg
      ... Would it be related to this... http://en.wikipedia.org/wiki/Agile_software_development#Measuring_agility
      Message 63 of 63 , Mar 29, 2012
        --- Steven Gordon <sgordonphd@...> wrote:
        > "Software Agility" is an attempt to define the software
        > qualities that entail "agility" and measure those qualities
        > with a small set of code metrics.

        Would it be related to this...
        http://en.wikipedia.org/wiki/Agile_software_development#Measuring_agility
      Your message has been successfully submitted and would be delivered to recipients shortly.