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

Self organization. How?

Expand Messages
  • unmesh_joshi
    Hi, Self organizing teams is heart of scrum. But I am not sure if self organization without some guiding principles is possible. It is reflected in org pattern
    Message 1 of 16 , Apr 30 3:25 AM
    View Source
    • 0 Attachment
      Hi,

      Self organizing teams is heart of scrum. But I am not sure if self
      organization without some guiding principles is possible.
      It is reflected in org pattern "Developer controls process". But what
      do you think are pre-requisites for development team to be considered
      fit for self-organization?
      I will like to know if there is any literature available that
      discusses practical examples of self organization in more details.

      Thanks,
      Unmesh
    • David H.
      ... Hello. ... What are you most interested in, could you elaborate a bit on what you are trying to learn about? There are many factors which are already in
      Message 2 of 16 , Apr 30 3:55 AM
      View Source
      • 0 Attachment
        >
        > Hi,
        >
        Hello.

        > I will like to know if there is any literature available that
        > discusses practical examples of self organization in more details.
        >
        What are you most interested in, could you elaborate a bit on what you
        are trying to learn about? There are many factors which are already in
        scrum. such as Time boxing, Sprint goals among many others. These are
        influencing factors for a proper selforganisation setup. However if
        you want to understand the guiding scientifc reasons behind it whcih
        do not necessarily fully apply to human beings, have a look here:

        http://www.calresco.org/tutorial.htm
        and
        http://www.calresco.org/sos/sosfaq.htm

        -d


        --
        Sent from gmail so do not trust this communication.
        Do not send me sensitive information here, ask for my none-gmail accounts.

        "Therefore the considerations of the intelligent always include both
        benefit and harm." - Sun Tzu
      • unmesh_joshi
        ... I was more curious to know how senior management will be convinced that team of junior developers can self-organize? For example, If we need effective self
        Message 3 of 16 , Apr 30 9:39 PM
        View Source
        • 0 Attachment
          > What are you most interested in, could you elaborate a bit on what
          > you are trying to learn about? There are many factors which are
          > already in scrum. such as Time boxing, Sprint goals among many
          > others. These are
          I was more curious to know how senior management will be convinced
          that team of junior developers can self-organize? For example,
          If we need effective self organizing dev team, we probably need to
          do TDD and continuous integration.
          Then we can tell senior management that if developers are good at
          these and these engineering practices and allowed to self organize
          their work, they are more productive. I think just time boxed
          iterations, or sprint goals are not enough?

          Thanks for your pointers on science of self organization. Its
          interesting to read.

          Thanks,
          Unmesh



          --- In scrumdevelopment@yahoogroups.com, "David H." <dmalloc@...>
          wrote:
          >
          > >
          > > Hi,
          > >
          > Hello.
          >
          > > I will like to know if there is any literature available that
          > > discusses practical examples of self organization in more
          details.
          > >
          > What are you most interested in, could you elaborate a bit on what
          you
          > are trying to learn about? There are many factors which are
          already in
          > scrum. such as Time boxing, Sprint goals among many others. These
          are
          > influencing factors for a proper selforganisation setup. However if
          > you want to understand the guiding scientifc reasons behind it
          whcih
          > do not necessarily fully apply to human beings, have a look here:
          >
          > http://www.calresco.org/tutorial.htm
          > and
          > http://www.calresco.org/sos/sosfaq.htm
          >
          > -d
          >
          >
          > --
          > Sent from gmail so do not trust this communication.
          > Do not send me sensitive information here, ask for my none-gmail
          accounts.
          >
          > "Therefore the considerations of the intelligent always include
          both
          > benefit and harm." - Sun Tzu
          >
        • Nicholas Cancelliere
          What makes senior developers any more effective at self-organization? Nicholas
          Message 4 of 16 , May 1, 2007
          View Source
          • 0 Attachment

            What makes senior developers any more effective at self-organization?

            Nicholas


            On Apr 30, 2007, at 11:39 PM, unmesh_joshi wrote:


            > What are you most interested in, could you elaborate a bit on what
            > you are trying to learn about? There are many factors which are
            > already in scrum. such as Time boxing, Sprint goals among many
            > others. These are
            I was more curious to know how senior management will be convinced
            that team of junior developers can self-organize? For example,
            If we need effective self organizing dev team, we probably need to
            do TDD and continuous integration.
            Then we can tell senior management that if developers are good at
            these and these engineering practices and allowed to self organize
            their work, they are more productive. I think just time boxed
            iterations, or sprint goals are not enough?

            Thanks for your pointers on science of self organization. Its
            interesting to read.

            Thanks,
            Unmesh

            --- In scrumdevelopment@yahoogroups.com, "David H." <dmalloc@...>
            wrote:
            >
            > >
            > > Hi,
            > >
            > Hello.
            >
            > > I will like to know if there is any literature available that
            > > discusses practical examples of self organization in more
            details.
            > >
            > What are you most interested in, could you elaborate a bit on what
            you
            > are trying to learn about? There are many factors which are
            already in
            > scrum. such as Time boxing, Sprint goals among many others. These
            are
            > influencing factors for a proper selforganisation setup. However if
            > you want to understand the guiding scientifc reasons behind it
            whcih
            > do not necessarily fully apply to human beings, have a look here:
            >
            > http://www.calresco.org/tutorial.htm
            > and
            > http://www.calresco.org/sos/sosfaq.htm
            >
            > -d
            >
            >
            > --
            > Sent from gmail so do not trust this communication.
            > Do not send me sensitive information here, ask for my none-gmail
            accounts.
            >
            > "Therefore the considerations of the intelligent always include
            both
            > benefit and harm." - Sun Tzu
            >


          • Peter Hundermark
            ... organization? ... This question is troubling me too. We have been using Scrum for a few months now and senior management continues not to trust teams to
            Message 5 of 16 , May 2, 2007
            View Source
            • 0 Attachment
              --- In scrumdevelopment@yahoogroups.com, Nicholas Cancelliere
              <nickaustin74@...> wrote:
              >
              >
              > What makes senior developers any more effective at self-
              organization?
              >
              > Nicholas
              >

              This question is troubling me too. We have been using Scrum for a few
              months now and senior management continues not to trust teams to self-
              organise. Perhaps more accurately they do not trust that the delivery
              of a self-organised team is optimised.

              So I hear statements like: "If I created a team comprising only
              experienced people, they would self-organise to do the work
              efficiently, but I don't think an inexperienced (or mixed) team can
              do this. We must retain a Project Leader role [within the team] who
              will tell the team what to do when they fail to self-organise." Even
              good PO's appear to be be frustrated by their inability to direct the
              team [via a single point of contact - the PL]. The SM is seen as a
              feminine/motherhood role lacking in 'fatherly' qualities.

              Ken [Schwaber] often says you can take a cr*p team and in a month
              they'll deliver you cr*p (my paraphrase), but this does not directly
              address the perceived leadership vacuum propagated by Scrum.

              So my questions are (I think):
              1. Does work (and life) experience influence a team's ability to self-
              organise?
              2. How does one accommodate an organisation's anxiety about the
              perceived loss of control that Scrum brings about.

              Thanks,

              PH
            • Mark Graybill
              Peter, 1: Yes with caveats. 2: Suffering in this regard is ubiquitous, but examine why do scrum? 1: Caveats: You need to understand what sort of influence and
              Message 6 of 16 , May 2, 2007
              View Source
              • 0 Attachment

                Peter,

                 

                1: Yes with caveats.

                2: Suffering in this regard is ubiquitous, but examine why do scrum?

                 

                1: Caveats: You need to understand what sort of influence and how you are using the answer, but also all the other individual and group variables involved.  Work and life experience (or lack thereof) for one individual can not only equip them or cripple them in the self-organizing process, but it also can catalyze or hinder how others participate. 

                 

                We all suffer from the desire to neatly package things into something simple and generalized; unfortunately reality is often too complicated for our packaging needs. The endeavor of packaging people is perhaps one of the most common examples of such a dilemma.

                 

                There are so many variables behind each individual that can influence their participation in the self-organizing process to isolate just one of them (such as experience level) for a generalized conclusion, although there may be those experienced with teams who might disagree.  My question to them is how well have they detected and minimized their biases and the influence of their biases on their conclusions, because the global literature related to this topic says otherwise.   But mostly, few are trained on and aware of all the involved variables.

                 

                I'm not trying to pick on anyone but to prove a point.  Team members can be all experienced or all inexperienced - or some mix, but their individual make-ups impose the most significant factor that can contribute or detract from the process of self-organization.  I know what you're thinking - you don’t want to hear that - management wants cookie-cutter and operationalized ways to control their world and this just throws a monkey wrench into their tidy managerial cogs.  However, there is some hope in the fact there can be group variables that can have an overriding effect, such as good leadership, bad leadership or no leadership (to over-generalize), that can be capitalized on.

                 

                2: Such is my lot in life at present.  The two world views can be so incompatible, and though you might have some success with an analogy (e.g. control a team of English majors to write the next best selling novel), the fact remains those in upper management often do not understand the essence of software development and the essence of people as operating in their world.  If they did, a paradigm shift would be much easier for them. 

                 

                I've found two things certain: I must buffer the incompatible agendas and formats, and I must convince upper management to trust me.  Just as a scrum master (project manager, team lead, whatever) must learn how to trust their team to make mistakes and expect mistakes in the process of them coming together, I think we have to convince upper management to trust us.

                 

                So there's my two cents worth. :)

                 

                Cheers!
                Mark

                 
                 
                ----- Original Message -----
                Sent: Wednesday, May 02, 2007 5:17 AM
                Subject: [scrumdevelopment] Re: Self organization. How?

                --- In scrumdevelopment@ yahoogroups. com, Nicholas Cancelliere
                <nickaustin74@ ...> wrote:
                >
                >
                > What makes senior developers any more effective at self-
                organization?
                >
                > Nicholas
                >

                This question is troubling me too. We have been using Scrum for a few
                months now and senior management continues not to trust teams to self-
                organise. Perhaps more accurately they do not trust that the delivery
                of a self-organised team is optimised.

                So I hear statements like: "If I created a team comprising only
                experienced people, they would self-organise to do the work
                efficiently, but I don't think an inexperienced (or mixed) team can
                do this. We must retain a Project Leader role [within the team] who
                will tell the team what to do when they fail to self-organise. " Even
                good PO's appear to be be frustrated by their inability to direct the
                team [via a single point of contact - the PL]. The SM is seen as a
                feminine/motherhood role lacking in 'fatherly' qualities.

                Ken [Schwaber] often says you can take a cr*p team and in a month
                they'll deliver you cr*p (my paraphrase), but this does not directly
                address the perceived leadership vacuum propagated by Scrum.

                So my questions are (I think):
                1. Does work (and life) experience influence a team's ability to self-
                organise?
                2. How does one accommodate an organisation' s anxiety about the
                perceived loss of control that Scrum brings about.

                Thanks,

                PH

              • Nicholas Cancelliere
                To your first point, yes. I would more agree age/experience has a lot more to do with being able to self-organize than technical prowess does. After all -
                Message 7 of 16 , May 2, 2007
                View Source
                • 0 Attachment
                   
                  To your first point, yes.  I would more agree age/experience has a lot more to do with being able to self-organize than technical prowess does.  After all - it's only through experience of being on teams and in situations where you have to direct yourself do you gain such skills.  Just being a great Java programmer doesn't make me a great team member. 
                   
                  Honestly, all the managers pre-occupied with "maximizing" output and thigns like this are fooling themselves.  You can do a simple experiment taking a bunch of people in a crowded room with a "manager" standing behind them barking commands.  Everyone has to navigate out of the room (over various obsticles) without bumping into others.  Then try the same experiment with a manager in front of the work clearing the obsticles and see what happens.
                   
                  The point of the exercise is that it's more efficient to let people make their own decisions and for managers to support them by clearning their path to success.  What managers need to learn to do is become servant leaders and to start trust their teams.  Trust is established when the team starts to become predictable and delivering consistently.  Teams trust that their managers will create an environment of success for them, clearning obsticles.


                   
                  On 5/2/07, Peter Hundermark <peterh@...> wrote:

                  --- In scrumdevelopment@yahoogroups.com, Nicholas Cancelliere
                  <nickaustin74@...> wrote:
                  >
                  >
                  > What makes senior developers any more effective at self-
                  organization?
                  >
                  > Nicholas
                  >

                  This question is troubling me too. We have been using Scrum for a few
                  months now and senior management continues not to trust teams to self-
                  organise. Perhaps more accurately they do not trust that the delivery
                  of a self-organised team is optimised.

                  So I hear statements like: "If I created a team comprising only
                  experienced people, they would self-organise to do the work
                  efficiently, but I don't think an inexperienced (or mixed) team can
                  do this. We must retain a Project Leader role [within the team] who
                  will tell the team what to do when they fail to self-organise." Even
                  good PO's appear to be be frustrated by their inability to direct the
                  team [via a single point of contact - the PL]. The SM is seen as a
                  feminine/motherhood role lacking in 'fatherly' qualities.

                  Ken [Schwaber] often says you can take a cr*p team and in a month
                  they'll deliver you cr*p (my paraphrase), but this does not directly
                  address the perceived leadership vacuum propagated by Scrum.

                  So my questions are (I think):
                  1. Does work (and life) experience influence a team's ability to self-
                  organise?
                  2. How does one accommodate an organisation's anxiety about the
                  perceived loss of control that Scrum brings about.

                  Thanks,

                  PH




                  --
                  Nicholas Cancelliere, Austin TX
                  "The wide world is all about you: you can fence yourselves in, but you cannot for ever fence it out." -Gildor, Fellowship of the Ring (Lord of the Rings)
                • Mark Graybill
                  Additional comments... The topic addressed (#1) was whether experience influences the process of self-organization, but perhaps the most interesting (and real)
                  Message 8 of 16 , May 2, 2007
                  View Source
                  • 0 Attachment

                    Additional comments...

                     

                    The topic addressed (#1) was whether experience influences the process of self-organization, but perhaps the most interesting (and real) topic behind the question is how experience influences the group's work output. 

                     

                    With scrum it is all about the team.  Group processes are paramount.  But as dev teams go, work experience is essential for good work output, IMHO.  In some cases perhaps the work output of a trained yet inexperienced well-formed dev team may output similar work output of another very experienced but ill-formed dev team.  But this is just speculation - I don't have any specific data in this regard.

                     

                    Fortunately, facilitating self-organization in principle falls into the same topic mulled over in countless times past, which I've observed touched on somewhat in the scrum master training I attended (kudos to Ken and Mike). 

                     

                    So I think there are three concurrent processes involved in bringing scrum into the organization a scrum master must deal with.

                     

                    1. The dev team achieving competence in and a paradigm shift of how to do software the scrum way (methods) - this includes the SM (key here being paradigm shift).

                    2. The dev team's process of self-organizing (the criticality of team formation is punctuated in scrum over traditional I think).

                    3. Fitting a square scrum team and project into an organization's round hole (no hidden puns intended).

                     

                    At least this is what I'm dealing with.


                    Cheers!
                    Mark

                     
                    ----- Original Message -----
                    Sent: Wednesday, May 02, 2007 8:59 AM
                    Subject: Re: [scrumdevelopment] Re: Self organization. How?

                    Peter,

                    1: Yes with caveats.

                    2: Suffering in this regard is ubiquitous, but examine why do scrum?

                    1: Caveats: You need to understand what sort of influence and how you are using the answer, but also all the other individual and group variables involved.  Work and life experience (or lack thereof) for one individual can not only equip them or cripple them in the self-organizing process, but it also can catalyze or hinder how others participate. 

                    We all suffer from the desire to neatly package things into something simple and generalized; unfortunately reality is often too complicated for our packaging needs. The endeavor of packaging people is perhaps one of the most common examples of such a dilemma.

                    There are so many variables behind each individual that can influence their participation in the self-organizing process to isolate just one of them (such as experience level) for a generalized conclusion, although there may be those experienced with teams who might disagree.  My question to them is how well have they detected and minimized their biases and the influence of their biases on their conclusions, because the global literature related to this topic says otherwise.   But mostly, few are trained on and aware of all the involved variables.

                    I'm not trying to pick on anyone but to prove a point.  Team members can be all experienced or all inexperienced - or some mix, but their individual make-ups impose the most significant factor that can contribute or detract from the process of self-organization.  I know what you're thinking - you don’t want to hear that - management wants cookie-cutter and operationalized ways to control their world and this just throws a monkey wrench into their tidy managerial cogs.  However, there is some hope in the fact there can be group variables that can have an overriding effect, such as good leadership, bad leadership or no leadership (to over-generalize) , that can be capitalized on.

                    2: Such is my lot in life at present.  The two world views can be so incompatible, and though you might have some success with an analogy (e.g. control a team of English majors to write the next best selling novel), the fact remains those in upper management often do not understand the essence of software development and the essence of people as operating in their world.  If they did, a paradigm shift would be much easier for them. 

                    I've found two things certain: I must buffer the incompatible agendas and formats, and I must convince upper management to trust me.  Just as a scrum master (project manager, team lead, whatever) must learn how to trust their team to make mistakes and expect mistakes in the process of them coming together, I think we have to convince upper management to trust us.

                    So there's my two cents worth. :)

                    Cheers!
                    Mark

                     
                     
                    ----- Original Message -----
                    Sent: Wednesday, May 02, 2007 5:17 AM
                    Subject: [scrumdevelopment] Re: Self organization. How?

                    --- In scrumdevelopment@ yahoogroups. com, Nicholas Cancelliere
                    <nickaustin74@ ...> wrote:
                    >
                    >
                    > What makes senior developers any more effective at self-
                    organization?
                    >
                    > Nicholas
                    >

                    This question is troubling me too. We have been using Scrum for a few
                    months now and senior management continues not to trust teams to self-
                    organise. Perhaps more accurately they do not trust that the delivery
                    of a self-organised team is optimised.

                    So I hear statements like: "If I created a team comprising only
                    experienced people, they would self-organise to do the work
                    efficiently, but I don't think an inexperienced (or mixed) team can
                    do this. We must retain a Project Leader role [within the team] who
                    will tell the team what to do when they fail to self-organise. " Even
                    good PO's appear to be be frustrated by their inability to direct the
                    team [via a single point of contact - the PL]. The SM is seen as a
                    feminine/motherhood role lacking in 'fatherly' qualities.

                    Ken [Schwaber] often says you can take a cr*p team and in a month
                    they'll deliver you cr*p (my paraphrase), but this does not directly
                    address the perceived leadership vacuum propagated by Scrum.

                    So my questions are (I think):
                    1. Does work (and life) experience influence a team's ability to self-
                    organise?
                    2. How does one accommodate an organisation' s anxiety about the
                    perceived loss of control that Scrum brings about.

                    Thanks,

                    PH

                  • dnicolet99
                    ... Concerns of this general type suggest an organizational culture in which processes and tools are deemed more important than people and their interactions.
                    Message 9 of 16 , May 2, 2007
                    View Source
                    • 0 Attachment
                      --- In scrumdevelopment@yahoogroups.com, "Peter Hundermark"
                      <peterh@...> wrote:
                      >
                      > --- In scrumdevelopment@yahoogroups.com, Nicholas Cancelliere
                      > <nickaustin74@> wrote:
                      > >
                      > >
                      > > What makes senior developers any more effective at self-
                      > organization?
                      > >
                      > > Nicholas
                      > >
                      >
                      > This question is troubling me too. We have been using Scrum for a few
                      > months now and senior management continues not to trust teams to self-
                      > organise. Perhaps more accurately they do not trust that the delivery
                      > of a self-organised team is optimised.
                      >
                      > So I hear statements like: "If I created a team comprising only
                      > experienced people, they would self-organise to do the work
                      > efficiently, but I don't think an inexperienced (or mixed) team can
                      > do this. We must retain a Project Leader role [within the team] who
                      > will tell the team what to do when they fail to self-organise." Even
                      > good PO's appear to be be frustrated by their inability to direct the
                      > team [via a single point of contact - the PL]. The SM is seen as a
                      > feminine/motherhood role lacking in 'fatherly' qualities.

                      Concerns of this general type suggest an organizational culture in
                      which processes and tools are deemed more important than people and
                      their interactions. It sounds as if (and I've seen this happen, too)
                      management is willing to give Scrum a try only as long as it is easy,
                      and nothing goes awry. As soon as there are problems, their immediate
                      response will be to fall back to a command-and-control approach.

                      It's possible that a program of education/coaching will be necessary
                      to help management understand how and why self-organization works.
                      Maybe a custom workshop or seminar would help get the management team
                      over the initial conceptual hurdles, and following up with a long-term
                      program of ongoing coaching would help propagate and institutionalize
                      the new way of thinking.



                      > Ken [Schwaber] often says you can take a cr*p team and in a month
                      > they'll deliver you cr*p (my paraphrase), but this does not directly
                      > address the perceived leadership vacuum propagated by Scrum.

                      Whether a "leadership vacuum" is perceived may depend on how
                      "leadership" is perceived. See
                      http://www.davenicolette.net/agile/index.blog/1681878/challenges-in-defining-agile-leadership/

                      What do they really mean when they say, "leadership?"


                      > So my questions are (I think):
                      > 1. Does work (and life) experience influence a team's ability to self-
                      > organise?

                      Yes (and yes).


                      > 2. How does one accommodate an organisation's anxiety about the
                      > perceived loss of control that Scrum brings about.

                      Whether a "loss of control" is perceived may depend on how "control"
                      is perceived. See http://en.wikipedia.org/wiki/Illusion_of_control

                      What do they really mean when they say, "control?"

                      Dave
                    • Hunt Sparra
                      ... Are the teams showing progress? I assume functionality is being delived every month. Are you able to use velocity to predict delivery and to show the
                      Message 10 of 16 , May 2, 2007
                      View Source
                      • 0 Attachment
                        --- In scrumdevelopment@yahoogroups.com, "Peter Hundermark" <peterh@...> wrote:
                        >
                        > This question is troubling me too. We have been using Scrum for a few
                        > months now and senior management continues not to trust teams to self-
                        > organise. Perhaps more accurately they do not trust that the delivery
                        > of a self-organised team is optimised.

                        Are the teams showing progress? I assume functionality is being delived every month. Are you able to use velocity to predict delivery and to show the impact of changes? It sounds like management may be focused more on documents than working software. Or, perhaps management is finding out problems that were always hidden by the prior process. Making everything visible and transparent can be a rude awakening.

                        What is meant by optimized? What do you want to optimize for? Speed of delivery, quality, testability, usability,  flexibility, something else?

                        >
                        > So I hear statements like: "If I created a team comprising only
                        > experienced people, they would self-organise to do the work
                        > efficiently, but I don't think an inexperienced (or mixed) team can
                        > do this. We must retain a Project Leader role [within the team] who
                        > will tell the team what to do when they fail to self-organise."

                        Some teams need more guidance at first than other teams. If people are use to being told what to work on and when, they have to "remember" how to have initiative. But telling the team everything that they need to do will result in the team never learning and only doing what they are told. Depending on the SM, they may have to sometimes lead by example.

                        > Even
                        > good PO's appear to be be frustrated by their inability to direct the
                        > team [via a single point of contact - the PL]. The SM is seen as a
                        > feminine/motherhood role lacking in 'fatherly' qualities.

                        Sounds like there is some machismo involved. Last I checked it was the female that carried the young and gave birth ;) Being an SM requires a different type of strength than strength based upon the ability to inflict punishment (C-in-C). Sometimes the SM has to call out the team and ensure they are not making excuses. Many times when people have been under a command and control process they get use to making excuses, however subtle the excuses may be. Sometimes and SM has to perform the difficult task of removing excuses. It takes a certain type of strength to admit that there is a problem/mistake and take the heat or to point out what is not working. In Scrum, soon as someone thinks there is an issue they need to point it out. Now if the SMs are just coddling, then that is an issue that needs to be dealt with.

                        >
                        > 2. How does one accommodate an organisation's anxiety about the
                        > perceived loss of control that Scrum brings about.

                        The first thing you need to do is educate people on what is often perceived as control is not really control. An example of this is the reliance on EVA and the belief that it gives an accurate picture of where the project is at. Most uses of EVA that I have seen do not do this, but instead show how people are marking time against the original project plan, which is different that what has actually been accomplished in most cases. What is 80% done anyway? I am sure you have seen as time goes on the increments become smaller and smaller between the prior update and the next, 25% done => 50% done => 75% done => 80% done => 85% done => 90% done => 91% done => ... Whatever it is that your organization uses to make them feel good, that is what you need to address. You should show how the Scrum tools give an accurate picture and how that is used so management can make informed decisions. It is worth reviewing the tools that your organization is use to using, because they may indeed provide value. Perhaps some you can create easily from your Scrum tools, such as using a Feature Breakdown instead of a Work Breakdown or creating a Gantt chart based on features and sprints instead of tasks.
                      • Zak Jacobson
                        ... Hi- I have a similar question... Let s say you are working in a company that is adopting Scrum. You are in the middle of a multi year project on a team of
                        Message 11 of 16 , Jun 26, 2007
                        View Source
                        • 0 Attachment
                          --- In scrumdevelopment@yahoogroups.com, "unmesh_joshi"
                          <unmesh_joshi@...> wrote:
                          >
                          > Hi,
                          >
                          > Self organizing teams is heart of scrum. But I am not sure if self
                          > organization without some guiding principles is possible.
                          > It is reflected in org pattern "Developer controls process". But what
                          > do you think are pre-requisites for development team to be considered
                          > fit for self-organization?
                          > I will like to know if there is any literature available that
                          > discusses practical examples of self organization in more details.
                          >
                          > Thanks,
                          > Unmesh
                          >

                          Hi-

                          I have a similar question...

                          Let's say you are working in a company that is adopting Scrum. You
                          are in the middle of a multi year project
                          on a team of 25+ developers. You've been "doing Scum" for several
                          months but it's just not clicking with this large team. Team size has
                          been identified as an issue in the Retrospective. The team wants to
                          split up into smaller teams but is having trouble seeing how. What
                          issues might arise if 3-5 teams share a product owner and a
                          ScrumMaster? Would it be best to have a PBL for each team or is it
                          light weight enough to share a PBL? Would it be best to have separate
                          scrums, planning meetings, reviews and retrospectives?

                          Another challenge is silos of knowledge. With one large team, there
                          are "go-to guys" for specific features. For example, one developer
                          practically owns the data access layer. This makes it difficult to
                          see a logical way to form the teams because this developer "needs" to
                          be on all teams. An obvious solution is pair programming to spread
                          the knowledge. Are there any other possible solutions?

                          Another wrinkle... There used to be 3 teams that were not self
                          organized. They were organized along architectural boundaries. This
                          added a lot of dependencies between teams because a story had to be
                          split across 2 or 3 teams. Combining the teams into one "solved" that
                          problem (or did it just mask it until now?). Some people think that
                          splitting up in to smaller teams might lead to the same issues.

                          Thanks for any insight-
                          Zak
                        • Petri Heiramo
                          Hi, ... Ultimately that is up to the team to decide, but I see you re looking for options for the team, which is exactly what I see the SM should be doing. :)
                          Message 12 of 16 , Jun 26, 2007
                          View Source
                          • 0 Attachment
                            Hi,


                            > Let's say you are working in a company that is adopting Scrum. You
                            > are in the middle of a multi year project
                            > on a team of 25+ developers. You've been "doing Scum" for several
                            > months but it's just not clicking with this large team. Team size has
                            > been identified as an issue in the Retrospective. The team wants to
                            > split up into smaller teams but is having trouble seeing how.

                            Ultimately that is up to the team to decide, but I see you're looking
                            for options for the team, which is exactly what I see the SM should be
                            doing. :)

                            First of all, I think it would be good to keep in mind that the team
                            structure need not be permanent. If necessary, the teams can
                            reorganize every sprint. Also, if the cost of splitting up is too
                            high, stay as one team even if it has its own drawbacks.

                            I've seen suggested that the teams should try to find logical
                            functional splits to minimize decoupling between teams'
                            responsibilities. It could also be logical split between stories
                            within one sprint. You might want to trial different team
                            configurations, and see what works and what not. Encourage the team to
                            test organizations and then tune based on practical experience. Some
                            ideas need iteration to get right (they tend to be the more difficult
                            problems).

                            > What issues might arise if 3-5 teams share a product owner and a
                            > ScrumMaster? Would it be best to have a PBL for each team or is it
                            > light weight enough to share a PBL? Would it be best to have separate
                            > scrums, planning meetings, reviews and retrospectives?

                            You might want to consider having a separate SM for each team. That
                            way they can have "local" SM presense.

                            I would not recommend separate sprint planning meetings (the first
                            part with customer), reviews and retrospectives. Those important to be
                            held as the whole project team. The second part of sprint planning and
                            daily scrums would be specific to each team. And then there would be
                            the Scrum of Scrums to which each team would daily send their
                            representatives to keep the teams communicating.

                            For some reason I recall that Henrik Kniberg did discuss the issue of
                            how to do sprint planning with multiple teams, but I can't find the
                            topic with a quick browse of his excellent Scrum and XP from the
                            Treches article
                            (http://www.crisp.se/henrik.kniberg/ScrumAndXpFromTheTrenches.pdf,
                            since it's just such a good read :) ). Maybe you have better luck.

                            Anyway, I think it went something like this. In the first part of the
                            sprint planning meeting, the project team would discuss the top
                            priority items and each team would then select (in co-operation with
                            other teams and the product owner) stories for themselves. After each
                            team is fully committed, they would do one more discussion round
                            whether this split would be okay, or they should do some shuffling
                            around. This shuffling might include either stories or people
                            transferring between the teams.

                            Anyway, this is a very interesting topic, so I would gladly read
                            practical experiences from other people who've solved the issue in
                            their projects.

                            > Another challenge is silos of knowledge. With one large team, there
                            > are "go-to guys" for specific features. For example, one developer
                            > practically owns the data access layer. This makes it difficult to
                            > see a logical way to form the teams because this developer "needs" to
                            > be on all teams. An obvious solution is pair programming to spread
                            > the knowledge. Are there any other possible solutions?

                            Pose this as a challenge to the team and ask them how they would solve
                            the situation. Ask what they would do if this one person is sick or
                            otherwise absent? How are they going to ensure that they can still
                            complete their spring commitments. It _IS_ their responsibility as a
                            self-managing team. They might suggest sharing knowledge through pair
                            programming, or sharing the person (and the possible deputy) between
                            teams based on greatest need in each sprint. It's really up to them.

                            Actually, maybe you could make this "silos" thing a topic in one
                            retrospective, and have them work out a strategy and actions to handle
                            it. Of course, start up with a question "do you see <this and that> a
                            risk or a problem for you in the future?" :). If they think it's not a
                            problem, pose situations where the risk could materialize (like the
                            ones I gave above) and maybe they can see the risk (or you realize
                            through the discussion that they already have mitigated the risk).

                            As to possible solutions, some have mentioned that Dojos are a good
                            way of sharing the knowledge. Could be. :)

                            > Another wrinkle... There used to be 3 teams that were not self
                            > organized. They were organized along architectural boundaries. This
                            > added a lot of dependencies between teams because a story had to be
                            > split across 2 or 3 teams. Combining the teams into one "solved" that
                            > problem (or did it just mask it until now?). Some people think that
                            > splitting up in to smaller teams might lead to the same issues.

                            Possibly very true. You replaced one problem with another challenge.
                            Try to find a new solution that works for both. :)

                            Hope any of this helps,


                            Petri Heiramo
                            Process Improvement Manager
                            SYSOPENDIGIA Plc., Finland
                          • Petri Heiramo
                            Hi, ... The way I see it, yes it does. But not in the traditional sense. If they have practical experience of working as a team, they have a better chance of
                            Message 13 of 16 , Jun 26, 2007
                            View Source
                            • 0 Attachment
                              Hi,


                              > So my questions are (I think):
                              > 1. Does work (and life) experience influence a team's ability to self-
                              > organise?

                              The way I see it, yes it does. But not in the traditional sense. If
                              they have practical experience of working as a team, they have a
                              better chance of working as a self-managing team slso in the future.
                              Of course technical expertise does give more experience to make
                              technical decisions, but that doesn't necessarily translate to
                              self-management.

                              I see proper coaching and support from SM and management as the more
                              important factor in fostering self-management. If you make the team
                              responsible when they do have to make a choice (rather than making the
                              choice for them), they will develop the sense of responsibility (and
                              will not even come to you with their problems, unless they think _you_
                              can act the solution).

                              Conversely, the lack of support from SM and management is the most
                              effective means of killing the self-management.

                              As to the juniors and seniors discussion, of course seniors will make
                              up a more skillful team in means of achieved solutions. They also
                              generally cost more and are harder to find. But they are not
                              necessarily any better at working as a team than juniors are. I would
                              recommend command-and-control only when the juniors are so bad that
                              they really can't come up with any meaningful technical solutions (in
                              other words, they produce cr*p).

                              > 2. How does one accommodate an organisation's anxiety about the
                              > perceived loss of control that Scrum brings about.

                              I see two things: results and visibility.

                              Results is a no-brainer. If there are no results and the team cannot
                              convincingly explain why, it's not a good team and something needs to
                              be done about it. If the team cranks up results sprint after sprint
                              (and can even increase their performance), does it even make any
                              difference how they are organized? It helps to compare the performance
                              to pre-self-organization, if possible, to see that the improvements
                              are real.

                              Visibility is something that has really worked here in my company. And
                              it especially works at showing that the team can do manage themselves.
                              The wall charts are visible to everyone, so anyone could technically
                              come over and see where the team stands, at task level. The teams are
                              much more capable at saying how complete they really are and whether
                              they will get the sprint completed successfully than any team ever
                              before. Also the fact that each project shows practical progress at
                              the end of any sprint has been a very comforting feeling for our
                              product managers and customers.

                              > Thanks,
                              >
                              > PH

                              Hope it helps any,


                              PH

                              ----

                              Petri Heiramo
                              Process Improvement Manager
                              SYSOPENDIGIA Plc., Finland
                            • Evan Leonard
                              If you have 25+ people on one team right now, why do you need to go straight to 3-5 teams? How about trying two teams? Then evaluate that at the next
                              Message 14 of 16 , Jun 26, 2007
                              View Source
                              • 0 Attachment
                                If you have 25+ people on one team right now, why do you need to go straight to 3-5 teams?
                                How about trying two teams? Then evaluate that at the next retrospective?

                                As for how to run multiple teams, they each definately need their own planning meetings and retrospectives and backlogs.  There can be a single product backlog, but when the PO comes to the planning meeting for one of the two teams there should be a set of work prepared just for that team to pull from.

                                Ideally there would be one PO for the product backlog and another PO for each of the team backlogs, and it would be the POs responsibility to coordinate all the work.  However one human may fill more than one of those roles.  Same for Scrum master, ideally there would be three, but again one human may fill more than one of those roles.  The important part is to recognize that the are separate roles with separate accountabilities. You might find it beneficial to write those accountabilities out so they're clear.  Then you can empirically see when it becomes more work than one person can handle.

                                Also, as for technical boundaries, the work given to each team should be "done" by that team.  That includes integration with the other team's work as well.  I would suggest a single continuous integration system that they are both checking into the whole time. If that is not possible, they should complete the integration work by the end of the sprint, otherwise its not "potentially shippable".

                                As for what work we give each team I highly recommend using User Stories. Do not break down the work into technical components and sub-components. Break the work along user facing functional lines. Look into Mike Cohn's book on User Stories.

                                I hope that is helpful.

                                Evan Leonard



                              • unmesh_joshi
                                ... Hi, I recommend reading Organizatinal Patterns of Agile software development by Jim Coplien and Neil Harrison. There are lot of scenarios discussed in that
                                Message 15 of 16 , Jun 27, 2007
                                View Source
                                • 0 Attachment
                                  >>>> Another wrinkle... There used to be 3 teams that were not self
                                  > organized. They were organized along architectural boundaries. This
                                  > added a lot of dependencies between teams because a story had to be
                                  > split across 2 or 3 teams. Combining the teams into one "solved"
                                  > that problem (or did it just mask it until now?). Some people
                                  >think that splitting up in to smaller teams might lead to the same
                                  >issues.
                                  Hi,
                                  I recommend reading Organizatinal Patterns of Agile software
                                  development by Jim Coplien and Neil Harrison. There are lot of
                                  scenarios discussed in that book.I think trying out some of the
                                  Organizational Patterns can help in your situation. Splitting the
                                  team across architectural boundaries is good thing to do (Thats what
                                  Conway's law is about). You probably need to use Function Owner and
                                  Component Owner, Named Stable bases and Incremental Integration
                                  patterns.
                                  Following is a link to (somewhat older) version of patterns
                                  http://www.bell-labs.com/cgi-user/OrgPatterns/OrgPatterns?
                                  FunctionOwnerAndComponentOwner

                                  Thanks
                                  Unmesh


                                  --- In scrumdevelopment@yahoogroups.com, "Petri Heiramo"
                                  <petri.heiramo@...> wrote:
                                  >
                                  > Hi,
                                  >
                                  >
                                  > > Let's say you are working in a company that is adopting Scrum.
                                  You
                                  > > are in the middle of a multi year project
                                  > > on a team of 25+ developers. You've been "doing Scum" for
                                  several
                                  > > months but it's just not clicking with this large team. Team
                                  size has
                                  > > been identified as an issue in the Retrospective. The team wants
                                  to
                                  > > split up into smaller teams but is having trouble seeing how.
                                  >
                                  > Ultimately that is up to the team to decide, but I see you're
                                  looking
                                  > for options for the team, which is exactly what I see the SM
                                  should be
                                  > doing. :)
                                  >
                                  > First of all, I think it would be good to keep in mind that the
                                  team
                                  > structure need not be permanent. If necessary, the teams can
                                  > reorganize every sprint. Also, if the cost of splitting up is too
                                  > high, stay as one team even if it has its own drawbacks.
                                  >
                                  > I've seen suggested that the teams should try to find logical
                                  > functional splits to minimize decoupling between teams'
                                  > responsibilities. It could also be logical split between stories
                                  > within one sprint. You might want to trial different team
                                  > configurations, and see what works and what not. Encourage the
                                  team to
                                  > test organizations and then tune based on practical experience.
                                  Some
                                  > ideas need iteration to get right (they tend to be the more
                                  difficult
                                  > problems).
                                  >
                                  > > What issues might arise if 3-5 teams share a product owner and a
                                  > > ScrumMaster? Would it be best to have a PBL for each team or is
                                  it
                                  > > light weight enough to share a PBL? Would it be best to have
                                  separate
                                  > > scrums, planning meetings, reviews and retrospectives?
                                  >
                                  > You might want to consider having a separate SM for each team. That
                                  > way they can have "local" SM presense.
                                  >
                                  > I would not recommend separate sprint planning meetings (the first
                                  > part with customer), reviews and retrospectives. Those important
                                  to be
                                  > held as the whole project team. The second part of sprint planning
                                  and
                                  > daily scrums would be specific to each team. And then there would
                                  be
                                  > the Scrum of Scrums to which each team would daily send their
                                  > representatives to keep the teams communicating.
                                  >
                                  > For some reason I recall that Henrik Kniberg did discuss the issue
                                  of
                                  > how to do sprint planning with multiple teams, but I can't find the
                                  > topic with a quick browse of his excellent Scrum and XP from the
                                  > Treches article
                                  > (http://www.crisp.se/henrik.kniberg/ScrumAndXpFromTheTrenches.pdf,
                                  > since it's just such a good read :) ). Maybe you have better luck.
                                  >
                                  > Anyway, I think it went something like this. In the first part of
                                  the
                                  > sprint planning meeting, the project team would discuss the top
                                  > priority items and each team would then select (in co-operation
                                  with
                                  > other teams and the product owner) stories for themselves. After
                                  each
                                  > team is fully committed, they would do one more discussion round
                                  > whether this split would be okay, or they should do some shuffling
                                  > around. This shuffling might include either stories or people
                                  > transferring between the teams.
                                  >
                                  > Anyway, this is a very interesting topic, so I would gladly read
                                  > practical experiences from other people who've solved the issue in
                                  > their projects.
                                  >
                                  > > Another challenge is silos of knowledge. With one large team,
                                  there
                                  > > are "go-to guys" for specific features. For example, one
                                  developer
                                  > > practically owns the data access layer. This makes it difficult
                                  to
                                  > > see a logical way to form the teams because this
                                  developer "needs" to
                                  > > be on all teams. An obvious solution is pair programming to
                                  spread
                                  > > the knowledge. Are there any other possible solutions?
                                  >
                                  > Pose this as a challenge to the team and ask them how they would
                                  solve
                                  > the situation. Ask what they would do if this one person is sick or
                                  > otherwise absent? How are they going to ensure that they can still
                                  > complete their spring commitments. It _IS_ their responsibility as
                                  a
                                  > self-managing team. They might suggest sharing knowledge through
                                  pair
                                  > programming, or sharing the person (and the possible deputy)
                                  between
                                  > teams based on greatest need in each sprint. It's really up to
                                  them.
                                  >
                                  > Actually, maybe you could make this "silos" thing a topic in one
                                  > retrospective, and have them work out a strategy and actions to
                                  handle
                                  > it. Of course, start up with a question "do you see <this and
                                  that> a
                                  > risk or a problem for you in the future?" :). If they think it's
                                  not a
                                  > problem, pose situations where the risk could materialize (like the
                                  > ones I gave above) and maybe they can see the risk (or you realize
                                  > through the discussion that they already have mitigated the risk).
                                  >
                                  > As to possible solutions, some have mentioned that Dojos are a good
                                  > way of sharing the knowledge. Could be. :)
                                  >
                                  > > Another wrinkle... There used to be 3 teams that were not self
                                  > > organized. They were organized along architectural boundaries.
                                  This
                                  > > added a lot of dependencies between teams because a story had to
                                  be
                                  > > split across 2 or 3 teams. Combining the teams into
                                  one "solved" that
                                  > > problem (or did it just mask it until now?). Some people think
                                  that
                                  > > splitting up in to smaller teams might lead to the same issues.
                                  >
                                  > Possibly very true. You replaced one problem with another
                                  challenge.
                                  > Try to find a new solution that works for both. :)
                                  >
                                  > Hope any of this helps,
                                  >
                                  >
                                  > Petri Heiramo
                                  > Process Improvement Manager
                                  > SYSOPENDIGIA Plc., Finland
                                  >
                                • unmesh_joshi
                                  If I am understanding the problem correctly, it is like a single product backlog item covers various layers of architecture. e.g. Product backlog says User
                                  Message 16 of 16 , Jun 27, 2007
                                  View Source
                                  • 0 Attachment
                                    If I am understanding the problem correctly, it is like a single
                                    product backlog item covers various layers of architecture.
                                    e.g. Product backlog says "User should be able to log into the
                                    system with system user name and password".
                                    Because the architecture is such that you have a J2EE frontend
                                    system, a service layer (probably a web service), a legacy system
                                    (may be a mainframe system).. etc.
                                    So to say that we are "done done done" with this item, you need to
                                    have all pieces integrated and working.
                                    If you do not split the team along architectural boundaries, you
                                    need to have a big team including all the members having various
                                    skills (J2EE frontend people, a web services experts, mainframe
                                    experts etc). It will be very convinient to break the team and let
                                    each team have their own sprint backlog. But there should be a
                                    Function Owner who owns the whole end to end functionality and each
                                    team owns the component. The function owner will probably maintain a
                                    overall burn down chart, while each team maintain their own burn
                                    down charts. For integration, let each team have a "named stable
                                    base", a working component published for other team to use, every
                                    couple of days, with list of concrete scenarios working.I think this
                                    should work for you.


                                    --- In scrumdevelopment@yahoogroups.com, "Evan Leonard" <evan@...>
                                    wrote:
                                    >
                                    > If you have 25+ people on one team right now, why do you need to
                                    go straight
                                    > to 3-5 teams?
                                    > How about trying two teams? Then evaluate that at the next
                                    retrospective?
                                    >
                                    > As for how to run multiple teams, they each definately need their
                                    own
                                    > planning meetings and retrospectives and backlogs. There can be a
                                    single
                                    > product backlog, but when the PO comes to the planning meeting for
                                    one of
                                    > the two teams there should be a set of work prepared just for that
                                    team to
                                    > pull from.
                                    >
                                    > Ideally there would be one PO for the product backlog and another
                                    PO for
                                    > each of the team backlogs, and it would be the POs responsibility
                                    to
                                    > coordinate all the work. However one human may fill more than one
                                    of those
                                    > roles. Same for Scrum master, ideally there would be three, but
                                    again one
                                    > human may fill more than one of those roles. The important part
                                    is to
                                    > recognize that the are separate roles with separate
                                    accountabilities. You
                                    > might find it beneficial to write those accountabilities out so
                                    they're
                                    > clear. Then you can empirically see when it becomes more work
                                    than one
                                    > person can handle.
                                    >
                                    > Also, as for technical boundaries, the work given to each team
                                    should be
                                    > "done" by that team. That includes integration with the other
                                    team's work
                                    > as well. I would suggest a single continuous integration system
                                    that they
                                    > are both checking into the whole time. If that is not possible,
                                    they should
                                    > complete the integration work by the end of the sprint, otherwise
                                    its not
                                    > "potentially shippable".
                                    >
                                    > As for what work we give each team I highly recommend using User
                                    Stories. Do
                                    > not break down the work into technical components and sub-
                                    components. Break
                                    > the work along user facing functional lines. Look into Mike Cohn's
                                    book on
                                    > User Stories.
                                    >
                                    > I hope that is helpful.
                                    >
                                    > Evan Leonard
                                    >
                                  Your message has been successfully submitted and would be delivered to recipients shortly.