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

Re: Real data

Expand Messages
  • davenicolette
    ... Waterfall didn t cause blame-ducking behavior, and agile doesn t cure it. It s a question of organizational culture and values. ... The key words IMHO
    Message 1 of 218 , Feb 1, 2010
      --- In agile-usability@yahoogroups.com, William Pietri <william@...> wrote:
      > Great post, Dave.
      > On 02/01/2010 03:57 AM, davenicolette wrote:
      > > --- In agile-usability@yahoogroups.com, William Pietri<william@> wrote:
      > >
      > > ...
      > >
      > >
      > >> One of the big points of a number of software processes (and software
      > >> development contracting arrangements) isn't producing more value, higher
      > >> quality, or more efficiency. It's blame assignment. Or, possibly, the
      > >> ability to duck blame.
      "Waterfall" didn't cause blame-ducking behavior, and "agile" doesn't cure it. It's a question of organizational culture and values.
      > >
      > This is true, but my point in mentioning this is that if you have a
      > culture that's about blame, then Agile methods are a poor fit. Agile
      > doesn't cause or cure finger-pointing, but if you need to do a lot of
      > it, I don't think you can fully adopt the Agile approach, and therefore
      > the benefits may be limited.

      The key words IMHO are "fully" and "limited." Even in a culture of blame and even using a relatively heavyweight process, some agile techniques can be applied and some degree of improvement can be achieved.

      Someone (I think it was Michael Feathers, but I haven't browsed back through the thread to be sure) shared a story of working on a military project as a tester and spending a lot of time going back and forth with developers, fixing one bug and creating a new one in the process, over and over again. Had they adopted just a few agile techniques, they could have mitigated that problem. In particular, TDD would have helped, and getting the development and test groups into the same room instead of having hand-offs. It wouldn't be necessary to adopt agile "fully." It wouldn't be necessary to change the organizational culture; those are simply "mechanical" changes to the process. Those changes could have fit into whatever governance framework they were using and satisfied whatever regulatory requirements they had to satisfy.

      > Anyhow, one of my teams just struggled with that recently. They chose to
      > leap the dilemma and learn how to do remote pairing.

      It's great that they were in position to do that. In the case I was referring to, they weren't in a good position to set up remote pairing. Maybe they will consider it in future. One person's Small Step is another person's Giant Leap. The next step you can take depends on where your feet are right now.

      > Indeed. However, I think there are some cultural values that are
      > poisonous to Agile approaches, so we can't always honor the local
      > cultural values and retain integrity.

      It really depends on what the client wants from us. They don't all want a trip to Wonderland. Many of them just want some concrete improvements in the delivery stream. They are worried about immediate problems and not general, long-term improvement. (At least, not yet. If we can relieve the pressure with a few small changes, maybe they can take a deep breath and start thinking about the bigger picture.)

      > Yes. For me, that's in the category of blame assignment. With an agile
      > outsourcing approach, I can look each week and see what's being
      > produced.

      Yes, you can. I was thinking of something a bit more cynical, I suppose. Going back to Michael's example - It's possible the contractor was happy to see all that back-and-forth between development and test, because they were billing good old Uncle Sam for the time. Everyone doesn't have noble goals, you know. ;-)

    • George Dinwiddie
      Hi, Jon, ... I ve never found creating software to be a one and only time no matter how small the program. There s a lot of similarity between writing one
      Message 218 of 218 , Feb 12, 2010
        Hi, Jon,

        Jon Kern wrote:
        > ok, maybe it is silly to debate the term...
        > George it's a free country, use method anytime you please :-)
        > I personally will only use "method" when I want to describe some way
        > that I achieve something over and over. Often in an abstract sense,
        > often in a step-wise way. Often because the "something" is a desirous
        > end goal, and one that I (or someone else) wants more than one time.
        > I would not describe the /ad hoc/ "how" of the one and only time I will
        > ever do something as a "method" if it is not.

        I've never found creating software to be a "one and only time" no matter
        how small the program. There's a lot of similarity between writing one
        line of code and writing the next.

        And I've observed, that people generally continue to do something
        somewhat in the fashion they've done it before. Thoughtful people will
        consider the result their achieving, and modify their actions to try to
        improve some aspect.

        I've never seen anyone continue to approach the work as if they'd never
        done anything like it before, choosing some completely different way of
        working. And I've never seen anyone carefully follow the recipe in a
        process manual. At best, a process manual gives the worker some ideas.

        It's the process people actually /do/ that has an effect. If you and
        Scott and Glen want to reserve the word "method" for officially blessed
        procedures, go right ahead. It won't change a thing.

        - George

        * George Dinwiddie * http://blog.gdinwiddie.com
        Software Development http://www.idiacomputing.com
        Consultant and Coach http://www.agilemaryland.org
      Your message has been successfully submitted and would be delivered to recipients shortly.