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

RE: [scrumdevelopment] Re: Design process in agile

Expand Messages
  • 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 1 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.