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

Re: [scrumdevelopment] Scrum Principle: Cross-Functional Team

Expand Messages
  • Adam Sroka
    ... From my various interactions with Ron I think that he intended for the statement to be troubling in its implications. Is it also true? Seems to me that it
    Message 1 of 34 , Aug 3, 2010
    • 0 Attachment
      On Tue, Aug 3, 2010 at 4:02 PM, Geoffrey <geoffrey_slinker@...> wrote:
      >
      >
      >
      > "From the Agile viewpoint, what we have here is a fundamental violation of the Scrum principle that the software must be done by a cross-functional team: a team that has all the skills needed to do the project. This team doesn't have the design skills to do the project … and therefore they are not an Agile team at all!"
      >
      > http://xprogramming.com/articles/can-doing-something-anti-agile-be-more-effective
      >
      > If a team has all of the skills needed to do a project then any process management methodology and any software development methodology would most likely be successful.
      >
      > If a team does not have the skills needed to do a project then any process management methodology and any software development methodology will fail.
      >
      > I find the quote at the beginning to be troubling in its implications. Is it saying, "Hey, you can't blame Agile because YOU didn't have a properly skilled team."
      >

      From my various interactions with Ron I think that he intended for the
      statement to be troubling in its implications. Is it also true? Seems
      to me that it is. So what do we do about it?

      > Is this Scrum principle in conflict with "people before process"?

      Ron is saying that a group of people who has the necessary skills will
      find the processes and tools that work. That is in complete alignment
      with what the Agile Manifesto says (And he is calling that approach
      "Agile.")

      However, a group of people without the necessary skills will have a
      hard time getting the processes and tools to work. Ron suggests that
      you might be able to game the results by telling this group of people
      which processes and tools to use. That would not be a particularly
      "Agile" approach, because it is in conflict with "Individuals and
      Interactions over processes and tools." It might work. There is
      evidence that it has worked in the past, but the success rate is not
      very high.

      I don't know if Ron is right, but I suspect he is on the right track.
      The implication is this:

      Either (a) build a cross-functional team and *do not* tell them how to
      do it. They will figure it out.
      Or (b) hire the cheapest folks you can find and tell them how to do
      it. This is risky, but probably better than nothing.

      I know from experience that (a) works if you do it well. I know from
      experience that (b) may or may not work regardless of how well you do
      it. I know from experience that the following are fraught with peril:

      (c) build a cross functional team and tell them how to do it -- This
      is even more risky than (b) because the team is more likely to revolt.
      The chance of success is only slightly higher than (b) and depends on
      heroics.
      (d) hire the cheapest folks that you can find and let them
      self-organize -- This will almost certainly fail to produce results
      and is the source of many failed "Agile adoptions."
    • Monde Hans
      I think also team based organizations do need leaders and there should be a succession plan for CTO and the like. I read this book years ago before starting
      Message 34 of 34 , Aug 6, 2010
      • 0 Attachment
        I think also team based organizations do need leaders and there should be a succession plan for CTO and the like.
        I read this book years ago before starting with scrum and it deals with some of your concerns.

        http://www.amazon.com/Empowered-Teams-Richard-S-Wellins/dp/1555425542/ref=sr_1_1?ie=UTF8&s=books&qid=1281101525&sr=8-1

        M.

        On Fri, Aug 6, 2010 at 3:24 PM, Satish Thatte <smthatte@...> wrote:
         

        Hello Ron,

         

         From my own experience (in a role of traditional project manager in my past industry experience), project plans elaborated with Gnatt charts,  etc., do not work well for software projects, unless the project requirements/scope is very stable, technology platform is very stable, there are very low risks, and it’s a simple, small, short duration project… and that is a rare occurrence indeed.

         

        Regards,

        Satish Thatte

        CEO, New Synergy Group

        www.NewSynergyGroup.com

         

        From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Ron Jeffries
        Sent: Thursday, August 05, 2010 9:22 PM


        To: scrumdevelopment@yahoogroups.com
        Subject: Re: [scrumdevelopment] Career paths for Scrum Team members

         

         

        Hello, Satish. On Thursday, August 5, 2010, at 7:40:49 PM, you


        wrote:

        > In traditional project management, project managers still prepare elaborate
        > project plans (with Gantt charts, etc.) and tell each project members their
        > tasks, start and due dates, task dependencies, etc., and then try to track
        > or manage them.

        How's that working for them? :)

        Ron Jeffries
        www.XProgramming.com
        www.xprogramming.com/blog
        The opinions expressed here /are/ necessarily those of XProgramming.com.
        But I might change my mind.

        No virus found in this incoming message.
        Checked by AVG - www.avg.com
        Version: 9.0.851 / Virus Database: 271.1.1/3050 - Release Date: 08/06/10 03:37:00




        --
        I keep six honest serving-men (They taught me all I knew); Their names are What and Why and When And How and Where and Who.
      Your message has been successfully submitted and would be delivered to recipients shortly.