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

Re: [XP] Agility v Speed

Expand Messages
  • M. Manca
    ... Ron, I am convinced of this, in previous posts I said that velocity has no meaning, delivery business value has meaning. Sometimes all the planned stories
    Message 1 of 63 , Mar 27 7:10 AM
      Il 27/03/2012 14:51, RonJeffries ha scritto:
      > 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.
      Ron, I am convinced of this, in previous posts I said that velocity has
      no meaning, delivery business value has meaning. Sometimes all the
      planned stories have to be released simply because the product needs
      them, so in this case also an agile team would finish with some delay.
      > > 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 partially agree but I have a question. If in 8 sprints (1 sprint = 1
      week) you completed 80 stories on 100 (so there are 20 stories on the
      backlog) meaning 320 story points on 410 total story points how do you
      rough estimate how much rough time will you need to complete the last 20
      stories? Personally I estimate it using stories cycle time over points
      (using worst, best and median cycle time) trying to obtain a median
      story point time (of course it is just a rough estimate) and
      prudentially I check to prioritize the 20 last stories using business
      value as order index.
      > >
      > > 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.
      I mean "my customer doesn't agree to accept this possibility" :-).
      > 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"?
      Ron, when I work in a fixed scope/fixed money contract I need to make
      estimates by myself to don't overrun, I can't wait to find only agile
      customers and I can't teach them what they miss doing business in an old
      way simply because they don't want to here these arguments.
      Sometimes goes better, some other no but I am already in the business so
      I didn't so much wrong. Traditional customers asking for fixed scope
      contracts think to be in business by a lot of time and they think to
      know what they need. Every time they ask to have "a little more" I ask
      to have a "little more time and a little more money" this is the true
      story. In my opinons these contracts don't produce the best products
      simply because both parties pull the blanket from opposite sides when
      instead both parties would collaborate more to make a better blanket.

      When I work for agile companies (a lot of times they just think to be
      agile but they aren't) they pay attention to our estimates and honestly
      the team work better and is more productive.
      > 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.
      I am in the business by half time then you but anyway is a long time; I
      don't think that it is impossible to increase a team productivity as I
      think that there are teams more productive then others, I agree that
      high productivity is not the main goal but developing the same product
      with the same or better quality in short time is a measure of how good
      is a team.
      > 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]

      [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 3:39 PM
        --- 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...
      Your message has been successfully submitted and would be delivered to recipients shortly.