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

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

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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.