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

Re: [scrumdevelopment] Design process in agile

Expand Messages
  • Pierre Neis
    Hi Emma, In my teams (coaching a program with developers, analysts and separated UX Designers), I ve been facing the same problems. If you re following Scrum
    Message 1 of 25 , Dec 30, 2011
    • 0 Attachment
      Hi Emma,

      In my teams (coaching a program with developers, analysts and separated UX Designers), I've been facing the same problems.

      If you're following Scrum straight then your designer must integrate the Development Team. Now if you need sometimes designer's support, then use it as external force or techlead. Here, for alignment reasons, it can be interesting to have a dedicated US for him/her.

      - Do you tend to have HTML mock-ups as part of a story (where needed?), [if designer part of the Team, then task is enough; else it's a story] or as part of grooming beforehand [then you must have an internal designer and designer plays TechLead]?
      - How do you handle design tickets on a story? [see above]
      - Are there any useful guidelines as to how the design process fits within agile? [Y/N, it's useful to collect data from end users and get their commitment. Make sense in the early development phases when you have few to show and during the process when you have to fix tech debt.]
      - What is your sign-off process for design and at what stage does this happen (e.g. desk demo of HTML, or when the design has been integrated into the developed page) [at current program, designers are involved since the beginning and supports Product Owners and Business Analysts. Designers are pair-working with BA to test business cases.]

      Hope it helps a bit.

      Pierre E.  NEIScsp

      PMO @ coPROcess S.A. 
      │ Scrum & Lean Coach   

      M: +352 / 661 727 867  - Skype: pierre.neis  
      Meet with me: http://meetwith.me/pierreneis



       

      Blogger Twitter LinkedIn SlideShare
      Contact me: Google Talk pierreneis@... Skype pierre.neis
      TwitterLatest tweet: @da_chrisch @scrumphony if I understand: I can't weir my favorite tie? Follow @elPedroMajor Reply Retweet   14:41 Dec-30


      On 30 December 2011 17:26, Emma G <emmagarland77@...> wrote:

      - Do you tend to have HTML mock-ups as part of a story (where needed?), or as part of grooming beforehand?
      - How do you handle design tickets on a story?
      - Are there any useful guidelines as to how the design process fits within agile?
      - What is your sign-off process for design and at what stage does this happen (e.g. desk demo of HTML, or when the design has been integrated into the developed page)


    • Fagan John
      Hi Emma - We have the same setup as you, 1 designer split across 2 sprint teams. We treat our design (creative) process like any other story within a sprint,
      Message 2 of 25 , Jan 3, 2012
      • 0 Attachment

        Hi Emma –

         

        We have the same setup as you, 1 designer split across 2 sprint teams. 

         

        We treat our  design (creative) process like any other story within a sprint, with its own specific acceptance criteria.   The scum team commits to what they think they can complete based on availability of the designer.  The “sign-off” is the acceptance criteria, which can happen within a sprint.  A story is not done done until these are met.   The AC can contain anything that needs to be met before its done, including sign off from particular people and/or delivery of relevant documents (html or image, style guides etc..).

         

        If its quite a big design task, then try break it down, or complete it in the sprint before implementation. 

         

        HTH.

         

        cheers, john

         

        From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Emma G
        Sent: 30 December 2011 17:26
        To: scrumdevelopment@yahoogroups.com
        Subject: [scrumdevelopment] Design process in agile

         

         

        I am interested in finding out how to handle the design process within an agile project.

        I'm a developer on a scrum team. We have one in-house designer who isn't solely in the sprints as he works for other teams as well. He creates the initial mock-ups of new pages, and either he or other developers will integrate this design into our solution during the sprint (usually as part of a wider story). We don't have an agreed design process yet.

        - Do you tend to have HTML mock-ups as part of a story (where needed?), or as part of grooming beforehand?
        - How do you handle design tickets on a story?
        - Are there any useful guidelines as to how the design process fits within agile?
        - What is your sign-off process for design and at what stage does this happen (e.g. desk demo of HTML, or when the design has been integrated into the developed page)

        Any suggestions or personal experience of how design fits into agile would be appreciated.

        Thanks

        Emma

      • Emma G
        Hi Jack, Yes, Balsamiq is something we have tried out, and it seems quite quick to output something. In theory we would be able to go straight from Balsamiq to
        Message 3 of 25 , Jan 10, 2012
        • 0 Attachment
          Hi Jack,

          Yes, Balsamiq is something we have tried out, and it seems quite quick to output something. In theory we would be able to go straight from Balsamiq to the code without any HTML mocks in between if we use the design guidelines we have.

          Cheers

          Emma

          --- In scrumdevelopment@yahoogroups.com, "JackM" <jack@...> wrote:
          >
          > Well I have seen many companies do wireframes using tools like balsamiq which are actually quite cool. But you'd be better off in my opinion building the real thing in whatever technology it is you're using and iterate over the real thing. I have worked with companies where they spend huge amounts of time on mockups and wireframes using design tools and at the end of it have nothing to show for it.
          >
          > Scrum tries to focus teams on delivering working software every iteration and so you should strive to do that.
          >
          > Hope that helps
          > Jack
          > www.agilebuddy.com
          >
          > --- In scrumdevelopment@yahoogroups.com, "Emma G" <emmagarland77@> wrote:
          > >
          > > Hi Jack
          > >
          > > At the moment we have a mixture of Sprint Cycle design, and sprint ahead design.
          > >
          > > Do you mean working wireframes as in the actual skeleton of the page is developed (e.g. in .net), rather than in HTML as a demo site? When iterating them as you go, do you mean the regular desk demos e.g. to the product owner.
          > >
          > > I guess I am really talking about the whole design process, but when referring to the initial design process I meant the graphical side. These discussions have raised a lot of good points though so my original question has expanded somewhat!
          > >
          > > Thanks for the response,
          > >
          > > Emma
          > >
          > >
          > > --- In scrumdevelopment@yahoogroups.com, "JackM" <jack@> wrote:
          > > >
          > > > In an ideal world you want to do this as part of the scrum sprint cycle just like you manage anything else. However, some companies if we're talking wireframes would want to work on those upfront i.e. a sprint ahead of when they're required.
          > > >
          > > > The problem with wireframes is that after building them that's all you have i.e. no working software. So it would be better to work with the designer to produce "working wireframes" and iterate over these as you go. That way you eliminate waste. But i know all to well that some companies don't like to work this way.
          > > >
          > > > If we're talking about just graphics as I saw you refer to in a different reply then just treat those as tasks that need to get done during the Sprint or dependencies that you track seperately. But you'll need to coordinate effectively as this will be your choke point.
          > > >
          > > > I hope that helps.
          > > > Jack
          > > > www.agilebuddy.com
          > > >
          > > > --- In scrumdevelopment@yahoogroups.com, "Emma G" <emmagarland77@> wrote:
          > > > >
          > > > > I am interested in finding out how to handle the design process within an agile project.
          > > > >
          > > > > I'm a developer on a scrum team. We have one in-house designer who isn't solely in the sprints as he works for other teams as well. He creates the initial mock-ups of new pages, and either he or other developers will integrate this design into our solution during the sprint (usually as part of a wider story). We don't have an agreed design process yet.
          > > > >
          > > > > - Do you tend to have HTML mock-ups as part of a story (where needed?), or as part of grooming beforehand?
          > > > > - How do you handle design tickets on a story?
          > > > > - Are there any useful guidelines as to how the design process fits within agile?
          > > > > - What is your sign-off process for design and at what stage does this happen (e.g. desk demo of HTML, or when the design has been integrated into the developed page)
          > > > >
          > > > > Any suggestions or personal experience of how design fits into agile would be appreciated.
          > > > >
          > > > > Thanks
          > > > >
          > > > > Emma
          > > > >
          > > >
          > >
          >
        • Emma G
          Hi John, Thanks for the reply. We tend to write our acceptance criteria before/during Sprint planning but it sometimes evolves throughout the sprint and the
          Message 4 of 25 , Jan 10, 2012
          • 0 Attachment
            Hi John,

            Thanks for the reply.

            We tend to write our acceptance criteria before/during Sprint planning but it sometimes evolves throughout the sprint and the story on the board is adjusted.

            Do you have a specific design story or add a design ticket on a wider story for example?


            Thanks

            Emma


            --- In scrumdevelopment@yahoogroups.com, "Fagan John" <john.fagan@...> wrote:
            >
            > Hi Emma -
            >
            >
            >
            > We have the same setup as you, 1 designer split across 2 sprint teams.
            >
            >
            >
            > We treat our design (creative) process like any other story within a
            > sprint, with its own specific acceptance criteria. The scum team
            > commits to what they think they can complete based on availability of
            > the designer. The "sign-off" is the acceptance criteria, which can
            > happen within a sprint. A story is not done done until these are met.
            > The AC can contain anything that needs to be met before its done,
            > including sign off from particular people and/or delivery of relevant
            > documents (html or image, style guides etc..).
            >
            >
            >
            > If its quite a big design task, then try break it down, or complete it
            > in the sprint before implementation.
            >
            >
            >
            > HTH.
            >
            >
            >
            > cheers, john
            >
            >
            >
            > From: scrumdevelopment@yahoogroups.com
            > [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Emma G
            > Sent: 30 December 2011 17:26
            > To: scrumdevelopment@yahoogroups.com
            > Subject: [scrumdevelopment] Design process in agile
            >
            >
            >
            >
            >
            > I am interested in finding out how to handle the design process within
            > an agile project.
            >
            > I'm a developer on a scrum team. We have one in-house designer who isn't
            > solely in the sprints as he works for other teams as well. He creates
            > the initial mock-ups of new pages, and either he or other developers
            > will integrate this design into our solution during the sprint (usually
            > as part of a wider story). We don't have an agreed design process yet.
            >
            > - Do you tend to have HTML mock-ups as part of a story (where needed?),
            > or as part of grooming beforehand?
            > - How do you handle design tickets on a story?
            > - Are there any useful guidelines as to how the design process fits
            > within agile?
            > - What is your sign-off process for design and at what stage does this
            > happen (e.g. desk demo of HTML, or when the design has been integrated
            > into the developed page)
            >
            > Any suggestions or personal experience of how design fits into agile
            > would be appreciated.
            >
            > Thanks
            >
            > Emma
            >
          • Emma G
            Hi Pierre, Interesting to know you re facing the same problems. Our designer is part of our team, but spread across two sprints (and also used on other
            Message 5 of 25 , Jan 10, 2012
            • 0 Attachment
              Hi Pierre,

              Interesting to know you're facing the same problems.

              Our designer is part of our team, but spread across two sprints (and also used on other projects).

              Can you expand on what you mean by the designer being a tech lead - do you mean in terms of guidance and overview of the design being implemented by the rest of the team?

              Your designers working with the BAs is something we seem to do quite a lot of and it seems to work.

              Thanks for your time

              Emma


              --- In scrumdevelopment@yahoogroups.com, Pierre Neis <pierreneis@...> wrote:
              >
              > Hi Emma,
              >
              > In my teams (coaching a program with developers, analysts and separated UX
              > Designers), I've been facing the same problems.
              >
              > If you're following Scrum straight then your designer must integrate the
              > Development Team. Now if you need sometimes designer's support, then use it
              > as external force or techlead. Here, for alignment reasons, it can be
              > interesting to have a dedicated US for him/her.
              >
              > - Do you tend to have HTML mock-ups as part of a story (where needed?), [if
              > designer part of the Team, then task is enough; else it's a story] or as
              > part of grooming beforehand [then you must have an internal designer and
              > designer plays TechLead]?
              > - How do you handle design tickets on a story? [see above]
              > - Are there any useful guidelines as to how the design process fits within
              > agile? [Y/N, it's useful to collect data from end users and get their
              > commitment. Make sense in the early development phases when you have few to
              > show and during the process when you have to fix tech debt.]
              > - What is your sign-off process for design and at what stage does this
              > happen (e.g. desk demo of HTML, or when the design has been integrated into
              > the developed page) [at current program, designers are involved since the
              > beginning and supports Product Owners and Business Analysts. Designers are
              > pair-working with BA to test business cases.]
              >
              > Hope it helps a bit.
              >
              > *Pierre E. NEIS*, *csp*
              >
              > *PMO @ coPROcess S.A. **â"‚ Scrum & Lean Coach *
              >
              > *M*: +352 / 661 727 867 - *Skype*: pierre.neis
              > *Meet with* me: http://meetwith.me/pierreneis
              >
              > *
              > *
              >
              > [image: Blogger] <http://managingagile.blogspot.com> [image:
              > Twitter]<http://twitter.com/elpedromajor> [image:
              > LinkedIn] <http://lu.linkedin.com/in/pierreneis> [image:
              > SlideShare]<http://www.slideshare.net/PierreNeis>
              > Contact me: [image: Google Talk] pierreneis@... [image: Skype]pierre.neis
              > “"Molesters Do Not Wear an Ugly Mask. They Wear A Shield of Trust." - Patty
              > Rase Hopson<http://www.quotesdaddy.com/quote/1390235/patty-rase-hopson/molesters-do-not-wear-an-ugly-mask-they-wear-a-shield>
              > ” Get this email app!
              > <http://www.wisestamp.com/apps/quotes?utm_source=extension&utm_medium=email&utm_term=quotes&utm_campaign=apps>
              >
              > [image: Twitter] <http://twitter.com/elPedroMajor>Latest tweet: @da_chrisch
              > @scrumphony if I understand: I can't weir my favorite tie? Follow
              > @elPedroMajor <http://twitter.com/elPedroMajor> Reply
              > <http://twitter.com/?status=@elPedroMajor%20&in_reply_to_status_id=152746213391863800&in_reply_to=elPedroMajor>
              > Retweet
              > <http://twitter.com/?status=RT%20%40elPedroMajor%3A%20%40da_chrisch%20%40scrumphony%20if%20I%20understand%3A%20I%20can't%20weir%20my%20favorite%20tie%3F>
              > 14:41 Dec-30<http://twitter.com/elPedroMajor/statuses/152746213391863808>
              > Get a signature like this.
              > <http://r1.wisestamp.com/r/landing?promo=17&dest=http%3A%2F%2Fwww.wisestamp.com%2Femail-install%3Futm_source%3Dextension%26utm_medium%3Demail%26utm_campaign%3Dpromo_17>
              > CLICK
              > HERE.<http://r1.wisestamp.com/r/landing?promo=17&dest=http%3A%2F%2Fwww.wisestamp.com%2Femail-install%3Futm_source%3Dextension%26utm_medium%3Demail%26utm_campaign%3Dpromo_17>
              >
              >
              >
              > On 30 December 2011 17:26, Emma G <emmagarland77@...> wrote:
              >
              > > - Do you tend to have HTML mock-ups as part of a story (where needed?), or
              > > as part of grooming beforehand?
              > > - How do you handle design tickets on a story?
              > > - Are there any useful guidelines as to how the design process fits within
              > > agile?
              > > - What is your sign-off process for design and at what stage does this
              > > happen (e.g. desk demo of HTML, or when the design has been integrated into
              > > the developed page)
              > >
              >
            • Emma G
              Hi Andrew, Good to hear you ve tried this approach too and thanks for the advice on how to get it to work. Do your team not use headphones at all then? I can
              Message 6 of 25 , Jan 10, 2012
              • 0 Attachment
                Hi Andrew,

                Good to hear you've tried this approach too and thanks for the advice on how to get it to work.

                Do your team not use headphones at all then? I can see both sides of this, the only thing is when working on something particularly complex, e.g. coding a complex method or analysing a difficult business process, where you really need to concentrate, I think headphones can be useful.

                We tend to have a mixture of design stories and design tickets on stories. So do you do the design iteratively rather than before you start the story? We are thinking of using Balsamiq where needed instead of mock-ups.

                We have started trying to iron out our definition of DONE. There is a list of all tasks that may form a done story (e.g. BDD, CMS'd up etc), and then each story is tasked up appropriately as not all stories require each task of done. This is something new we have introduced after feedback during the retrospectives.

                Looking at the product frequently: so the product owner and rest of team reviewing the product throughout the sprint presumably?

                Working software by the end of the sprint is the goal indeed, and it's good to have this in the front of our minds.

                Thanks

                Emma



                --- In scrumdevelopment@yahoogroups.com, Andrew Burrows <andy@...> wrote:
                >
                > Hey Emma,
                >
                > I'm the scrum master on a team developing social games for Facebook. We
                > work in exactly the way Steve Ropa described in his email earlier today. We
                > haven't always, and it was a big step for the team to move away from a lot
                > of pre-design - design documents, wireframes, comps, etc.... The best thing
                > you can do to aid the transition is to establish an environment where the
                > team is eager to improve, ready for intense collaboration (it's not a great
                > environment for devs with headphones and they should be ready for the
                > change) and not afraid of failing a few times while you iron out the
                > process.
                >
                > From your end, clarity on story requirements is vital. If you feel that
                > your definitions of done for stories are vague, work on tightening them up.
                > A team should know where they need to get to, and then figure out how to
                > get there during the sprint. You should also look at your product
                > frequently during a sprint to asses the work you're producing, ensure
                > you're still moving in the right direction, or if it's just not working out
                > and you can reward the team for failing fast.
                >
                > (It may sound weird, but failure is a big advantage of working this way. By
                > your earlier emails, you currently have a sprint of design followed by a
                > sprint of implementation. If you run 5 day sprints, the earliest you'll
                > find that you don't like the product is probably 6 days (assuming 5 days of
                > design, then reviewing the first day of implementation work). By focusing
                > on working software, you can find out you don't like the product much
                > faster, and then fix it sooner. :) )
                >
                > Good luck,
                >
                > Andrew
                >
                > On Wed, Jan 4, 2012 at 12:38 PM, Emma G <emmagarland77@...> wrote:
                >
                > > **
                > >
                > >
                > > Hi Dave,
                > >
                > > The point you make about the team members being willing to do anything for
                > > the sprint, similarly to Steve's point about developers trying out
                > > designing a page, has struck home. It is sometimes too easy to stick to
                > > predefined roles, and not think outside the realms of what you normally do.
                > >
                > > Everyone getting involved in testing for example, in order to get the
                > > sprint finished, is something we realise we need to be more proactive at
                > > doing in order to get a story done, rather than taking on a new story.
                > >
                > > Great feedback everyone, I have fed back to the team already and I think I
                > > will bring these points up in the retro.
                > >
                > > Thanks
                > >
                > > Emma
                > >
                > >
                > > --- In scrumdevelopment@yahoogroups.com, David A Barrett <dave.barrett@>
                > > wrote:
                > > >
                > > > To me this doesn't sound like anything particular to "design", but
                > > simply
                > > > that you've got an external resource to manage.
                > > >
                > > > I've found that the defining element that makes a person a team member
                > > is
                > > > whether or not they would do *anything* to move the project along. This
                > > > could be stuffing envelopes, cleaning whiteboards, solving quadratic
                > > > equations, double checking calculations, testing GUI's, maybe even
                > > coding
                > > > --- anything, even if it isn't within their speciality. If somebody
                > > isn't
                > > > available to do *anything* when the project needs it, then they're not a
                > > > team member. End of discussion.
                > > >
                > > > People that aren't team members are, for lack of a better term, an
                > > > external resource. From a Scrum context, it's best to treat them as
                > > such.
                > > > As chickens, if you like. So they don't come to daily standups, and they
                > > > aren't part of retrospectives and so on. What that means is that the
                > > team
                > > > takes responsibility for the work that the external resource is supposed
                > > > to deliver, and they figure out a way to manage that resource. That
                > > > could mean coordinating with other teams that share the resource,
                > > defining
                > > > how the work is passed to the resource, monitoring progress and all of
                > > the
                > > > other stuff that comes up.
                > > >
                > > > But if you try to treat them like they are a team member, you'll have
                > > all
                > > > kinds of insoluble problems and probably end up saying something like,
                > > > "Scrum doesn't handle this well".
                > > >
                > > >
                > > >
                > > > Dave Barrett
                > > >
                > > >
                > > > This e-mail may be privileged and/or confidential, and the sender does
                > > not
                > > > waive any related rights and obligations. Any distribution, use or
                > > copying
                > > > of this e-mail or the information it contains by other than an intended
                > > > recipient is unauthorized. If you received this e-mail in error, please
                > > > delete it and advise me (by return e-mail or otherwise) immediately.
                > > >
                > > > Ce courrier électronique est confidentiel et protégé. L'expéditeur ne
                > > > renonce pas aux droits et obligations qui s'y rapportent. Toute
                > > diffusion,
                > > > utilisation ou copie de ce message ou des renseignements qu'il contient
                > > > par une personne autre que le (les) destinataire(s) désigné(s) est
                > > > interdite. Si vous recevez ce courrier électronique par erreur, veuillez
                > > > le supprimer et m'en aviser immédiatement, par retour de courrier
                > > > électronique ou par un autre moyen.
                > > >
                > >
                > >
                > >
                >
                >
                >
                > --
                > Andrew Burrows
                > Managing Producer, Large Animal Games
                > Call me: 212-989-4312
                > Follow me: @readytoscrumble
                > We're Hiring: http://largeanimal.com/jobs
                >
              • Steve Ropa
                Hi Emma, How is the story adjusted? Just as in adding the discovered Acceptance Criteria? I still vote for aiming your acceptance criteria at what you would
                Message 7 of 25 , Jan 10, 2012
                • 0 Attachment

                  Hi Emma,

                   

                  How is the story adjusted?  Just as in adding the discovered Acceptance Criteria?  I still vote for aiming your acceptance criteria at what you would expect the working software to do, and implement it throughout the sprint.  As you discover new things, you know more about what you really wanted and can adjust on the fly. 

                   

                  Now this will probably result in you discovering that your stories were too big, and you might have a couple of sprints where you feel like you didn’t “get the stories done”.  That’s a good and natural thing.  It will start the process of finding the best way to make your stories smaller.  The way you’ve described your team so far, I think you are definitely up to the challenge.

                   

                  Steve

                   

                  From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Emma G
                  Sent: Tuesday, January 10, 2012 3:29 AM
                  To: scrumdevelopment@yahoogroups.com
                  Subject: [scrumdevelopment] Re: Design process in agile

                   

                   

                  Hi John,

                  Thanks for the reply.

                  We tend to write our acceptance criteria before/during Sprint planning but it sometimes evolves throughout the sprint and the story on the board is adjusted.

                  Do you have a specific design story or add a design ticket on a wider story for example?

                  Thanks

                  Emma

                  --- In scrumdevelopment@yahoogroups.com, "Fagan John" <john.fagan@...> wrote:
                  >
                  > Hi Emma -
                  >
                  >
                  >
                  > We have the same setup as you, 1 designer split across 2 sprint teams.
                  >
                  >
                  >
                  > We treat our design (creative) process like any other story within a
                  > sprint, with its own specific acceptance criteria. The scum team
                  > commits to what they think they can complete based on availability of
                  > the designer. The "sign-off" is the acceptance criteria, which can
                  > happen within a sprint. A story is not done done until these are met.
                  > The AC can contain anything that needs to be met before its done,
                  > including sign off from particular people and/or delivery of relevant
                  > documents (html or image, style guides etc..).
                  >
                  >
                  >
                  > If its quite a big design task, then try break it down, or complete it
                  > in the sprint before implementation.
                  >
                  >
                  >
                  > HTH.
                  >
                  >
                  >
                  > cheers, john
                  >
                  >
                  >
                  > From: scrumdevelopment@yahoogroups.com
                  > [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Emma G
                  > Sent: 30 December 2011 17:26
                  > To: scrumdevelopment@yahoogroups.com
                  > Subject: [scrumdevelopment] Design process in agile
                  >
                  >
                  >
                  >
                  >
                  > I am interested in finding out how to handle the design process within
                  > an agile project.
                  >
                  > I'm a developer on a scrum team. We have one in-house designer who isn't
                  > solely in the sprints as he works for other teams as well. He creates
                  > the initial mock-ups of new pages, and either he or other developers
                  > will integrate this design into our solution during the sprint (usually
                  > as part of a wider story). We don't have an agreed design process yet.
                  >
                  > - Do you tend to have HTML mock-ups as part of a story (where needed?),
                  > or as part of grooming beforehand?
                  > - How do you handle design tickets on a story?
                  > - Are there any useful guidelines as to how the design process fits
                  > within agile?
                  > - What is your sign-off process for design and at what stage does this
                  > happen (e.g. desk demo of HTML, or when the design has been integrated
                  > into the developed page)
                  >
                  > Any suggestions or personal experience of how design fits into agile
                  > would be appreciated.
                  >
                  > Thanks
                  >
                  > Emma
                  >

                • Steve Ropa
                  Hi Emma, About the headphones….its really hard to pair program when someone is wearing headphones! J I really like to work on encouraging folks to work
                  Message 8 of 25 , Jan 10, 2012
                  • 0 Attachment

                    Hi Emma,

                     

                    About the headphones….its really hard to pair program when someone is wearing headphones!  J  I really like to work on encouraging folks to work together.  Headphones are really just portable walls.  That isn’t to say I would *ban* headphones, as that is a fairly command and control kind of thing, but I would put a ton of time and energy into encouraging a more interactive environment.  That complex method becomes much easier to implement when you are working the idea with someone else.

                     

                    From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Emma G
                    Sent: Tuesday, January 10, 2012 3:59 AM
                    To: scrumdevelopment@yahoogroups.com
                    Subject: [scrumdevelopment] Re: Design process in agile

                     

                     

                    Hi Andrew,

                    Good to hear you've tried this approach too and thanks for the advice on how to get it to work.

                    Do your team not use headphones at all then? I can see both sides of this, the only thing is when working on something particularly complex, e.g. coding a complex method or analysing a difficult business process, where you really need to concentrate, I think headphones can be useful.

                    We tend to have a mixture of design stories and design tickets on stories. So do you do the design iteratively rather than before you start the story? We are thinking of using Balsamiq where needed instead of mock-ups.

                    We have started trying to iron out our definition of DONE. There is a list of all tasks that may form a done story (e.g. BDD, CMS'd up etc), and then each story is tasked up appropriately as not all stories require each task of done. This is something new we have introduced after feedback during the retrospectives.

                    Looking at the product frequently: so the product owner and rest of team reviewing the product throughout the sprint presumably?

                    Working software by the end of the sprint is the goal indeed, and it's good to have this in the front of our minds.

                    Thanks

                    Emma

                    --- In scrumdevelopment@yahoogroups.com, Andrew Burrows <andy@...> wrote:
                    >
                    > Hey Emma,
                    >
                    > I'm the scrum master on a team developing social games for Facebook. We
                    > work in exactly the way Steve Ropa described in his email earlier today. We
                    > haven't always, and it was a big step for the team to move away from a lot
                    > of pre-design - design documents, wireframes, comps, etc.... The best thing
                    > you can do to aid the transition is to establish an environment where the
                    > team is eager to improve, ready for intense collaboration (it's not a great
                    > environment for devs with headphones and they should be ready for the
                    > change) and not afraid of failing a few times while you iron out the
                    > process.
                    >
                    > From your end, clarity on story requirements is vital. If you feel that
                    > your definitions of done for stories are vague, work on tightening them up.
                    > A team should know where they need to get to, and then figure out how to
                    > get there during the sprint. You should also look at your product
                    > frequently during a sprint to asses the work you're producing, ensure
                    > you're still moving in the right direction, or if it's just not working out
                    > and you can reward the team for failing fast.
                    >
                    > (It may sound weird, but failure is a big advantage of working this way. By
                    > your earlier emails, you currently have a sprint of design followed by a
                    > sprint of implementation. If you run 5 day sprints, the earliest you'll
                    > find that you don't like the product is probably 6 days (assuming 5 days of
                    > design, then reviewing the first day of implementation work). By focusing
                    > on working software, you can find out you don't like the product much
                    > faster, and then fix it sooner. :) )
                    >
                    > Good luck,
                    >
                    > Andrew
                    >
                    > On Wed, Jan 4, 2012 at 12:38 PM, Emma G <emmagarland77@...> wrote:
                    >
                    > > **
                    > >
                    > >
                    > > Hi Dave,
                    > >
                    > > The point you make about the team members being willing to do anything for
                    > > the sprint, similarly to Steve's point about developers trying out
                    > > designing a page, has struck home. It is sometimes too easy to stick to
                    > > predefined roles, and not think outside the realms of what you normally do.
                    > >
                    > > Everyone getting involved in testing for example, in order to get the
                    > > sprint finished, is something we realise we need to be more proactive at
                    > > doing in order to get a story done, rather than taking on a new story.
                    > >
                    > > Great feedback everyone, I have fed back to the team already and I think I
                    > > will bring these points up in the retro.
                    > >
                    > > Thanks
                    > >
                    > > Emma
                    > >
                    > >
                    > > --- In scrumdevelopment@yahoogroups.com, David A Barrett <dave.barrett@>
                    > > wrote:
                    > > >
                    > > > To me this doesn't sound like anything particular to "design", but
                    > > simply
                    > > > that you've got an external resource to manage.
                    > > >
                    > > > I've found that the defining element that makes a person a team member
                    > > is
                    > > > whether or not they would do *anything* to move the project along. This
                    > > > could be stuffing envelopes, cleaning whiteboards, solving quadratic
                    > > > equations, double checking calculations, testing GUI's, maybe even
                    > > coding
                    > > > --- anything, even if it isn't within their speciality. If somebody
                    > > isn't
                    > > > available to do *anything* when the project needs it, then they're not a
                    > > > team member. End of discussion.
                    > > >
                    > > > People that aren't team members are, for lack of a better term, an
                    > > > external resource. From a Scrum context, it's best to treat them as
                    > > such.
                    > > > As chickens, if you like. So they don't come to daily standups, and they
                    > > > aren't part of retrospectives and so on. What that means is that the
                    > > team
                    > > > takes responsibility for the work that the external resource is supposed
                    > > > to deliver, and they figure out a way to manage that resource. That
                    > > > could mean coordinating with other teams that share the resource,
                    > > defining
                    > > > how the work is passed to the resource, monitoring progress and all of
                    > > the
                    > > > other stuff that comes up.
                    > > >
                    > > > But if you try to treat them like they are a team member, you'll have
                    > > all
                    > > > kinds of insoluble problems and probably end up saying something like,
                    > > > "Scrum doesn't handle this well".
                    > > >
                    > > >
                    > > >
                    > > > Dave Barrett
                    > > >
                    > > >
                    > > > This e-mail may be privileged and/or confidential, and the sender does
                    > > not
                    > > > waive any related rights and obligations. Any distribution, use or
                    > > copying
                    > > > of this e-mail or the information it contains by other than an intended
                    > > > recipient is unauthorized. If you received this e-mail in error, please
                    > > > delete it and advise me (by return e-mail or otherwise) immediately.
                    > > >
                    > > > Ce courrier électronique est confidentiel et protégé. L'expéditeur ne
                    > > > renonce pas aux droits et obligations qui s'y rapportent. Toute
                    > > diffusion,
                    > > > utilisation ou copie de ce message ou des renseignements qu'il contient
                    > > > par une personne autre que le (les) destinataire(s) désigné(s) est
                    > > > interdite. Si vous recevez ce courrier électronique par erreur, veuillez
                    > > > le supprimer et m'en aviser immédiatement, par retour de courrier
                    > > > électronique ou par un autre moyen.
                    > > >
                    > >
                    > >
                    > >
                    >
                    >
                    >
                    > --
                    > Andrew Burrows
                    > Managing Producer, Large Animal Games
                    > Call me: 212-989-4312
                    > Follow me: @readytoscrumble
                    > We're Hiring: http://largeanimal.com/jobs
                    >

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