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

Help with an article?

Expand Messages
  • Esther Schindler
    Howdy, folks. I m working on an article for ITWorld.com, and I d like your input. The working title is: “Why your users hate Agile software development.”
    Message 1 of 4 , May 12, 2013
    View Source
    • 0 Attachment
      Howdy, folks. I'm working on an article for ITWorld.com, and I'd like your input.

      The working title is: �Why your users hate Agile software development.�

      Despite the challenging headline -- hey, we have to attract people's attention here -- I am not against Agile. Quite to the contrary. But I do want to see it done WELL and RIGHT and to the benefit of all concerned. My premise in this article is: Agile developers and project managers should have some insight into why Agile causes anxiety and what they can do to minimize that.

      Most developers I know really like Agile. There are a lot of advantages, and I doubt we need to go into what they are.

      Clients and users, however, may not appreciate all those things. They have their own concerns -- and sometimes Agile developers don't recognize them.

      It isn't always the user's fault. Sometimes the users have a _perception_ of a problem that they blame on Agile... for good reasons. For example, I've spoken with corporate users who kept trying to shoe-horn more and more functionality into an initial iteration. That sounds like they didn't grok what "iteration" meant, when in reality it was a response to their own corporate culture: They knew full well that the funding would go away after the "first phase," with excuses like, "We'll do that in phase 2, next spring," when reality taught them that phase 2 never never does get funded. The developers are moved onto some other project and the users never get that must-have requirement EVER.

      Another reason that the users might hate agile: The developers talk to the wrong users. They interview the department managers, who might care about things like reporting, but the developers never have the opportunity to talk to the day-to-day users who might have reasonable requests to improve the data entry process. To those users, "Agile" is just another way to ignore their needs while claiming that the process is to serve them.

      And those are just off the top of my head.

      So I'm writing a feature article for ITWorld about the subject... and I'd like your input. It can be public on the list (which I am sure would be appreciated) or private. Ideally you permit me to refer to you by full name, title, and company or company type ("Esther Schindler, a developer at SRP, the electric company in Phoenix"), but if it encourages openness I'm okay with working with an arm wave ("Esther, a corporate developer in Phoenix").

      * How do you describe the Agile process to a client or user who is expecting something different?

      * What, in your experience, are their big concerns about doing things without a Big Design Up Front process? What about the little ones?

      * What has gone wrong? What would you do differently, in those situations, knowing what you do now?

      * What do YOU think makes users and clients anxious? What do you do to counter it?

      * Please DO NOT spend time telling me how great Agile is. I already know that. That's not what this article is about.

      I do all of this by e-mail, not telephone. I'll also be collecting input all week, with the fond hope that I will have enough to assemble into an article by next weekend.

      --Esther Schindler
      twitter.com/estherschindler

      [Non-text portions of this message have been removed]
    • Francis Fish
      Hi Esther Just found this half-answered in my drafts to thought I d finish it :) ... Different from what? If you mean waterfall then it s about delivering
      Message 2 of 4 , Jun 4, 2013
      View Source
      • 0 Attachment
        Hi Esther

        Just found this half-answered in my drafts to thought I'd finish it :)


        >
        > * How do you describe the Agile process to a client or user who is
        > expecting something different?
        >

        Different from what? If you mean waterfall then it's about delivering
        working software incrementally, preferably the most risky/challenging
        pieces first, without the last minute scrabble and overruns because people
        have developed the habit of delivering useful stuff continuously. This also
        means that it's easy to spot if things were under specified (or rather
        under budgeted) early.


        > * What, in your experience, are their big concerns about doing things
        > without a Big Design Up Front process? What about the little ones?
        >

        BDUF is something *we* used to do. Users used to see it as a burden and it
        was always rushed at the inception phase. However agile needs constant
        feedback - and they don't like being asked for it when they're off doing
        things they see as more important. This creates a continuous tension
        instead of one that only lasts a few weeks. If they don't buy in, or employ
        a BA who is also always looking at something 6 months hence, it's gonna get
        really hard.

        Also lots of people misread the manifesto and don't do any design at all -
        then end up making mud pies (as in the Big Ball of Mud pattern) and it all
        has to be rewritten in 18 months time if the business hasn't failed.

        Users want *capability* not user stories, designs or any other of the
        artefacts we use to deliver that capability. We need to lift our heads up
        much more often :)


        >
        > * What has gone wrong? What would you do differently, in those situations,
        > knowing what you do now?
        >

        Spend a lot more time making sure people are talking to each other about
        what they need, or more importantly why it's needed. Make sure that we can
        deliver the minimum they need within the external constraints.


        >
        > * What do YOU think makes users and clients anxious? What do you do to
        > counter it?
        >


        They have budgets and need things done by a particular time. We, instead,
        flex on functionality and backlog. This will cause conflict unless we make
        sure that they get what they want when they want it. This needs contingency
        building in, instead of being taken out. It also needs a culture of trust
        and less politics.

        I have found that flexing on functionality means that you need to make sure
        that you know what the business need in some detail, and you need to know
        the *why* rather than the *what*. You can find a way to something that
        gives capability with the *why* - the what is just an implementation
        detail. I've found the idea of "commander's intent" really useful when
        discussing this with people.

        Shameless plug - I talk about this at some length in Unicorns in the Mist
        https://leanpub.com/unicorns :)


        >
        > * Please DO NOT spend time telling me how great Agile is. I already know
        > that. That's not what this article is about.
        >
        > I do all of this by e-mail, not telephone. I'll also be collecting input
        > all week, with the fond hope that I will have enough to assemble into an
        > article by next weekend.
        >
        > --Esther Schindler
        > twitter.com/estherschindler
        >
        > [Non-text portions of this message have been removed]
        >

        Thanks and regards,

        Francis

        Follow me on twitter https://twitter.com/fjfish
        Blog at http://www.francisfish.com
        Books at https://leanpub.com/u/fjfish
        CV http://www.pharmarketeer.com/francis.html

        I have no intention of apologizing for believing in people, for insisting
        that we all use this moment and these assets to create some art and improve
        the world around us.
        To do anything less than that is a crime. - Seth Godin


        [Non-text portions of this message have been removed]
      • Esther Schindler
        Wah! The article just went live today! Why your users hate Agile development (and what you can do about it) What developers see as iterative and flexible,
        Message 3 of 4 , Jun 4, 2013
        View Source
        • 0 Attachment
          Wah! The article just went live today!

          Why your users hate Agile development (and what you can do about it)
          What developers see as iterative and flexible, users see as disorganized and never-ending. Here�s how some experienced developers have changed that perception.

          http://www.itworld.com/software/359398/why-your-users-hate-agile-development-and-what-you-can-do-about-it



          On Jun 4, 2013, at 3:24 PM, Francis Fish <francis@...> wrote:

          > Hi Esther
          >
          > Just found this half-answered in my drafts to thought I'd finish it :)
          >
          > >
          > > * How do you describe the Agile process to a client or user who is
          > > expecting something different?
          > >
          >
          > Different from what? If you mean waterfall then it's about delivering
          > working software incrementally, preferably the most risky/challenging
          > pieces first, without the last minute scrabble and overruns because people
          > have developed the habit of delivering useful stuff continuously. This also
          > means that it's easy to spot if things were under specified (or rather
          > under budgeted) early.
          >
          > > * What, in your experience, are their big concerns about doing things
          > > without a Big Design Up Front process? What about the little ones?
          > >
          >
          > BDUF is something *we* used to do. Users used to see it as a burden and it
          > was always rushed at the inception phase. However agile needs constant
          > feedback - and they don't like being asked for it when they're off doing
          > things they see as more important. This creates a continuous tension
          > instead of one that only lasts a few weeks. If they don't buy in, or employ
          > a BA who is also always looking at something 6 months hence, it's gonna get
          > really hard.
          >
          > Also lots of people misread the manifesto and don't do any design at all -
          > then end up making mud pies (as in the Big Ball of Mud pattern) and it all
          > has to be rewritten in 18 months time if the business hasn't failed.
          >
          > Users want *capability* not user stories, designs or any other of the
          > artefacts we use to deliver that capability. We need to lift our heads up
          > much more often :)
          >
          > >
          > > * What has gone wrong? What would you do differently, in those situations,
          > > knowing what you do now?
          > >
          >
          > Spend a lot more time making sure people are talking to each other about
          > what they need, or more importantly why it's needed. Make sure that we can
          > deliver the minimum they need within the external constraints.
          >
          > >
          > > * What do YOU think makes users and clients anxious? What do you do to
          > > counter it?
          > >
          >
          > They have budgets and need things done by a particular time. We, instead,
          > flex on functionality and backlog. This will cause conflict unless we make
          > sure that they get what they want when they want it. This needs contingency
          > building in, instead of being taken out. It also needs a culture of trust
          > and less politics.
          >
          > I have found that flexing on functionality means that you need to make sure
          > that you know what the business need in some detail, and you need to know
          > the *why* rather than the *what*. You can find a way to something that
          > gives capability with the *why* - the what is just an implementation
          > detail. I've found the idea of "commander's intent" really useful when
          > discussing this with people.
          >
          > Shameless plug - I talk about this at some length in Unicorns in the Mist
          > https://leanpub.com/unicorns :)
          >
          > >
          > > * Please DO NOT spend time telling me how great Agile is. I already know
          > > that. That's not what this article is about.
          > >
          > > I do all of this by e-mail, not telephone. I'll also be collecting input
          > > all week, with the fond hope that I will have enough to assemble into an
          > > article by next weekend.
          > >
          > > --Esther Schindler
          > > twitter.com/estherschindler
          > >
          > > [Non-text portions of this message have been removed]
          > >
          >
          > Thanks and regards,
          >
          > Francis
          >
          > Follow me on twitter https://twitter.com/fjfish
          > Blog at http://www.francisfish.com
          > Books at https://leanpub.com/u/fjfish
          > CV http://www.pharmarketeer.com/francis.html
          >
          > I have no intention of apologizing for believing in people, for insisting
          > that we all use this moment and these assets to create some art and improve
          > the world around us.
          > To do anything less than that is a crime. - Seth Godin
          >
          >


          [Non-text portions of this message have been removed]
        • Francis Fish
          ... It s nice to see there is a lot of congruence, I m not going mad. :) [Non-text portions of this message have been removed]
          Message 4 of 4 , Jun 4, 2013
          View Source
          • 0 Attachment
            On Tue, Jun 4, 2013 at 11:26 PM, Esther Schindler <esther@...>wrote:

            > Wah! The article just went live today!
            >
            > Why your users hate Agile development (and what you can do about it)
            > What developers see as iterative and flexible, users see as disorganized
            > and never-ending. Here�s how some experienced developers have changed that
            > perception.
            >
            >
            > http://www.itworld.com/software/359398/why-your-users-hate-agile-development-and-what-you-can-do-about-it
            >
            >
            >
            >
            It's nice to see there is a lot of congruence, I'm not going mad. :)


            [Non-text portions of this message have been removed]
          Your message has been successfully submitted and would be delivered to recipients shortly.