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

7333Re: [agile-usability] Re: Process Entry Points...

Expand Messages
  • chris chandler
    Mar 27, 2011
    • 0 Attachment

      With all due respect, that sounds horrible. I'm probably a big jerk for saying so, but let me tell you that I operate in the UX portion of a gigantic enterprise, and I live something very close to the scenario you describe, so my reaction is based in my experience.

      Let me paraphrase your process:
      The product manager has an idea (or even mandate) for a feature. He describes this feature to the BA, who then describes it to the UX person. The BA goes back and forth between the two, (or three, or four depending on how you count architects and dev) until he wraps it all up and someone gets the go ahead to build something -- presumably based on all the "context" he's been saving.

      Again, I'm not trying to be harsh, and I'm probably exaggerating, but there is pretty much nothing relating to an "agile" methodology in anything you described.

      One other approach, would be to read the agile manifesto and see how the principles there, if applied, would alter the process you laid out.

      Individuals and interactions over processes and tools
      Working software over comprehensive documentation
      Customer collaboration over contract negotiation
      Responding to change over following a plan

      I'm not even going to get into the fact that the rationale you mentioned for this process is to keep UX from dominating the product managers vision -- but I will say to me, this hints at some fundamental cultural issues in the organization that stand in the way of effectiveness.


      On Sat, Mar 26, 2011 at 12:00 PM, Dean <dean.stevens1@...> wrote:

      I am interested to hear this feedback as well.

      I agree UX should be engaged as part of Discovery or Inception. The question is the level of engagement. At my current client, the push back is that UX tends to dominate the conversation with product managers. Ideas that are very difficult to deliver get baked into requirements.

      I'm recommending the following approach of two distinct conversations.

      First, the BA gets to a proposed feature set and a high level use case. UX, along with architects, can listen and ask clarifying questions but are mostly present to understand. So initially engagement is fairly low. They don't actually even have to be present.

      Then BA presents the initial discovery and gets input from UX and architects to produce options: Good, Better, Best solution sets. The Ba will Gain agreement and present these options to product managers. This may be the place for conceptual mock-ups.

      The BA intentionally iterates between these two conversations. The BA must hold the context of learning from the product manager/ business and then developing viable options with UX, architects and dev. These are distinctly different conversations. I call this dialog then discussion (my Peter Senge reference :).

      I'm looking forward to hearing other approaches. Dean Stevens

      --- In agile-usability@yahoogroups.com, "Brando" <brandonpmitchell@...> wrote:
      > I am currently working to implement a flexible, but consistent Agile UX process at a large enterprise-software development group. We typically have 4-10 large scale projects going at any one time.
      > As I examine current processes and look at where projects went off-course, or progressed slowly, is because they did not get UX/Strategy involved early enough. Our current practices seem to put any UX involvment -AFTER- requirements have been generally collected.
      > It seems that in an Agile/Iterative environment, it makes sense for the UX side of the project to:
      > - Be engaged AT the time that Business Analsyts are assigned
      > - This could be BEFORE any Product Backlog or Features List is officially complete.
      > - Understand HIGH-LEVEL functionality (not necessarily details)
      > - Create early 'customer journey' sketches / outlines
      > - BEFORE the rest of the development team actually joins, have an early conceptual mockup/design so it also helps the project team have a quicker understanding of the project --- visually.
      > It just seems that getting a requirements document 'dropped on my desk' is not the most effective way to design an application.
      > I'm looking for opinions on the best place to inject into the project.
      > Any opinions, trials, or suggestions are welcome.

    • Show all 9 messages in this topic