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

Re: [agile-usability] New to the challenge of Agile Usability. Looking for good ideas.

Expand Messages
  • William Pietri
    Hi, Gh900. Your question is a good one, but broad enough that it s hard to answer easily. To narrow things down, a few questions: How long are your iterations?
    Message 1 of 4 , Oct 31, 2009
    • 0 Attachment
      Hi, Gh900. Your question is a good one, but broad enough that it's hard
      to answer easily. To narrow things down, a few questions:

      How long are your iterations?

      How long, typically, is the period where your organization is thinking
      about funding a project, but hasn't actually committed to it yet?

      Do designers sit with developers?


      Thanks,

      William


      gh900 wrote:
      > I'm new to this organisation, and starting to bring in some Scrum practices. There's been a tradition of wireframing and sign-off before development starting here which I want to get away from (at least all up front!) so we can start delivering value faster.
      >
      > I know there's going to have to be some compromise to get this working, but I'm not sure whether a "wateration", as suggested in some quarters, is the best one. I can see IA/design taking place in the first half of the sprint and development in the second half. Even if we then re-work things next sprint, it's getting away from stories being done done at the end of a sprint. I can't really see this working.
      >
      > All I can come up with is some combination of the following: Get the Product Backlog in shape with all high priority stories broken down into small chunks and ready for development. Being ready should mean any IA/UCD work is complete at a story/backlog item level - maybe this can be done on a separate cycle, or one sprint in advance ? Do a Sprint Zero for new projects to set overall goals and vision, and allow time for high-level IA (and some systems architecture) to be done. More collaboration between IA, the SME and development - start working as more of a Scrum team.
      >
      > Anything else seems to go against the Scrum grain. I'm not the kind of person that would blindly adhere to a method, but I don't want to get too far away from the ideal either.
      >
      > Any good suggestions welcome. Oh, and just to complicate matters further, as well as working on multiple products, the (small) team also has to support and maintain existing applications...
      >
      >
      >
      > ------------------------------------
      >
      > Yahoo! Groups Links
      >
      >
      >
      >
    • gh900
      William Iterations are currently two weeks long. thinking time is generally in months. Designers do sit with developers. Hope that clarifies it a little.
      Message 2 of 4 , Nov 4, 2009
      • 0 Attachment
        William

        Iterations are currently two weeks long.

        "thinking time" is generally in months.

        Designers do sit with developers.

        Hope that clarifies it a little.

        Gareth


        --- In agile-usability@yahoogroups.com, William Pietri <william@...> wrote:
        >
        > Hi, Gh900. Your question is a good one, but broad enough that it's hard
        > to answer easily. To narrow things down, a few questions:
        >
        > How long are your iterations?
        >
        > How long, typically, is the period where your organization is thinking
        > about funding a project, but hasn't actually committed to it yet?
        >
        > Do designers sit with developers?
        >
        >
        > Thanks,
        >
        > William
        >
        >
        > gh900 wrote:
        > > I'm new to this organisation, and starting to bring in some Scrum practices. There's been a tradition of wireframing and sign-off before development starting here which I want to get away from (at least all up front!) so we can start delivering value faster.
        > >
        > > I know there's going to have to be some compromise to get this working, but I'm not sure whether a "wateration", as suggested in some quarters, is the best one. I can see IA/design taking place in the first half of the sprint and development in the second half. Even if we then re-work things next sprint, it's getting away from stories being done done at the end of a sprint. I can't really see this working.
        > >
        > > All I can come up with is some combination of the following: Get the Product Backlog in shape with all high priority stories broken down into small chunks and ready for development. Being ready should mean any IA/UCD work is complete at a story/backlog item level - maybe this can be done on a separate cycle, or one sprint in advance ? Do a Sprint Zero for new projects to set overall goals and vision, and allow time for high-level IA (and some systems architecture) to be done. More collaboration between IA, the SME and development - start working as more of a Scrum team.
        > >
        > > Anything else seems to go against the Scrum grain. I'm not the kind of person that would blindly adhere to a method, but I don't want to get too far away from the ideal either.
        > >
        > > Any good suggestions welcome. Oh, and just to complicate matters further, as well as working on multiple products, the (small) team also has to support and maintain existing applications...
        > >
        > >
        > >
        > > ------------------------------------
        > >
        > > Yahoo! Groups Links
        > >
        > >
        > >
        > >
        >
      • William Pietri
        In that case, I d suggest: Don t do the wateration thing. I see people struggle pretty hard with that in a 4-week iteration, and I ve never seen it work in a
        Message 3 of 4 , Nov 5, 2009
        • 0 Attachment
          In that case, I'd suggest:

          Don't do the wateration thing. I see people struggle pretty hard with that in a 4-week iteration, and I've never seen it work in a 2-week or 1-week iteration.

          Instead, I think you should switch from thinking of it as a "push" system to a "pull" system.

          Waterfall is very push-oriented. There's a giant idea that gets analyzed, broken down into a giant plan, and crammed into the production system, generally with a lot of pain.

          But the best Agile teams I see instead start with the production team, which builds a consistent amount of work every iteration. Then they say, "How can we be ready to keep them working at maximum efficiency?" The team pulls what it needs from the rest of the organization, a bit at a time.

          As you say, that involves having a broad but shallow product backlog, so when we ask, "What's the most important thing they could release this iteration?" we have some confidence that we know.

          Then for the thing the team takes on this iteration, product managers need to be ready to answer any question that comes up without delay, as do the people with "design" in their titles. That generally means some pre-iteration prep work. The right amount varies by product and by team, but the shorter your iterations, the more quickly everybody will learn what the right local approaches are.

          Personally, I think Sprint Zero is unnecessary, a luxury. If your organization has taken months to think about a project before pulling the trigger, then I'd bet people know enough to select an iteration's worth of work without too much risk. Certainly I've never seen a project where I couldn't shake out a week's work. But if you need a little waterfall hair-of-the-dog to get going, I doubt it will do much harm.


          Regarding your multiple-project issue, I recommend one work queue per team. So if it's truly one team, then all work requests for them go in the same stream and count toward the same velocity number.

          Hoping that helps,

          William


          gh900 wrote:
          William
          
          Iterations are currently two weeks long.
          
          "thinking time" is generally in months.
          
          Designers do sit with developers.
          
          Hope that clarifies it a little.
          
          Gareth
          
          
          --- In agile-usability@yahoogroups.com, William Pietri <william@...> wrote:
            
          Hi, Gh900. Your question is a good one, but broad enough that it's hard 
          to answer easily. To narrow things down, a few questions:
          
          How long are your iterations?
          
          How long, typically, is the period where your organization is thinking 
          about funding a project, but hasn't actually committed to it yet?
          
          Do designers sit with developers?
          
          
          Thanks,
          
          William
          
          
          gh900 wrote:
              
          I'm new to this organisation, and starting to bring in some Scrum practices. There's been a tradition of wireframing and sign-off before development starting here which I want to get away from (at least all up front!) so we can start delivering value faster.
          
          I know there's going to have to be some compromise to get this working, but I'm not sure whether a "wateration", as suggested in some quarters, is the best one. I can see IA/design taking place in the first half of the sprint and development in the second half. Even if we then re-work things next sprint, it's getting away from stories being done done at the end of a sprint. I can't really see this working.
          
          All I can come up with is some combination of the following: Get the Product Backlog in shape with all high priority stories broken down into small chunks and ready for development. Being ready should mean any IA/UCD work is complete at a story/backlog item level - maybe this can be done on a separate cycle, or one sprint in advance ? Do a Sprint Zero for new projects to set overall goals and vision, and allow time for high-level IA (and some systems architecture) to be done. More collaboration between IA, the SME and development - start working as more of a Scrum team.
          
          Anything else seems to go against the Scrum grain. I'm not the kind of person that would blindly adhere to a method, but I don't want to get too far away from the ideal either.
          
          Any good suggestions welcome. Oh, and just to complicate matters further, as well as working on multiple products, the (small) team also has to support and maintain existing applications...
          
          
          
          ------------------------------------
          
          Yahoo! Groups Links
          
          
          
          
                
          
          
          
          ------------------------------------
          
          Yahoo! Groups Links
          
          <*> To visit your group on the web, go to:
              http://groups.yahoo.com/group/agile-usability/
          
          <*> Your email settings:
              Individual Email | Traditional
          
          <*> To change settings online go to:
              http://groups.yahoo.com/group/agile-usability/join
              (Yahoo! ID required)
          
          <*> To change settings via email:
              agile-usability-digest@yahoogroups.com 
              agile-usability-fullfeatured@yahoogroups.com
          
          <*> To unsubscribe from this group, send an email to:
              agile-usability-unsubscribe@yahoogroups.com
          
          <*> Your use of Yahoo! Groups is subject to:
              http://docs.yahoo.com/info/terms/
          
            

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