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

Re: [XP] New practice: Slack

Expand Messages
  • Paul Beckford
    ... I think we are saying the same thing. My general point then, is depending on the teams relationship with their customer, that the customer can/should be
    Message 1 of 110 , Jan 2, 2006
      Ron Jeffries wrote:

      >On Monday, January 2, 2006, at 12:25:25 PM, Paul Beckford wrote:
      >
      >
      >
      >>I've been following this thread for a while, and I feel like the person
      >>asking the dumb question. I spoke it over with a colleague and we both
      >>came to the same conclusion. Why would we want to predict the outcome of
      >>an iteration/sprint?
      >>
      >>
      >
      >Because the fundamental business problem is to invest the
      >organization's time and money effectively. In order to do that, the
      >business needs to know, with rough accuracy early on, and much
      >tighter accuracy as time goes on, what they'll get in return for how
      >much spending.
      >
      >This is not optional. It's what a successful business has to do:
      >spend its money wisely, to get the best results for the least
      >expenditure.
      >
      >
      >
      >>My understanding of "empirical process control" is that we accept that
      >>the (open-loop) outcome is inherently unpredictable. Accepting this and
      >>communicating the fact to our customer gives us greater control over a
      >>process that is inherently complex, chaotic and unpredictable.
      >>
      >>
      >
      >I'd suggest googling "empirical process control" and reviewing,
      >amont others, the first article that shows up, namely
      >http://www.agileadvice.com/archives/2005/11/agile_work_uses_1.html .
      >
      >The notion of empirical process control is that we use results in
      >cycle N to improve the process in cycle N+1. It really doesn't
      >address overall predictability at all.
      >
      >Further, though it is complex, the process of developing software is
      >far from inherently chaotic and unpredictable. If the project in
      >hand is broken down into small functional bits, and the team works
      >on them in small batches, it turns out that most of the bits get
      >done at approximately the same rate. This rate is trivially easy to
      >measure, and so long as the rate is reasonably stable, it is quite
      >easy to project how much will be done by any given date.
      >
      >In short, it's not impossible to predict the outcome of a software
      >project. Done right, it's almost easy.
      >
      >
      >
      >>In the discussion group on XPE2E Alistair Cockburn makes the same point.
      >>We can tell our customers what we expect to achieve in an iteration
      >>based on past velocity. We can also promise to do the things that are
      >>most important to our customer first, but we cannot/should not commit to
      >>delivering a precise quota of work, as we have no way of accurately
      >>predicting the future.
      >>
      >>
      >
      >I agree that we cannot commit honestly to completing exactly X
      >amount of work, no more and no less. It should be clear, though,
      >that we can estimate approximately how much we can do, and that we
      >can commit up to any desired probability less than one to some
      >subset of that.
      >
      >There might be 10 stories on the table for the iteration. We think
      >we have a 70 percent chance of getting them all done. What's the
      >chance of getting 8 done? Probably around 80 percent? What are the
      >chances of getting half of them done? 90 or 95? Can we commit to one
      >story with 99 percent confidence? I'd think so.
      >
      >"Commitment" does not mean "prediction with certainty". Commitment
      >is the act of binding ourselves strongly to a course of action. When
      >we use our credit card, we commit to pay back the money. If we lose
      >our job or go bankrupt, we may break that commitment. We should feel
      >bad about it, but we should not imagine that something impossible
      >has happened.
      >
      >Suppose a team commits to complete N stories. That means they will
      >do everything within their power to get those stories done, and that
      >they are damn sure they can do it if no one gets hit by a truck and
      >the joint isn't flooded.
      >
      >
      >
      >>Unlike the proponents of CMM we accept that we have no way of
      >>removing uncertainty, our only claim is that we have a means of
      >>managing/controlling it.
      >>
      >>
      >
      >If we measure a statistical process, we can predict things about it.
      >If we have a decent random number generator and use it to produce
      >random numbers between 0 and 10, perhaps 20 per iteration, we can't
      >say exactly what the total will be in any iteration. But we know
      >fairly accurately what that total will be ... far more accurately
      >than the naive "well, it might be 0 or it might be 200" would
      >suggest. And over the course of ten iterations, we can be really
      >sure that we'll be really close to a total of 1000.
      >
      >The business people can use that information. They can consider, if
      >they'll get about a thousand things done, whether to spend the
      >dollars it takes to get them.
      >
      >Our job is to cause our team to be a good enough random number
      >generator to enable the business people to make those decisions.
      >
      >See the remarks on "Development is a Machine", in
      >http://www.xprogramming.com/xpmag/jatMakingTheDate.htm .
      >
      >
      >
      >>Have I missed the point?
      >>
      >>
      >
      >I'm not sure ... what do you think now?
      >
      >
      I think we are saying the same thing.

      My general point then, is depending on the teams relationship with their
      customer, that the customer can/should be included in the process of
      managing uncertainty (risk). I use the term "customer" and "mangement"
      interchangeably as the distinction between these roles vary from one
      organisation to the next.

      Infact I would go further and say that given the right information, that
      risk management is ultimately a customer responsibility. So using
      probability, then over time a customer will be able to determine the
      acurracy of the predictions (estimates) made by the team. The
      probability distribution of predictions vs actuals represents a
      characteristic of the team as machine. Using this information the
      customer/management should be able to predict for example how many
      iterations are required to have a 99% probability of achieving a
      specific outcome.

      If the spread (standard deviation) in the probability distribution is
      wide, then to achieve a 99% probability will require a lot of redundancy
      and possible waste as you point out. The customer/management then as a
      choice to change teams, or to request improvements within the current
      team. Through feedback the team and the customer can work
      collaboratively to improve accuracy (e.g less interruptions for the
      team, clear project focus, more domain expert time, the right balance of
      experience/skill in the team etc). Ultimately if the customer looses
      confidence in the team, or in the project then the option to cancel
      exists (some projects just have a higher degree of uncertainty (risk)
      then others).

      So my point is why hide this information? Why not be open about how well
      the team as a machine is performing? This allows an open and honest
      discussion on how to improve. After all the root cause may not be down
      to the development team. They could be problems in the organisation or
      with the project concept, or with the customer team etc.

      The idea of Slack just seems meaningless in this context. If certainty
      is important then customers will add slack themselves.

      I accept that in most organisations the degree of trust between the
      customer and the development team is not sufficient to do as I suggest.
      But I see that as a different issue. The issue in such circumstances is
      how do I increase the level of trust with my customer so that I can tell
      him the truth. Now that is a whole different ball game.

      Paul.

      >Ron Jeffries
      >www.XProgramming.com
      >Know what I pray for? The strength to change what I can, the inability to
      >accept what I can't and the incapacity to tell the difference. --Calvin and Hobbes
      >
      >
      >To Post a message, send it to: extremeprogramming@...
      >
      >To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
      >
      >ad-free courtesy of objectmentor.com
      >Yahoo! Groups Links
      >
      >
      >
      >
      >
      >
      >
      >
      >
    • Paul Beckford
      ... Hi Victor, I totally agree. I am a European too (I live and work in the UK), and I ve also worked in the States, and there is a cultural difference (by and
      Message 110 of 110 , Feb 12, 2006
        Victor wrote:

        > I think this is a serious social
        >issue that needs to be confronted by society as a whole at the educational
        >level. Honesty can be tough to maintain in an environment that values
        >denial and unrealistic expectations, but in final account it's the best
        >policy.
        >
        >Victor
        >
        >
        Hi Victor,

        I totally agree. I am a European too (I live and work in the UK), and
        I've also worked in the States, and there is a cultural difference (by
        and large I find both the UK and the US very similiar though). I think
        it has something to do with the perception of science in the west and
        the role of the scientific expert. Earlier in this thread (way back)
        someone made a similar point about Doctors in the west not being able to
        say that they don't know, and presumeably experiencing emotions of guilt
        when they truly do not know.

        In software I think it is about organisational culture, and I have
        experienced cultural change by simply telling people I do not know. At
        first they are shocked, but once you encourage them to take the second
        person perspective (seeing things from your point of view), they quickly
        realise that this is the only honest answer and they respect you for it.

        With regards to the long term, many people in the west no longer trust
        Doctors and are increasingly looking to "alternative medicine". In
        China this seems to be less of an issue, as Chinese doctors are more
        willing to use approaches that aren't strictly "scientific". Maybe this
        is a tacit admission that as Doctors they do not always know the
        precise casual basis for illness and maybe as a consequence of this
        tacit admission people in China tend to trust them more.

        Just a thought.

        Paul.

        >=========================================================
        >----- Original Message -----
        >From: "Kent Beck" <kentb@...>
        >To: <extremeprogramming@yahoogroups.com>
        >Sent: Wednesday, February 08, 2006 1:48 PM
        >Subject: RE: Cultural difference was ->(Re: [XP] Re: New practice: Slack)
        >
        >
        >
        >
        >>David,
        >>
        >>The European cultures I have worked in do seem to be willing to make slack
        >>
        >>
        >a
        >
        >
        >>more visible part of the rhythms of work. Whether it is frequent espresso
        >>breaks or one-contiguous-month vacations in the summer, there seems to be
        >>more of a understanding that there is more to life than work and that work
        >>goes better when we acknowledge that. I have also seen significant erosion
        >>of this understanding in recent years, which makes paying attention to the
        >>value of slack increasingly important.
        >>
        >>As far as trust and promises are concern, if I want my children to trust
        >>
        >>
        >me,
        >
        >
        >>I will say, "I will be home at 8:30" and sometimes be early instead of
        >>saying, "I will be home at 8:00" and often being late. Whether I have a
        >>
        >>
        >good
        >
        >
        >>excuse ("traffic, you know") doesn't matter to a kid near as much as
        >>
        >>
        >knowing
        >
        >
        >>whether they can count on me.
        >>
        >>That said, I still make too many professional commitments based on what I
        >>think people want to hear and end up missing them. However, even when I
        >>
        >>
        >make
        >
        >
        >>promises I secretly think I can't meet, the big issue for me is time
        >>management. If I improved my ability to focus and prioritize I would be
        >>
        >>
        >able
        >
        >
        >>to make and meet promises with much less slack than I currently use.
        >>
        >>Sincerely yours,
        >>
        >>Kent Beck
        >>Three Rivers Institute
        >>
        >>
        >>
        >>>-----Original Message-----
        >>>From: extremeprogramming@yahoogroups.com
        >>>[mailto:extremeprogramming@yahoogroups.com] On Behalf Of David H.
        >>>Sent: Tuesday, February 07, 2006 5:45 AM
        >>>To: extremeprogramming@yahoogroups.com
        >>>Subject: Cultural difference was ->(Re: [XP] Re: New practice: Slack)
        >>>
        >>>Kent Beck wrote:
        >>>
        >>>
        >>>>David,
        >>>>
        >>>>
        >>>>
        >>>Hello Kent.
        >>>
        >>>First of all please accept my apologies for answering so belatedly.
        >>>
        >>>
        >>>
        >>>>I think software developers and managers have always
        >>>>
        >>>>
        >>>included lots of slack
        >>>
        >>>
        >>>>in their schedules. We just didn't talk about it. The
        >>>>
        >>>>
        >>>client or boss was
        >>>
        >>>
        >>>>"supposed" to think that we were working as hard as we
        >>>>
        >>>>
        >>>could 150% of the
        >>>
        >>>
        >>>>time, taking only Sunday mornings off. What happens if we
        >>>>
        >>>>
        >>>admit we are
        >>>
        >>>
        >>>>human? We take coffee breaks and time to think and look out
        >>>>
        >>>>
        >>>the window at
        >>>
        >>>
        >>>>the weather?
        >>>>
        >>>>
        >>>>
        >>>That is something, I as European, cannot quite understand.
        >>>Yes, there is peer
        >>>pressure in our countries as well, but the chances that you
        >>>get fired because
        >>>you are not working "hard enough" are pretty slim. This is
        >>>basically caused
        >>>due to our employment laws which are usually in favour of the
        >>>employee and not
        >>>the employer. As such I do not have to worry too much about
        >>>my financial
        >>>freedom or my career as long as I do pay attention to what I am doing.
        >>>
        >>>I wonder how that is influenced by the fact that I recall,
        >>>for my visits in
        >>>the USA, that this is not the case in most companies over
        >>>there. Everyone
        >>>seems very concerned how their doing is perceived by the
        >>>bosses, always aware
        >>>that they _could_ be out of work by tomorrow.
        >>>
        >>>
        >>><snip>
        >>>
        >>>
        >>>
        >>>
        >>>>What I have found for myself is that when I am open with my
        >>>>
        >>>>
        >>>customers about
        >>>
        >>>
        >>>>the process I use to make promises I feel exposed. I have
        >>>>
        >>>>
        >>>no information in
        >>>
        >>>
        >>>>reserve with which to protect myself if I break my promise.
        >>>>
        >>>>
        >>>However, when I
        >>>
        >>>
        >>>>make transparent promises, I focus harder and don't waste
        >>>>
        >>>>
        >>>time keeping track
        >>>
        >>>
        >>>>of what I am holding back, so I get more done. It works for
        >>>>
        >>>>
        >>>me, even though
        >>>
        >>>
        >>>>it doesn't always feel good yet.
        >>>>
        >>>>
        >>>>
        >>>Is this not also a matter of trust. Making promises that are
        >>>not transparent
        >>>or based on assumptions will most likely cause a more than
        >>>negative reaction
        >>>in the one you promised them too when you cannot fulfill
        >>>them. I like to think
        >>>of this like a parent promising something to their child.
        >>>When I am honest
        >>>about the possibility of failure, the child usually will
        >>>accept that when I
        >>>cannot fulfill my promise. Very similar to saying:
        >>>
        >>>I will be home by 8pm versus I will try to be home at 8pm,
        >>>but I might not be
        >>>able to be here, because the traffic will be bad tonight.
        >>>
        >>>I know that most customers will expect you to say "I will be
        >>>home by 8pm", so
        >>>how do you get out of that dilemma?
        >>>
        >>>
        >>
        >>To Post a message, send it to: extremeprogramming@...
        >>
        >>To Unsubscribe, send a blank message to:
        >>
        >>
        >extremeprogramming-unsubscribe@...
        >
        >
        >>ad-free courtesy of objectmentor.com
        >>Yahoo! Groups Links
        >>
        >>
        >>
        >>
        >>
        >>
        >>
        >>
        >
        >
        >
        >To Post a message, send it to: extremeprogramming@...
        >
        >To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
        >
        >ad-free courtesy of objectmentor.com
        >Yahoo! Groups Links
        >
        >
        >
        >
        >
        >
        >
        >
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.