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

Re: [scrumdevelopment] Re: Scrum and specialists

Expand Messages
  • George Dinwiddie
    Gustavo ... Sit around one table and pair frequently, discuss the work constantly, and I think you ll find everyone comes to learn all the parts. ... I don t
    Message 1 of 16 , Jun 20, 2011
    • 0 Attachment
      Gustavo

      On 6/16/11 1:26 PM, gustavonarea_tech wrote:
      > Hello, George.
      >
      >
      > --- In scrumdevelopment@yahoogroups.com, George Dinwiddie<lists@...>
      > wrote:
      >>
      >> Gustavo,
      >>
      >> On 6/15/11 1:32 PM, gustavonarea_tech wrote:
      >>> Assume all the members of the team are happy to wear whatever
      >>> hat (tester, designer, etc) is necessary. However, because of
      >>> their background, they know some areas better than others, to the
      >>> extend that some people don't know anything about a particular
      >>> area. If they try and do some work in an area of expertise they
      >>> have no experience with, should their work be at least reviewed
      >>> by someone more experienced in that area? Or should the expert be
      >>> consulted before the work is done? For example, say I've always
      >>> been a coder and haven't even bothered to even read about UI
      >>> before, but I'm willing to do some UI-related work while the rest
      >>> of the team are busy. Should I go ahead or should that task be
      >>> put on hold until someone better suitable is free?
      >>
      >> Is this a hypothetical situation or an actual one? Are the team
      >> members responsible adults who want the project to succeed, or are
      >> they workers who do what they're told? (Or something else?) Are
      >> you asking on their behalf, or are you asking to know what to tell
      >> them?
      >>
      >> The answers I would give depend on the answers to these questions.
      >
      > This is an actual situation. No-one in the team I work has all the
      > capabilities. We're a team of 6 people maintaining a Web site: 3
      > back-end developers, 1 front-end developer, the PM/tester and the CTO,
      > but we're happy to trade "roles".

      Sit around one table and pair frequently, discuss the work constantly,
      and I think you'll find everyone comes to learn all the parts.


      >>> What if a significant part of the project/Sprint is done by an
      >>> external team? Say you're part of an in-house team that maintains
      >>> a system, but a significant redesign of part of the system is
      >>> commissioned to a third party who specializes in User Interface
      >>> and Experience -- Something no-one in your team has extensive
      >>> experience with. They would be in charge of the requirements
      >>> gathering and UI design, with your team playing a *mostly passive
      >>> role* at those stages, leading to a waterfall-y process in the
      >>> beginning. Would you start applying Scrum once your team gets the
      >>> UI design documentation? Or should this whole project be handle
      >>> in a different way more compliant with Scrum? If it's the latter,
      >>> I don't know what exactly it'd mean (start implementing the early
      >>> design drafts?).
      >>
      >> As Ron says, don't do it that way. You're just asking for heartache.
      >>
      >> You might get the outside experts to join your team for the
      >> duration (or your team join them). Or, if they're ONLY doing UX
      >> exploration and UI design, they should join your Product Owner, and
      >> be involved during the implementation. It really doesn't work to
      >> treat the requirements and design of the GUI separately from the
      >> requirements and design of the rest of the system, whether you're
      >> doing Scrum or not.
      >
      > They would also be available during development and testing, to validate
      > the working product. Would that be OK or less bad in Scrum?

      I don't recommend taking a phased approach like that. Don't do the
      design up front, then do development and testing. Do design,
      development, and testing all the way through. Even UI stuff.

      Sure, that may be foreign to them. Sure, they may have to sketch some
      stuff out to help them think things through. But don't wait for a
      complete design. Get the basics, start developing that, and then refine
      as you go.


      >> See Ron's most recent Kate Oneal story for a great description of
      >> how it should work.
      >
      > Thanks, I'll have a look.
      >
      >
      >>> I can see the ultimate goal is to be a generalizing specialist,
      >>> but my concern is mainly when the team is new to Scrum and not
      >>> all the members have all the capabilities needed in the project.
      >>> At this early stage, is it OK to be less strict? For example, not
      >>> having someone doing some work that requires a capability he
      >>> doesn't have, even if he's happy to do it?
      >>
      >> Again, are these responsible adults who want the project to succeed?
      >> Can they work together to spread the knowledge they have? Can they
      >> learn the things that the team needs to learn? Can they work together
      >> to make sure things work out?
      >
      > Yes, yes, yes, yes.

      Good!


      >> I don't understand your phrase "having someone doing some work."
      >> Who is assigning work to people? Have you tried promiscuous
      >> pairing and volunteering for work?
      >
      > Normally, we developers organize the tasks, but discrete tasks are
      > usually assigned by the PM.

      How can the team members work together to make sure things work out if
      they can't even be trusted to choose their own tasks? There's something
      wrong in this description.

      > We haven't done any pair programming sort of thing. UI, architecture and
      > low-level design is usually reviewed by at least one person.

      The answers to your questions are fairly simple, but only if the team
      members self-organize and choose to solve the problems. If they're
      being directed how to work, then it's unlikely to solve the problem.
      There really is that much difference in the two ways of working.

      - George

      --
      ----------------------------------------------------------------------
      * George Dinwiddie * http://blog.gdinwiddie.com
      Software Development http://www.idiacomputing.com
      Consultant and Coach http://www.agilemaryland.org
      ----------------------------------------------------------------------
    Your message has been successfully submitted and would be delivered to recipients shortly.