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

Re: [XP] New practice: Slack

Expand Messages
  • Ron Jeffries
    Hi Paul, On Tuesday, January 3, 2006, at 2:12:14 AM, Paul Beckford wrote, not ... Certainly Alistair is saying that burn down charts are good, and I agree,
    Message 1 of 110 , Jan 3, 2006
    • 0 Attachment
      Hi Paul,

      On Tuesday, January 3, 2006, at 2:12:14 AM, Paul Beckford wrote, not
      quite in this order:

      > I'm looking at this from a SCRUM perspective. As I understand it the
      > inherent risk to the "release" can safely be managed using a burn down
      > chart. No need for Slack.

      > Here is a link to an article that I think is saying the same thing:

      > http://alistair.cockburn.us/crystal/articles/evabc/earnedvalueandburncharts.htm

      Certainly Alistair is saying that burn down charts are good, and I
      agree, though I happen to prefer burn UP, since requirements tend to
      expand and contract.

      But I take Alistair's point to be that you have to burn something
      where you have a finite list of real deliverables. In software,
      burning lines of code wouldn't be useful because we don't know how
      many there are. Burning stories, features, backlog items can be
      valuable, /if/ we know how many there are until the release is done.

      I don't see that Alistair supports at all the issues of complexity,
      chaos, and general unpredictability that you've been talking about;
      I'd say that he is supporting the notion that results are
      predictable.

      I don't see him addressing at all the notion of Slack as describe in
      2e, nor of Slack as described in DeMarco.

      All that said, I do see and agree with your point that providing
      absolute commitments may be of limited value. Further comments
      below. We now return to the original order of your note.

      > I agree. I think this is the point I'm trying to make. Open loop (no
      > feedback from customer) we cannot predict. Software development is
      > chaotic, complex and unpredictable, hence the experience of the last
      > 20-30 years and all those failed waterfall projects. But closed loop
      > (with customer feedback) then predictablity increases greatly.

      I'm not sure how feedback from the customer is a necessary
      component. We have to know the magnitude of the work. As Alistair's
      example shows, the number of rooms packed may be sufficient to do a
      decent job. No customer feedback is present there as far as I can
      see.

      Now of course I want customer feedback ... and I want the customer
      to see progress. The reason is that the predictability shown by a
      burn chart or equivalent is quite high in my experience (though I
      take you to be saying it isn't} and if the customer doesn't like
      what it says, he can and will manage scope to get the best possible
      release by the date he wants.

      > So the question then is, how much feedback do you need? The smaller the
      > iteration size then the less the delta of error but the greater the
      > overhead. The larger the iteration size then the greater the delta and
      > the lower the overhead.

      Yes, iteration size is of some importance. However, if it takes N
      hours to plan 100 stories for a month, my best guess at how long
      it'll take to plan 25 for a week is N/4 hours. IOW, I don't think
      the overhead increases very fast down to iterations of the order of
      a week.

      > As I've understood it from following this thread (I do not have a copy
      > of XPE2E), Slack is about increasing the certainty of the outcome of a
      > single iteration (not a release). So why would you want to do this?

      From what I can tell from the discussion so far, no one else is
      quite sure what Kent meant, and he wishes he had put it differently.

      One reason why a team might want a kind of certainty would be if
      there was a lack of trust somewhere in the command chain. They might
      find it preferable to make and keep promises, rather than offer
      vague estimates and progress charts. If management wants promises,
      some people would argue that we should give them promises, and I can
      support that concern. Agile methods /can/ make promises in my
      experience, and do so rather nicely.

      Another reason for a kind of certainty might be that there are
      external events that need to be conditioned on the date and
      contents of a release. Perhaps we're planning a big rollout, with
      floats and blimps and such, and we need a list of the important
      features of the new product. Agile methods can make that kind of
      commitment in my experience, and do so rather nicely.

      > For the specific problem you describe I can see two alternative
      > solutions to Slack:

      > 1. Call the customer mid-iteration and tell him that we need about
      > another 25 stories, shall we just pull them off the (prioritised) backlog?
      > 2. Reduce the iteration size untill the team gets better at predictions
      > (which could take 3-4 iterations).

      These are both good things to do, and I prefer them. I'd note that
      they do not address either the Kent Beck notion of slack, nor the
      DeMarco version of Slack.

      Beck appears to be working for a firm commitment or promise of
      delivery. If we want that, option 1 won't help us much at all, and
      option 2 remains weak since there will always be variability.

      DeMarco is working to make space for creativity, and that notion
      has been extended here by Jim Shore and others to make space for
      necessary work behind the scenes, such as automation or perhaps
      refactoring. I don't see that either option helps us with that
      concern, though neither gets in the way.

      Working, I hope, toward mutual understanding, I remain, etc., etc.,
      yours truly,

      Ron Jeffries
      www.XProgramming.com
      If it is more than you need, it is waste. -- Andy Seidl
    • 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
      • 0 Attachment
        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.