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

Re: [agile-usability] Re: are you making efficient designs?

Expand Messages
  • Pascal Roy
    That s really interesting, one of the primary reasons to go for agile methods is to provide better, more concrete feedback so that the customers have a better
    Message 1 of 341 , Feb 1, 2007
    • 0 Attachment
      That's really interesting, one of the primary reasons to go for agile methods is to provide better, more concrete feedback so that the customers have a better sense of where the project is.
      If you customer isn't happy, there's something missing in your process.

      Sure we question every bit of work we do   (managerial or technical) in agile to determine if it's really worth doing, but this is not an excuse to skip doing work just because we (developers) find it annoying (although I'm sure this happens in real life...). We still have goals, plans (release and iteration) based on estimates, status reports (at the end of every iteration, heck daily if you do stand-ups...). In fact, they are much more likely to be up to date and realistic than in any traditional waterfall type development where there is no real feedback until the end of the process. The reality is that because agile is based on iterative development providing concrete feedback in the form of running software, you should have customers that feel more secure, not less...

      One other thing, agile teams will often do what might be considered "non-agile" tasks if  the customer says he needs it and understands the cost associated with it (for example, he might trade off some functionality  in order to keep a document of high level design up to date every iteration because that makes him nervous otherwise). We might want to explain why it might not be as valuable as he thinks and try to diminish his fears. But in the end, he controls scope (what we do), it's his decision. If your customer is not happy, than you did not address his issues and something is missing in the process... Of course, we need to understand that some customers are harder to please than others and some might even be unreasonable. In that case, you as a developer might come to the conclusion that it would be a sound business decision not to work with that client....
      Pascal Roy, ing./P.Eng., PMP
      Vice-Président/Vice President
      Elapse Technologies inc.

      [url]        www.elapsetech.com
      [email]]  pascal.roy@...
      [cell]       514-862-6836

      Le 07-02-01 à 04:21, Miinalainen, Petteri a écrit :

      If the crash-test dummies would do the same tasks as humans more effectively compared to the cost of change in given time-frame? Well, from business point of view, yes. When (if) you start to consider softer values or long-term development, it gets more complicated. 
      The trend is already to outsource everything (first manufacturing, then engineering, then design - you will see) to countries which provide more value for you money. In short term, you might find it very pleasing. But what will your grandchildren do for work after all the education, knowledge, research and manufacturing has been outsourced to cheaper countries already decades ago?
      Sad to say, but currently i consult my clients to do former while on personal level i worry about the latter.
      I think agile methods provide efficiency and if team is knowledgeable in different areas (mullti-disciplanary team) it can even result for better quality. For any development or usability methodology the value is eventually defining factor for it's survival. And for most managers value is something you can measure. And to be able to measure, you have to do things in pre-planned ways (to some extent). In smaller projects the measurements and predictability doesn't have time to raise to such dominant role.
      In large-scale projects, you will not get stakeholder support if you don't have most of the things planned out in details. Go and try convence ad CEO and CIO that your developers are going to design and implement most of the software while they are programming it for two to three years. it just won't work. They want planning, schedules, timeteables, sub-projects, sub-plans tracking of expenses, status reports etc. Basically they want that project has planned goals, schedule for achieving each of the goals, estimate on how much resources it takes accomplish each goal and a way to track how things are progressing. I've seen some teams ignoring this (or trying to) when doing agile development as the managerial stuff is seen just as unproductive overhead. Client won't try agile method again as they feel insecure without their progress meters.

      From: agile-usability@yahoogroups.com [mailto:agile-usability@yahoogroups.com] On Behalf Of Ron Jeffries
      Sent: 1. helmikuuta 2007 6:33
      To: agile-usability@yahoogroups.com
      Subject: Re: [agile-usability] Re: are you making efficient designs?

      Hello, Jared. On Wednesday, January 31, 2007, at 2:49:21 PM, you

      > On Jan 30, 2007, at 11:28 PM, Ron Jeffries wrote:

      >> Perhaps there are more kinds of business value than just "revenue".
      >> How many can you think of?

      > Five.

      > There are five, including revenue.

      > 1) Increased Revenue
      > 2) Reduced Expenses
      > 3) Increased Marketshare (new customers)
      > 4) Increased Business (sales to existing customers)
      > 5) Increased Shareholder Value

      > That's it.

      > Anything else has to serve one of those 5 things, or it has no value.
      > (Or REALIZED value, as it's been said elsewhere. :) )

      So, for example, we could replace all the employees with crash test
      dummies, and there would be no loss of value?

      Ron Jeffries
      Here is Edward Bear, coming downstairs now, bump, bump, bump, on the back
      of his head. It is, as far as he knows, the only way of coming downstairs,
      but sometimes he feels that there really is another way, if only he could
      stop bumping for a moment and think of it. And then he feels that perhaps
      there isn't. -- A. A. Milne

      This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.

    • Alexander Johannesen
      ... I just got back from another planet, it seems, so pardon me for asking dumb questions, but what *did* you expect? I myself do a lot of agile UX (note,
      Message 341 of 341 , Feb 23, 2007
      • 0 Attachment
        On 2/23/07, Robert Hoekman, Jr. <rhoekmanjr@...> wrote:
        > Without any hard feelings intended, the best thing I could do here is to simply
        > stop engaging in this conversation. I'm sorry if this bothers you, but this list is
        > simply not what I hoped it would be, and I believe I need to explore my
        > interests elsewhere.

        I just got back from another planet, it seems, so pardon me for asking
        dumb questions, but what *did* you expect? I myself do a lot of agile
        UX (note, small 'a'; there is no Agile) and I'm on this list, so I'm
        curious about your "Great Wall of Agile on this list"; what is it?

        Sure, a lot of people have *their* meaning of Agile and their way of
        doing things, and as you say, that's ok. Do you feel some people
        advocate only one way of Agile, perhaps a tad too much? That their
        passion is getting in the way of pragmatism?


        Project Wrangler, SOA, Information Alchymist, UX, RESTafarian, Topic Maps
        ------------------------------------------ http://shelter.nu/blog/ --------
      Your message has been successfully submitted and would be delivered to recipients shortly.