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

How much agility in look and feel?

Expand Messages
  • tony_t_tubbs
    I m pulling this topic out of my How to be an agent of change post. The question means how much change can go into the look and feel from one iteration to
    Message 1 of 41 , Nov 18, 2007
      I'm pulling this topic out of my "How to be an agent of change" post.
      The question means how much change can go into the look and feel from
      one iteration to the next iteration? Can it be acceptable that a
      final release doesn't look anything like an initial release as long as
      functionality is maintained? Thoughts and experiences welcomed.
    • Gary Brown
      Hi, Tony, ... Here is what you wrote in message #136754 I was in an interesting meeting this week were business, human factors, and technical folks all
      Message 41 of 41 , Nov 25, 2007
        Hi, Tony,

        Quoting tony_t_tubbs <tony_t_tubbs@...>:

        > GB,
        > I said the UI folks dreamed this command line widget up internal, the
        > clients haven't even seen it yet. I have issues with them taking such
        > a hard stance on it, when they haven't even shopped it around.
        > Anyway, only the UI folks have spoken (so far) not the Customers.
        > Again, my point to the post was a discussion about when and where that
        > hard line should/shouldn't be drawn with respect to the UI. The most
        > direct response to that was the poster who talked about the power of
        > AND, and suggesting a solution of both buttons AND later the command
        > line thing. Other posts indirectly seem to address the point by
        > suggesting that the line is drawn where the customer wants it to be
        > drawn. I find it all helpful information.
        > I'm am unable to grasp how you reached the conclusion that a
        > discussion I'm involved in, in a yahoo group equates to what I do at
        > work. The facts are that I am well aware that the concerns I raised
        > were not as concerning to everyone else as they were to me. As such,
        > I have gone along with the rest of the party, and without the need for
        > a coach to tell me to do so. I've spent every working day since on
        > the command line thing, as that was agreed to be of the highest
        > priority.
        > Oddly, I find that your post and the responses to it have really
        > gotten this post on topic, Your 'suck it up' suggestion is very much
        > like the stance the UI folks have taken, and the responses to that
        > express the frustration with dealing with that from a technical
        > perspective. More than that though, they include tips and suggestions
        > for how to better deal with such craziness. I've found this
        > discussion informative as well.

        Here is what you wrote in message #136754

        "I was in an interesting meeting this week were business, human
        factors, and technical folks all thought everyone was on the same
        page, but found out that each group's understanding of what and where
        we are going on the project was different. We all are trying to do
        things different because what we've been doing for years keeps leading
        to the same results (Surprised, right?). Our typical approach is
        gather requirements up front, kick the clients out of the way while we
        code like mad, then pull clients back in at delivery time months
        later. This round, all have agreed to trying a more iterative
        approach, the powers that be are at least paying lip service to
        keeping clients closer and more involved along the way, and all
        parties have agreed to an initial delivery of just some basic
        functionality clients really want. I'm not suggesting this is agile
        or XP in anyway, I don't think it is, but I do see it as a step in the
        right direction.

        So, the problems come to the surface when we start talking details.
        The root of the problems are in agreeing to what we deliver and how we
        deliver it. It seems the business and human factors folks are more
        closely aligned in that they think iterative means adding to, but not
        changing or replacing. For example, we have a long term goal to do
        something in our app like yubnub.org does for the web. Because of
        that, they want some sort of basic one of these in our initial
        delivery. Iterative in their mind is that we add more options to it
        over time. Technical folks like myself suggested just a couple of
        buttons on the first round would suffice. We could switch the buttons
        out for a command driven thing in some later iteration. They were not
        happy with this, would not agree that this refactor/replacement idea
        was iterative. They suggested we'd screwed up very badly and would do
        nothing but confuse our clients."

        I assumed when you said "business ... folks", you meant people who are
        involved in product development. I took that to mean the Customer,
        capital C, in the XP sense of the word. In my organization, the human
        factors folks report to the product development group, so they are
        Customers as well.

        Sorry if I missed your intended meaning!

      Your message has been successfully submitted and would be delivered to recipients shortly.