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

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

Expand Messages
  • 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 1 of 16 , May 2 6:59 AM

      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 2 of 16 , May 2 7:14 AM
         
        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 3 of 16 , May 2 7:22 AM

          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 4 of 16 , May 2 8:24 AM
            --- 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 5 of 16 , May 2 10:00 AM
              --- 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 6 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 7 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 8 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 9 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 10 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 11 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.