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

Re: Agile Team Boilerplate

Expand Messages
  • vasonson
    Thanks William. I knew my question was very general in nature but I needed a place to start. Since this is an agile-usability forum, I am most interested in
    Message 1 of 8 , Oct 16, 2009
    • 0 Attachment
      Thanks William. I knew my question was very general in nature but I needed a place to start. Since this is an agile-usability forum, I am most interested in how the user experience team is baked into an agile development team - how does UX work fit into agile? Is this still to broad a question to ask? Thanks again.

      --- In agile-usability@yahoogroups.com, William Pietri <william@...> wrote:
      >
      > vasonson wrote:
      > > Hi all - I'm new to agile development and I was wondering if anyone has a good boilerplate template they could share that identifies and defines the roles on an agile development team, including those of the customer. Any guidance would be greatly appreciated. Thanks!
      > >
      > >
      >
      > There is no generic "agile" process. So actual roles depend on which
      > agile process you're using.
      >
      > One complicating factor is that the Agile Manifesto elevates
      > "individuals and interactions over processes and tools", so there's a
      > fair bit of local variance based on what skills and relationships the
      > real people involved have. Plus, good agile teams are supposed to
      > tinker with their process, so even teams that start out the same way end
      > up quite different.
      >
      > Was there something in particular you were wondering?
      >
      > William
      >
    • Rudiger
      ... Some people in the agile world think there is no place for roles and others think there should be. Here are links to two agile flavours that do have role
      Message 2 of 8 , Oct 18, 2009
      • 0 Attachment
        --- In agile-usability@yahoogroups.com, "vasonson" <vasonson@...> wrote:
        >
        > Hi all - I'm new to agile development and I was wondering if anyone has a good boilerplate template they could share that identifies and defines the roles on an agile development team, including those of the customer. Any guidance would be greatly appreciated. Thanks!
        >


        Some people in the agile world think there is no place for roles and others think there should be.

        Here are links to two agile flavours that do have role descriptions:

        Open Unified process (OUP)
        http://epf.eclipse.org/wikis/openup/

        Dynamic Systems Development Method (DSDM)
        http://www.dsdm.org/atern/roles-responsibilities/
        You need to register.
      • William Pietri
        ... Heh. It s certainly not too broad to ask. However, answering that is a major purpose of this group, so I don t know that we have a short answer for you
        Message 3 of 8 , Oct 18, 2009
        • 0 Attachment
          vasonson wrote:
          > Thanks William. I knew my question was very general in nature but I needed a place to start. Since this is an agile-usability forum, I am most interested in how the user experience team is baked into an agile development team - how does UX work fit into agile? Is this still to broad a question to ask? Thanks again.
          >

          Heh. It's certainly not too broad to ask. However, answering that is a
          major purpose of this group, so I don't know that we have a short answer
          for you yet.

          My personal view is that you can divide UX work up into two sorts. The
          division parallels the common Agile division between product management
          and actual construction. Consider this breakdown:

          http://www.jjg.net/elements/pdf/elements.pdf

          I think the top layers, the most concrete ones, are mainly about the
          details of construction, the how of the project. The bottom layers are
          more about who, why, and what, which is what product managers normally
          concern themselves with. So I'd say UX fits in differently depending on
          which layer you're talking about.

          Regardless, I think the way to fit it in is to make sure that your
          project has everybody vital in one room Then have them frequently
          deliver working product -- including to end users -- and regularly
          evaluate both external effects and internal processes.

          That may seem too simple, but teams who appreciate usability will turn
          to the UX people right away. Those that don't need to feel the pain of
          releasing something bad for their users, so they can learn to appreciate
          those people sitting right there with them. :-)

          William
        • vasonson
          Thank you very much for the resource links!
          Message 4 of 8 , Oct 19, 2009
          • 0 Attachment
            Thank you very much for the resource links!

            --- In agile-usability@yahoogroups.com, "Rudiger" <rudiger.wolf@...> wrote:
            >
            >
            >
            > --- In agile-usability@yahoogroups.com, "vasonson" <vasonson@> wrote:
            > >
            > > Hi all - I'm new to agile development and I was wondering if anyone has a good boilerplate template they could share that identifies and defines the roles on an agile development team, including those of the customer. Any guidance would be greatly appreciated. Thanks!
            > >
            >
            >
            > Some people in the agile world think there is no place for roles and others think there should be.
            >
            > Here are links to two agile flavours that do have role descriptions:
            >
            > Open Unified process (OUP)
            > http://epf.eclipse.org/wikis/openup/
            >
            > Dynamic Systems Development Method (DSDM)
            > http://www.dsdm.org/atern/roles-responsibilities/
            > You need to register.
            >
          • vasonson
            There are many people with deep scars as a result not considering UX before releasing software! Thanks for the insight.
            Message 5 of 8 , Oct 19, 2009
            • 0 Attachment
              There are many people with deep scars as a result not considering UX before releasing software! Thanks for the insight.

              --- In agile-usability@yahoogroups.com, William Pietri <william@...> wrote:
              >
              > vasonson wrote:
              > > Thanks William. I knew my question was very general in nature but I needed a place to start. Since this is an agile-usability forum, I am most interested in how the user experience team is baked into an agile development team - how does UX work fit into agile? Is this still to broad a question to ask? Thanks again.
              > >
              >
              > Heh. It's certainly not too broad to ask. However, answering that is a
              > major purpose of this group, so I don't know that we have a short answer
              > for you yet.
              >
              > My personal view is that you can divide UX work up into two sorts. The
              > division parallels the common Agile division between product management
              > and actual construction. Consider this breakdown:
              >
              > http://www.jjg.net/elements/pdf/elements.pdf
              >
              > I think the top layers, the most concrete ones, are mainly about the
              > details of construction, the how of the project. The bottom layers are
              > more about who, why, and what, which is what product managers normally
              > concern themselves with. So I'd say UX fits in differently depending on
              > which layer you're talking about.
              >
              > Regardless, I think the way to fit it in is to make sure that your
              > project has everybody vital in one room Then have them frequently
              > deliver working product -- including to end users -- and regularly
              > evaluate both external effects and internal processes.
              >
              > That may seem too simple, but teams who appreciate usability will turn
              > to the UX people right away. Those that don't need to feel the pain of
              > releasing something bad for their users, so they can learn to appreciate
              > those people sitting right there with them. :-)
              >
              > William
              >
            Your message has been successfully submitted and would be delivered to recipients shortly.