Loading ...
Sorry, an error occurred while loading the content.
Skip to search.
 

Re: [scrumdevelopment] Re: Self organization. How?

Expand Messages
  • Nicholas Cancelliere
    What makes senior developers any more effective at self-organization? Nicholas
    Message 1 of 16 , May 1, 2007

      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 2 of 16 , May 2, 2007
        --- 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 3 of 16 , May 2, 2007

          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 4 of 16 , May 2, 2007
             
            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 5 of 16 , May 2, 2007

              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 6 of 16 , May 2, 2007
                --- 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 7 of 16 , May 2, 2007
                  --- 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 8 of 16 , Jun 26, 2007
                    --- 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 9 of 16 , Jun 26, 2007
                      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 10 of 16 , Jun 26, 2007
                        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 11 of 16 , Jun 26, 2007
                          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 12 of 16 , Jun 27, 2007
                            >>>> 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 13 of 16 , Jun 27, 2007
                              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.