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

RE: [scrumdevelopment] Re: Question re purpose of Scrum of Scrums

Expand Messages
  • Mike Dwyer
    Alan We have just finished a 200+ person, 30+ teams engagement where all of the factors you mentioned were involved plus infrastructure, Architecture (Data,
    Message 1 of 16 , Nov 15, 2008

      Alan

       

      We have just finished a 200+ person, 30+ teams engagement where all of the factors you mentioned were involved plus infrastructure, Architecture (Data, systems and software)  Operations, and deployment.

       

      The direction you talk about does not come from the leadership, it comes from the Stories the teams create at the highest level that drive the value of the product.  The only general ‘direction’ used was a set of Themes used to connect everyone together.  For example The Roadmap could be made up of “Get a line across the chasm”, Establish a foothold”, “build a bridge from both sides”, “manage the traffic”, making up Release themes. “Climb the tallest tree and get your bearings” followed by “cut a safe path through the wilderness”, “your shoot a line”, and deliver the ability to “get someone on the other side”.  These themes were the responsibility of the Uber Uber Product Owner and ScrumMaster and their teams of scrummasters and PO’s.

       

      What happens is these themes guide all conversations about what is important for a given short period of time.  In doing so the planning conversations, the iteration conversations, and the story conversations all fall in line.

       

      As to your examples  The Scrum of Scrums and Meta Scrums are their to coordinate the decomposition of the stories so that you don’t end up with the same thing being built by many teams.  Those things are to be worked out through the daily and frequent conversation that occurs at all levels.  Yes there are times when one team may need something that another team is not working on.  But has been my experience in coaching the teams providing the horizontal layers of software – you know the ones that get sliced up in the sushi – that good teams in Architecture, Data, Infrastructure are all over that stuff, making sure that what they cobble up is done in such a way that it can be easily refactored.

       

      You are right Alan this all hangs together because ‘management’ is in the game, doing the job we have always asked them to do, plow the road.  So I am confused as to what the disagreement is on this point, but it doesn’t happen because it got direction from the ‘top down’ unless you mean that the direction was the collaboration by the team and actively supported by ‘management’.

       

      I’m looking forward to reading what you have found out.  I am sure it will be insightful to all of us.

       

      Michael F. Dwyer

       

      "Planning constantly peers into the future for indications as to where a solution may emerge."

      "A Plan is a complex situation, adapting to an emerging solution." 

      -----Original Message-----
      From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Alan Shalloway
      Sent: Saturday, November 15, 2008 4:40 PM
      To: scrumdevelopment@yahoogroups.com
      Subject: [scrumdevelopment] Re: Question re purpose of Scrum of Scrums

       

       --- In scrumdevelopment@ yahoogroups. com, Ken Schwaber <ken.schwaber@ ...> wrote:

      >
      > The responsibility of getting everyone on the same page. That would
      be 
      > the responsibility of the Product Owner and ScrumMaster that hired 
      > more people to "scale" their effort into multiple teams. And,
      since 
      > they are responsible for ROI and process, respectively, they would
      be 
      > responsible for getting everyone they hire and who reports to them
      to 
      > be on the same page.

      I think we're talking different level of scaling. I have in mind a 350 person group doing Scrum.  There are UI devs, component devs, mid-tier, database, and more.  Essentially, several different products are involved, but supported by the common components.  There are several product owners and scrum masters involved.  In fact, the person who made the decision to scale is well above these.

      Intuitively they (POs, SMs) know they need help - but aren't sure what to do.  The biggest problem is one of perspective.  Scrum suggests taking teams and scaling them up.  Lean suggests looking at the entire organization.  How does Lean's different perspective help?  Because it sees things you won't see at the team level. More on this can be seen in "The Big Picture" chapter of our upcoming book Lean Software Development: Scaling Agile to the Enterprise.  Essentially, the attitude is, instead of being at the team level and trying to look up, be at the organization level you are trying to improve and give direction (not command and control) and support for the teams to work things out.

      Let me give 3 examples .  One at a technical level, one at a cross-team level and one at a team-structural level.

      Technical level.  Given we're doing iterative development, teams are hopefully following the principles of emergent design.  This means that we're writing high quality code, but not adding functionality or design structures until they are needed.  Team A may write an encryptor without the use of an interface simply because they have need for only one.  Team B may later need an encryptor which is slightly different from Team A's.  What would be the best way for the organization to proceed is for team A to modify their code and have an encryptor interface - something that wasn't needed before.  First, it's likely team B will even know about this.  But if they do, Team A has no real incentive to help by modifying their code.  Their PO will suggest that it won't help their customers (remember these are different albeit related products).  Team A's product owner must be driven not by their customer but by the organization as a whole (i.e., follow the Lean concept optimize the whole).  Emergent design across groups has little chance of being seen or coordinated when everyone is looking at different things.

      Cross-Team Level. How teams work together when there are different Product Owners and Scrum Masters for the different teams is not always obvious.  Again, a bigger picture helps.  This is especially true when there is a component team doing support work for several other teams.  To drive from business value requires looking across the product owners.  They may cooperate, but then again, they may not.  People are typically not magnanimous.  They tend to identify with their team or product more than the company.  The only case I've seen this not be true is when there is a very strong customer focus.  But this doesn't happen a lot unfortunately. 

      Team Structural Level. Many scrum teams working together have serious problems delivering an end to end feature when several teams are involved.  I have seen three separate teams, one comprised of UI people, one of mid-tier people and one of database people, get much more effective when they reorganized into three different teams organized around functionality.  The people in the organized groups still performed more or less the same functions but were now able to swarm around features, not parts of a feature that was on a layer.  This caused some integration problems across the teams but enabled end-to-end functionality to be built more quickly.  This type of reorganization can only be made at a managerial level above the first level (which was how it was done at the team I was consulting at - 3rd level in this case).  Huge productivity gains were almost immediately achieved.  These teams were following Scrum when I got there and were not looking to make this change immediately because the teams liked organizing by roles - it let them do what they liked.  Managers intervened, said we need end-to-end structure and had the teams figure out how to do that.  This, by the way, is also a great example of  the fact that while managers can't do command and control - servant leadership is not really the answer either. 

      Managers have  a responsibility for support and specifying outcomes - not merely helping out the team.  I believe much of the challenge in getting Scrum to scale is that mid-managers feel like they are being left out - that they not only have no role but are somehow bad.

      >A standard management responsibility, except that 

      > it must be accomplished in Scrum with servant leadership rather than 
      > command and control.

      Lean never suggests command and control.   Giving high level outcomes that are needed is not command and control. It simply says - hey,  we must do this - you go figure out how to do it.  I have seen a pendulum swinging in this industry between command and control and cats (programmers) doing what they want.  Managers and teams working together makes more sense to me.  Deming, the foundation of Lean, has been saying how to do this for 60 years.

      > The difficulty is inherent in large organizations, and while lean and 

      > other techniques are useful in attaining this, the responsibility 
      > remains the same.

      Here's another point of disagreement.  I believe ultimate responsibility lies with management at the top of the teams working together.  They must assist and help those under them to get the job done.  Much of this involves them removing impediments (improper team organizations, etc.) that those at the lower levels cannot.

      In any event, I appreciate your input. I suspect we just disagree here - but the conversation has been useful (at least to me) so thanks.  I am going to try to concentrate on finishing the chapter and not so much continue the conversation on this thread.  I let you all know when I've completed the draft and posted it.

      Alan Shalloway
      CEO, Net Objectives
      Achieving Enterprise and Team Agility

      > Ken

      >
      >
      > On Nov 15, 2008, at 12:54 PM, Alan Shalloway wrote:
      >
      > > So, in this case, I believe there are two possibilities: one, get
      > > everyone on the same page (an extremely difficult task in any but a
      > > highly functioning organization) or two, create a team that can
      > > coordinate the teams working together. They can't command and
      > > control it, but can give direction (outcomes) that create an
      > > enterprise view of things. How we've accomplished this is the main
      > > part of the chapter I am writing.
      >

    • Ron Jeffries
      Hello, Mike. On Saturday, November 15, 2008, at 9:33:06 PM, you ... Real examples would be really helpful here ... Ron Jeffries www.XProgramming.com
      Message 2 of 16 , Nov 15, 2008
        Hello, Mike. On Saturday, November 15, 2008, at 9:33:06 PM, you
        wrote:

        > The direction you talk about does not come from the leadership, it comes
        > from the Stories the teams create at the highest level that drive the value
        > of the product. The only general 'direction' used was a set of Themes used
        > to connect everyone together. For example The Roadmap could be made up of
        > "Get a line across the chasm", Establish a foothold", "build a bridge from
        > both sides", "manage the traffic", making up Release themes. "Climb the
        > tallest tree and get your bearings" followed by "cut a safe path through the
        > wilderness", "your shoot a line", and deliver the ability to "get someone on
        > the other side". These themes were the responsibility of the Uber Uber
        > Product Owner and ScrumMaster and their teams of scrummasters and PO's.

        > What happens is these themes guide all conversations about what is important
        > for a given short period of time. In doing so the planning conversations,
        > the iteration conversations, and the story conversations all fall in line.

        Real examples would be really helpful here ...

        Ron Jeffries
        www.XProgramming.com
        www.xprogramming.com/blog
        Will Turner: This is either madness or brilliance.
        Captain Jack Sparrow: It's remarkable how often those two traits coincide.
      • Mike Dwyer
        NDA s pose a bit of a problem. The specific titles of the Release Roadmap have been changed but the flow and the logic are from experience. But here goes.
        Message 3 of 16 , Nov 15, 2008

          NDA’s pose a bit of a problem.  The specific titles of the Release Roadmap have been changed but the flow and the logic are from experience.  But here goes.

           

          The first release began was to do the most valuable single feature of the overall product line. The theme of the release was to have functioning software that used data and services from two internal sources, took advantage of as much COTS (commercial off the shelf software) combined it with ERP data buses and gave access via a portal to the world.  The initial choice of operating system was an impediment, as was the storage and processing capabilities.  Both were adapted and inspected to so that both the commitments to the individual iterations could be supported and the overall product vision be met. 

           

          Chosen because it allowed sushi slicing to be additive as the feature was with an iteration to it also was the biggest risk as it made transparent a great number of the design and development assumptions that were not totally understood.  This created a certain level of dynamics in the ‘horizontal layers’ of the sushi as not only did those changes have to occur on development systems but also on integration, systems, performance, and training systems.  Add to this changing ROI demands and this was an interesting effort.

           

          As a coach, I can attest to the critical importance of these themes as no management, hierarchy of scrums, nor commitment of super product owners would have been able to give the direction and support these simple words did.  But more than the words were their source, the team. So it wasn’t just management giving direction (aka Command and Control – C2) it was taking the product vision and establishing the product owners top priority as the number 1 objective.

           

           

          Michael F. Dwyer

           

          "Planning constantly peers into the future for indications as to where a solution may emerge."

          "A Plan is a complex situation, adapting to an emerging solution." 

          -----Original Message-----
          From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Ron Jeffries
          Sent: Saturday, November 15, 2008 9:56 PM
          To: scrumdevelopment@yahoogroups.com
          Subject: Re: [scrumdevelopment] Re: Question re purpose of Scrum of Scrums

           

          Hello, Mike. On Saturday, November 15, 2008, at 9:33:06 PM, you
          wrote:

          > The direction you talk about does not come from the leadership, it comes
          > from the Stories the teams create at the highest level that drive the
          value
          > of the product. The only general 'direction' used was a set of Themes used
          > to connect everyone together. For example The Roadmap could be made up of
          > "Get a line across the chasm", Establish a foothold",
          "build a bridge from
          > both sides", "manage the traffic", making up Release themes.
          "Climb the
          > tallest tree and get your bearings" followed by "cut a safe path
          through the
          > wilderness", "your shoot a line", and deliver the ability
          to "get someone on
          > the other side". These themes were the responsibility of the Uber
          Uber
          > Product Owner and ScrumMaster and their teams of scrummasters and PO's.

          > What happens is these themes guide all conversations about what is
          important
          > for a given short period of time. In doing so the planning conversations,
          > the iteration conversations, and the story conversations all fall in line.

          Real examples would be really helpful here ...

          Ron Jeffries
          www.XProgramming. com
          www.xprogramming. com/blog
          Will Turner: This is either madness or brilliance.
          Captain Jack Sparrow: It's remarkable how often those two traits coincide.

        • Peter Stevens
          ... Actually, I wanted to give this thread +1 (or even +2 if my karma would allow it) - this is one of the more substantive discussions on the relationship
          Message 4 of 16 , Nov 15, 2008
            > In any event, I appreciate your input. I suspect we just disagree here...
            >
            Actually, I wanted to give this thread +1 (or even +2 if my karma would
            allow it) - this is one of the more substantive discussions on the
            relationship between Lean and Scrum that i have seen in this forum. Hope
            it stays that way...

            I've never seen any conflict between Lean principles and Scrum. They are
            orthogonal to one another. I started doing Scrum, much later I
            discovered lean principles and saw how without thinking about them,
            Scrum helped my team and my customer implement lean principles. Lean
            principles gave me much of the 'Why' which explained Scrum's 'How.'
            Agile values (which I couldn't properly appreciate until I'd been doing
            Scrum for two years) gave me the rest.

            Cheers,

            Peter





            --
            Peter Stevens, CSM, CSP
            www.tinyurl.com/Scrum-In-House-Training
            www.scrum-breakfast.com
            tel: +41 44 586 6450
          • Alan Shalloway
            ... of the ... Architecture (Data, ... comes ... the value ... Themes used ... made up of ... bridge from ... the ... through the ... someone on ... Uber ...
            Message 5 of 16 , Nov 16, 2008
              --- In scrumdevelopment@yahoogroups.com, "Mike Dwyer"
              <mike.dwyer1@...> wrote:
              >
              > Alan
              >
              >
              >
              > We have just finished a 200+ person, 30+ teams engagement where all
              of the
              > factors you mentioned were involved plus infrastructure,
              Architecture (Data,
              > systems and software) Operations, and deployment.
              >
              >
              >
              > The direction you talk about does not come from the leadership, it
              comes
              > from the Stories the teams create at the highest level that drive
              the value
              > of the product. The only general 'direction' used was a set of
              Themes used
              > to connect everyone together. For example The Roadmap could be
              made up of
              > "Get a line across the chasm", Establish a foothold", "build a
              bridge from
              > both sides", "manage the traffic", making up Release themes. "Climb
              the
              > tallest tree and get your bearings" followed by "cut a safe path
              through the
              > wilderness", "your shoot a line", and deliver the ability to "get
              someone on
              > the other side". These themes were the responsibility of the Uber
              Uber
              > Product Owner and ScrumMaster and their teams of scrummasters and
              PO's.
              >
              >
              >
              > What happens is these themes guide all conversations about what is
              important
              > for a given short period of time. In doing so the planning
              conversations,
              > the iteration conversations, and the story conversations all fall
              in line.
              >
              >
              >
              > As to your examples The Scrum of Scrums and Meta Scrums are their
              to
              > coordinate the decomposition of the stories so that you don't end
              up with
              > the same thing being built by many teams. Those things are to be
              worked out
              > through the daily and frequent conversation that occurs at all
              levels. Yes
              > there are times when one team may need something that another team
              is not
              > working on. But has been my experience in coaching the teams
              providing the
              > horizontal layers of software - you know the ones that get sliced
              up in the
              > sushi - that good teams in Architecture, Data, Infrastructure are
              all over
              > that stuff, making sure that what they cobble up is done in such a
              way that
              > it can be easily refactored.
              >
              >
              >
              > You are right Alan this all hangs together because 'management' is
              in the
              > game, doing the job we have always asked them to do, plow the
              road. So I am
              > confused as to what the disagreement is on this point, but it
              doesn't happen
              > because it got direction from the 'top down' unless you mean that
              the
              > direction was the collaboration by the team and actively supported
              by
              > 'management'.
              >
              >
              >
              > I'm looking forward to reading what you have found out. I am sure
              it will
              > be insightful to all of us.
              >
              >
              >
              > Michael F. Dwyer
              >
              >
              >
              > "Planning constantly peers into the future for indications as to
              where a
              > solution may emerge."
              >
              > "A Plan is a complex situation, adapting to an emerging solution."
              >

              I am curious why you put 'management' in quotes. Were these real
              managers involved? I can think of two interpretations - one,
              management was done by the team, meaning managers didn't have a
              role. Or, real managers were working but we'll call them 'managers'
              so as not to confuse them with pointy haired bosses. Both
              interpretations I am left with seems disparaging of the role of
              management. Please tell me the correct interpretation.

              I am glad you were able to solve this with Scurm-of-Scrums. I find it
              interesting that it seems every time I post something on this group
              that says Lean would be useful I get a response that tells me that
              Lean isn't necessary. I have never said you _need_ Lean (or I
              shouldn't have). I have been trying to say it gives useful insights
              that can extend the usefulness of Scrum.

              I was at Ken's keynote in Vancouver a couple of weeks ago and he
              eloquently said Scrum is a framework for identifying your
              impediments - it creates visibility. Scrum gives some guidelines to
              solve them - but in many many cases these guidelines are insufficient
              for teams to figure out what to do when what they have is really a
              cross-team problem. In these situations, Lean is very useful. Also,
              in many situations I've worked with, the problems involved teams that
              were outside of the software domain.

              Mike, please give me clarification - without breaking the NDA. Would
              you say this group was very closely identified with the software of
              the company (can be internal)? I ask this question because I thought
              I had said this is the one case where I have personally seen Scrum-of-
              Scrums work. Also, were there any hardware groups that the software
              had to work on? I ask this question because in the companies I have
              worked at where there is such a group, this group is typically not
              doing Agile and the only way I know to get them enrolled in changing
              how they work is to do a value stream map and show them how they are
              causing problems.

              In any event, sounds like you did a great job there and that the
              culture of the company is healthy as well. Was that something that
              was present when you started this or was it something that Scrum
              facilitated?

              Alan Shalloway
              CEO, Net Objectives
              Achieving Enterprise and Team Agility

              > -----Original Message-----
              > From: scrumdevelopment@yahoogroups.com
              > [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Alan
              Shalloway
              > Sent: Saturday, November 15, 2008 4:40 PM
              > To: scrumdevelopment@yahoogroups.com
              > Subject: [scrumdevelopment] Re: Question re purpose of Scrum of
              Scrums
              >
              >
              >
              > <http://www.netobjectives.com/resources/books/lean-software-
              development>
              >
              > --- In scrumdevelopment@ <mailto:scrumdevelopment@yahoogroups.com>
              > yahoogroups.com, Ken Schwaber <ken.schwaber@> wrote:
              > >
              > > The responsibility of getting everyone on the same page. That
              would be
              > > the responsibility of the Product Owner and ScrumMaster that
              hired
              > > more people to "scale" their effort into multiple teams. And,
              since
              > > they are responsible for ROI and process, respectively, they
              would be
              > > responsible for getting everyone they hire and who reports to
              them to
              > > be on the same page.
              >
              > I think we're talking different level of scaling. I have in mind a
              350
              > person group doing Scrum. There are UI devs, component devs, mid-
              tier,
              > database, and more. Essentially, several different products are
              involved,
              > but supported by the common components. There are several product
              owners
              > and scrum masters involved. In fact, the person who made the
              decision to
              > scale is well above these.
              >
              > Intuitively they (POs, SMs) know they need help - but aren't sure
              what to
              > do. The biggest problem is one of perspective. Scrum suggests
              taking teams
              > and scaling them up. Lean suggests looking at the entire
              organization. How
              > does Lean's different perspective help? Because it sees things you
              won't
              > see at the team level. More on this can be seen in "The Big
              Picture" chapter
              > of our upcoming book Lean
              > <http://www.netobjectives.com/resources/books/lean-software-
              development>
              > Software Development: Scaling Agile to the Enterprise.
              Essentially, the
              > attitude is, instead of being at the team level and trying to look
              up, be at
              > the organization level you are trying to improve and give direction
              (not
              > command and control) and support for the teams to work things out.
              >
              > Let me give 3 examples . One at a technical level, one at a cross-
              team
              > level and one at a team-structural level.
              >
              > Technical level. Given we're doing iterative development, teams are
              > hopefully following the principles of emergent design. This means
              that
              > we're writing high quality code, but not adding functionality or
              design
              > structures until they are needed. Team A may write an encryptor
              without the
              > use of an interface simply because they have need for only one.
              Team B may
              > later need an encryptor which is slightly different from Team A's.
              What
              > would be the best way for the organization to proceed is for team A
              to
              > modify their code and have an encryptor interface - something that
              wasn't
              > needed before. First, it's likely team B will even know about
              this. But if
              > they do, Team A has no real incentive to help by modifying their
              code.
              > Their PO will suggest that it won't help their customers (remember
              these are
              > different albeit related products). Team A's product owner must be
              driven
              > not by their customer but by the organization as a whole (i.e.,
              follow the
              > Lean concept optimize the whole). Emergent design across groups
              has little
              > chance of being seen or coordinated when everyone is looking at
              different
              > things.
              >
              > Cross-Team Level. How teams work together when there are different
              Product
              > Owners and Scrum Masters for the different teams is not always
              obvious.
              > Again, a bigger picture helps. This is especially true when there
              is a
              > component team doing support work for several other teams. To
              drive from
              > business value requires looking across the product owners. They may
              > cooperate, but then again, they may not. People are typically not
              > magnanimous. They tend to identify with their team or product more
              than the
              > company. The only case I've seen this not be true is when there is
              a very
              > strong customer focus. But this doesn't happen a lot
              unfortunately.
              >
              > Team Structural Level. Many scrum teams working together have
              serious
              > problems delivering an end to end feature when several teams are
              involved.
              > I have seen three separate teams, one comprised of UI people, one of
              > mid-tier people and one of database people, get much more effective
              when
              > they reorganized into three different teams organized around
              functionality.
              > The people in the organized groups still performed more or less the
              same
              > functions but were now able to swarm around features, not parts of
              a feature
              > that was on a layer. This caused some integration problems across
              the teams
              > but enabled end-to-end functionality to be built more quickly.
              This type of
              > reorganization can only be made at a managerial level above the
              first level
              > (which was how it was done at the team I was consulting at - 3rd
              level in
              > this case). Huge productivity gains were almost immediately
              achieved.
              > These teams were following Scrum when I got there and were not
              looking to
              > make this change immediately because the teams liked organizing by
              roles -
              > it let them do what they liked. Managers intervened, said we need
              > end-to-end structure and had the teams figure out how to do that.
              This, by
              > the way, is also a great example of the fact that while managers
              can't do
              > command and control - servant leadership is not really the answer
              either.
              >
              > Managers have a responsibility for support and specifying
              outcomes - not
              > merely helping out the team. I believe much of the challenge in
              getting
              > Scrum to scale is that mid-managers feel like they are being left
              out - that
              > they not only have no role but are somehow bad.
              >
              > >A standard management responsibility, except that
              > > it must be accomplished in Scrum with servant leadership rather
              than
              > > command and control.
              >
              > Lean never suggests command and control. Giving high level
              outcomes that
              > are needed is not command and control. It simply says - hey, we
              must do
              > this - you go figure out how to do it. I have seen a pendulum
              swinging in
              > this industry between command and control and cats (programmers)
              doing what
              > they want. Managers and teams working together makes more sense to
              me.
              > Deming, the foundation of Lean, has been saying how to do this for
              60 years.
              >
              > > The difficulty is inherent in large organizations, and while lean
              and
              > > other techniques are useful in attaining this, the
              responsibility
              > > remains the same.
              >
              > Here's another point of disagreement. I believe ultimate
              responsibility
              > lies with management at the top of the teams working together.
              They must
              > assist and help those under them to get the job done. Much of this
              involves
              > them removing impediments (improper team organizations, etc.) that
              those at
              > the lower levels cannot.
              >
              > In any event, I appreciate your input. I suspect we just disagree
              here - but
              > the conversation has been useful (at least to me) so thanks. I am
              going to
              > try to concentrate on finishing the chapter and not so much
              continue the
              > conversation on this thread. I let you all know when I've
              completed the
              > draft and posted it.
              >
              > Alan Shalloway
              > CEO, Net Objectives
              > Achieving Enterprise and Team Agility
              >
              > > Ken
              > >
              > >
              > > On Nov 15, 2008, at 12:54 PM, Alan Shalloway wrote:
              > >
              > > > So, in this case, I believe there are two possibilities: one,
              get
              > > > everyone on the same page (an extremely difficult task in any
              but a
              > > > highly functioning organization) or two, create a team that can
              > > > coordinate the teams working together. They can't command and
              > > > control it, but can give direction (outcomes) that create an
              > > > enterprise view of things. How we've accomplished this is the
              main
              > > > part of the chapter I am writing.
              > >
              >
            • Alan Shalloway
              ... of the ... Architecture (Data, ... comes ... the value ... Themes used ... made up of ... bridge from ... the ... through the ... someone on ... Uber ...
              Message 6 of 16 , Nov 16, 2008
                --- In scrumdevelopment@yahoogroups.com, "Mike Dwyer"
                <mike.dwyer1@...> wrote:
                >
                > Alan
                >
                >
                >
                > We have just finished a 200+ person, 30+ teams engagement where all
                of the
                > factors you mentioned were involved plus infrastructure,
                Architecture (Data,
                > systems and software) Operations, and deployment.
                >
                >
                >
                > The direction you talk about does not come from the leadership, it
                comes
                > from the Stories the teams create at the highest level that drive
                the value
                > of the product. The only general 'direction' used was a set of
                Themes used
                > to connect everyone together. For example The Roadmap could be
                made up of
                > "Get a line across the chasm", Establish a foothold", "build a
                bridge from
                > both sides", "manage the traffic", making up Release themes. "Climb
                the
                > tallest tree and get your bearings" followed by "cut a safe path
                through the
                > wilderness", "your shoot a line", and deliver the ability to "get
                someone on
                > the other side". These themes were the responsibility of the Uber
                Uber
                > Product Owner and ScrumMaster and their teams of scrummasters and
                PO's.
                >
                >
                >
                > What happens is these themes guide all conversations about what is
                important
                > for a given short period of time. In doing so the planning
                conversations,
                > the iteration conversations, and the story conversations all fall
                in line.
                >
                >
                >
                > As to your examples The Scrum of Scrums and Meta Scrums are their
                to
                > coordinate the decomposition of the stories so that you don't end
                up with
                > the same thing being built by many teams. Those things are to be
                worked out
                > through the daily and frequent conversation that occurs at all
                levels. Yes
                > there are times when one team may need something that another team
                is not
                > working on. But has been my experience in coaching the teams
                providing the
                > horizontal layers of software - you know the ones that get sliced
                up in the
                > sushi - that good teams in Architecture, Data, Infrastructure are
                all over
                > that stuff, making sure that what they cobble up is done in such a
                way that
                > it can be easily refactored.
                >
                >
                >
                > You are right Alan this all hangs together because 'management' is
                in the
                > game, doing the job we have always asked them to do, plow the
                road. So I am
                > confused as to what the disagreement is on this point, but it
                doesn't happen
                > because it got direction from the 'top down' unless you mean that
                the
                > direction was the collaboration by the team and actively supported
                by
                > 'management'.
                >
                >
                >
                > I'm looking forward to reading what you have found out. I am sure
                it will
                > be insightful to all of us.
                >
                >
                >
                > Michael F. Dwyer
                >
                >
                >
                > "Planning constantly peers into the future for indications as to
                where a
                > solution may emerge."
                >
                > "A Plan is a complex situation, adapting to an emerging solution."
                >

                I am curious why you put 'management' in quotes. Were these real
                managers involved? I can think of two interpretations - one,
                management was done by the team, meaning managers didn't have a
                role. Or, real managers were working but we'll call them 'managers'
                so as not to confuse them with pointy haired bosses. Both
                interpretations I am left with seems disparaging of the role of
                management. Please tell me the correct interpretation.

                I am glad you were able to solve this with Scurm-of-Scrums. I find it
                interesting that it seems every time I post something on this group
                that says Lean would be useful I get a response that tells me that
                Lean isn't necessary. I have never said you _need_ Lean (or I
                shouldn't have). I have been trying to say it gives useful insights
                that can extend the usefulness of Scrum.

                I was at Ken's keynote in Vancouver a couple of weeks ago and he
                eloquently said Scrum is a framework for identifying your
                impediments - it creates visibility. Scrum gives some guidelines to
                solve them - but in many many cases these guidelines are insufficient
                for teams to figure out what to do when what they have is really a
                cross-team problem. In these situations, Lean is very useful. Also,
                in many situations I've worked with, the problems involved teams that
                were outside of the software domain.

                Mike, please give me clarification - without breaking the NDA. Would
                you say this group was very closely identified with the software of
                the company (can be internal)? I ask this question because I thought
                I had said this is the one case where I have personally seen Scrum-of-
                Scrums work. Also, were there any hardware groups that the software
                had to work on? I ask this question because in the companies I have
                worked at where there is such a group, this group is typically not
                doing Agile and the only way I know to get them enrolled in changing
                how they work is to do a value stream map and show them how they are
                causing problems.

                In any event, sounds like you did a great job there and that the
                culture of the company is healthy as well. Was that something that
                was present when you started this or was it something that Scrum
                facilitated?

                Alan Shalloway
                CEO, Net Objectives
                Achieving Enterprise and Team Agility

                > -----Original Message-----
                > From: scrumdevelopment@yahoogroups.com
                > [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Alan
                Shalloway
                > Sent: Saturday, November 15, 2008 4:40 PM
                > To: scrumdevelopment@yahoogroups.com
                > Subject: [scrumdevelopment] Re: Question re purpose of Scrum of
                Scrums
                >
                >
                >
                > <http://www.netobjectives.com/resources/books/lean-software-
                development>
                >
                > --- In scrumdevelopment@ <mailto:scrumdevelopment@yahoogroups.com>
                > yahoogroups.com, Ken Schwaber <ken.schwaber@> wrote:
                > >
                > > The responsibility of getting everyone on the same page. That
                would be
                > > the responsibility of the Product Owner and ScrumMaster that
                hired
                > > more people to "scale" their effort into multiple teams. And,
                since
                > > they are responsible for ROI and process, respectively, they
                would be
                > > responsible for getting everyone they hire and who reports to
                them to
                > > be on the same page.
                >
                > I think we're talking different level of scaling. I have in mind a
                350
                > person group doing Scrum. There are UI devs, component devs, mid-
                tier,
                > database, and more. Essentially, several different products are
                involved,
                > but supported by the common components. There are several product
                owners
                > and scrum masters involved. In fact, the person who made the
                decision to
                > scale is well above these.
                >
                > Intuitively they (POs, SMs) know they need help - but aren't sure
                what to
                > do. The biggest problem is one of perspective. Scrum suggests
                taking teams
                > and scaling them up. Lean suggests looking at the entire
                organization. How
                > does Lean's different perspective help? Because it sees things you
                won't
                > see at the team level. More on this can be seen in "The Big
                Picture" chapter
                > of our upcoming book Lean
                > <http://www.netobjectives.com/resources/books/lean-software-
                development>
                > Software Development: Scaling Agile to the Enterprise.
                Essentially, the
                > attitude is, instead of being at the team level and trying to look
                up, be at
                > the organization level you are trying to improve and give direction
                (not
                > command and control) and support for the teams to work things out.
                >
                > Let me give 3 examples . One at a technical level, one at a cross-
                team
                > level and one at a team-structural level.
                >
                > Technical level. Given we're doing iterative development, teams are
                > hopefully following the principles of emergent design. This means
                that
                > we're writing high quality code, but not adding functionality or
                design
                > structures until they are needed. Team A may write an encryptor
                without the
                > use of an interface simply because they have need for only one.
                Team B may
                > later need an encryptor which is slightly different from Team A's.
                What
                > would be the best way for the organization to proceed is for team A
                to
                > modify their code and have an encryptor interface - something that
                wasn't
                > needed before. First, it's likely team B will even know about
                this. But if
                > they do, Team A has no real incentive to help by modifying their
                code.
                > Their PO will suggest that it won't help their customers (remember
                these are
                > different albeit related products). Team A's product owner must be
                driven
                > not by their customer but by the organization as a whole (i.e.,
                follow the
                > Lean concept optimize the whole). Emergent design across groups
                has little
                > chance of being seen or coordinated when everyone is looking at
                different
                > things.
                >
                > Cross-Team Level. How teams work together when there are different
                Product
                > Owners and Scrum Masters for the different teams is not always
                obvious.
                > Again, a bigger picture helps. This is especially true when there
                is a
                > component team doing support work for several other teams. To
                drive from
                > business value requires looking across the product owners. They may
                > cooperate, but then again, they may not. People are typically not
                > magnanimous. They tend to identify with their team or product more
                than the
                > company. The only case I've seen this not be true is when there is
                a very
                > strong customer focus. But this doesn't happen a lot
                unfortunately.
                >
                > Team Structural Level. Many scrum teams working together have
                serious
                > problems delivering an end to end feature when several teams are
                involved.
                > I have seen three separate teams, one comprised of UI people, one of
                > mid-tier people and one of database people, get much more effective
                when
                > they reorganized into three different teams organized around
                functionality.
                > The people in the organized groups still performed more or less the
                same
                > functions but were now able to swarm around features, not parts of
                a feature
                > that was on a layer. This caused some integration problems across
                the teams
                > but enabled end-to-end functionality to be built more quickly.
                This type of
                > reorganization can only be made at a managerial level above the
                first level
                > (which was how it was done at the team I was consulting at - 3rd
                level in
                > this case). Huge productivity gains were almost immediately
                achieved.
                > These teams were following Scrum when I got there and were not
                looking to
                > make this change immediately because the teams liked organizing by
                roles -
                > it let them do what they liked. Managers intervened, said we need
                > end-to-end structure and had the teams figure out how to do that.
                This, by
                > the way, is also a great example of the fact that while managers
                can't do
                > command and control - servant leadership is not really the answer
                either.
                >
                > Managers have a responsibility for support and specifying
                outcomes - not
                > merely helping out the team. I believe much of the challenge in
                getting
                > Scrum to scale is that mid-managers feel like they are being left
                out - that
                > they not only have no role but are somehow bad.
                >
                > >A standard management responsibility, except that
                > > it must be accomplished in Scrum with servant leadership rather
                than
                > > command and control.
                >
                > Lean never suggests command and control. Giving high level
                outcomes that
                > are needed is not command and control. It simply says - hey, we
                must do
                > this - you go figure out how to do it. I have seen a pendulum
                swinging in
                > this industry between command and control and cats (programmers)
                doing what
                > they want. Managers and teams working together makes more sense to
                me.
                > Deming, the foundation of Lean, has been saying how to do this for
                60 years.
                >
                > > The difficulty is inherent in large organizations, and while lean
                and
                > > other techniques are useful in attaining this, the
                responsibility
                > > remains the same.
                >
                > Here's another point of disagreement. I believe ultimate
                responsibility
                > lies with management at the top of the teams working together.
                They must
                > assist and help those under them to get the job done. Much of this
                involves
                > them removing impediments (improper team organizations, etc.) that
                those at
                > the lower levels cannot.
                >
                > In any event, I appreciate your input. I suspect we just disagree
                here - but
                > the conversation has been useful (at least to me) so thanks. I am
                going to
                > try to concentrate on finishing the chapter and not so much
                continue the
                > conversation on this thread. I let you all know when I've
                completed the
                > draft and posted it.
                >
                > Alan Shalloway
                > CEO, Net Objectives
                > Achieving Enterprise and Team Agility
                >
                > > Ken
                > >
                > >
                > > On Nov 15, 2008, at 12:54 PM, Alan Shalloway wrote:
                > >
                > > > So, in this case, I believe there are two possibilities: one,
                get
                > > > everyone on the same page (an extremely difficult task in any
                but a
                > > > highly functioning organization) or two, create a team that can
                > > > coordinate the teams working together. They can't command and
                > > > control it, but can give direction (outcomes) that create an
                > > > enterprise view of things. How we've accomplished this is the
                main
                > > > part of the chapter I am writing.
                > >
                >
              • mike.dwyer1@comcast.net
                Alan In both of the cases I drew from the product (software + training + support) modules being built were for use extremely thru a web interface and
                Message 7 of 16 , Nov 16, 2008
                  Alan
                  In both of the cases I drew from the product (software + training + support) modules being built were for use extremely thru a web interface and internally thru a push call center model.

                  Managers, (Dept level) were team members and produced as such and their former employees scattered among the teams.

                  Some attempts were made to do C2 but were overwhelmed by the constant conversations. And unending collaborative improvements that happened.

                  Interesting note some of the biggest mgt resistors became HUGE SCRUM fans when they found out that one of the implicit rules of scrum is ' no whining - just deliver'. It turns out they hated the waste of time that excuses make.

                  Sent via BlackBerry by AT&T


                  From: "Alan Shalloway" <alshall@...>
                  Date: Sun, 16 Nov 2008 13:53:09 -0000
                  To: <scrumdevelopment@yahoogroups.com>
                  Subject: [scrumdevelopment] Re: Question re purpose of Scrum of Scrums

                  --- In scrumdevelopment@ yahoogroups. com, "Mike Dwyer"
                  <mike.dwyer1@ ...> wrote:

                  >
                  > Alan
                  >
                  >
                  >
                  > We have just finished a 200+ person, 30+ teams engagement where all
                  of the
                  > factors you mentioned were involved plus infrastructure,
                  Architecture (Data,
                  > systems and software) Operations, and deployment.
                  >
                  >
                  >
                  > The direction you talk about does not come from the leadership, it
                  comes
                  > from the Stories the teams create at the highest level that drive
                  the value
                  > of the product. The only general 'direction' used was a set of
                  Themes used
                  > to connect everyone together. For example The Roadmap could be
                  made up of
                  > "Get a line across the chasm", Establish a foothold", "build a
                  bridge from
                  > both sides", "manage the traffic", making up Release themes. "Climb
                  the
                  > tallest tree and get your bearings" followed by "cut a safe path
                  through the
                  > wilderness", "your shoot a line", and deliver the ability to "get
                  someone on
                  > the other side". These themes were the responsibility of the Uber
                  Uber
                  > Product Owner and ScrumMaster and their teams of scrummasters and
                  PO's.
                  >
                  >
                  >
                  > What happens is these themes guide all conversations about what is
                  important
                  > for a given short period of time. In doing so the planning
                  conversations,
                  > the iteration conversations, and the story conversations all fall
                  in line.
                  >
                  >
                  >
                  > As to your examples The Scrum of Scrums and Meta Scrums are their
                  to
                  > coordinate the decomposition of the stories so that you don't end
                  up with
                  > the same thing being built by many teams. Those things are to be
                  worked out
                  > through the daily and frequent conversation that occurs at all
                  levels. Yes
                  > there are times when one team may need something that another team
                  is not
                  > working on. But has been my experience in coaching the teams
                  providing the
                  > horizontal layers of software - you know the ones that get sliced
                  up in the
                  > sushi - that good teams in Architecture, Data, Infrastructure are
                  all over
                  > that stuff, making sure that what they cobble up is done in such a
                  way that
                  > it can be easily refactored.
                  >
                  >
                  >
                  > You are right Alan this all hangs together because 'management' is
                  in the
                  > game, doing the job we have always asked them to do, plow the
                  road. So I am
                  > confused as to what the disagreement is on this point, but it
                  doesn't happen
                  > because it got direction from the 'top down' unless you mean that
                  the
                  > direction was the collaboration by the team and actively supported
                  by
                  > 'management' .
                  >
                  >
                  >
                  > I'm looking forward to reading what you have found out. I am sure
                  it will
                  > be insightful to all of us.
                  >
                  >
                  >
                  > Michael F. Dwyer
                  >
                  >
                  >
                  > "Planning constantly peers into the future for indications as to
                  where a
                  > solution may emerge."
                  >
                  > "A Plan is a complex situation, adapting to an emerging solution."
                  >

                  I am curious why you put 'management' in quotes. Were these real
                  managers involved? I can think of two interpretations - one,
                  management was done by the team, meaning managers didn't have a
                  role. Or, real managers were working but we'll call them 'managers'
                  so as not to confuse them with pointy haired bosses. Both
                  interpretations I am left with seems disparaging of the role of
                  management. Please tell me the correct interpretation.

                  I am glad you were able to solve this with Scurm-of-Scrums. I find it
                  interesting that it seems every time I post something on this group
                  that says Lean would be useful I get a response that tells me that
                  Lean isn't necessary. I have never said you _need_ Lean (or I
                  shouldn't have). I have been trying to say it gives useful insights
                  that can extend the usefulness of Scrum.

                  I was at Ken's keynote in Vancouver a couple of weeks ago and he
                  eloquently said Scrum is a framework for identifying your
                  impediments - it creates visibility. Scrum gives some guidelines to
                  solve them - but in many many cases these guidelines are insufficient
                  for teams to figure out what to do when what they have is really a
                  cross-team problem. In these situations, Lean is very useful. Also,
                  in many situations I've worked with, the problems involved teams that
                  were outside of the software domain.

                  Mike, please give me clarification - without breaking the NDA. Would
                  you say this group was very closely identified with the software of
                  the company (can be internal)? I ask this question because I thought
                  I had said this is the one case where I have personally seen Scrum-of-
                  Scrums work. Also, were there any hardware groups that the software
                  had to work on? I ask this question because in the companies I have
                  worked at where there is such a group, this group is typically not
                  doing Agile and the only way I know to get them enrolled in changing
                  how they work is to do a value stream map and show them how they are
                  causing problems.

                  In any event, sounds like you did a great job there and that the
                  culture of the company is healthy as well. Was that something that
                  was present when you started this or was it something that Scrum
                  facilitated?

                  Alan Shalloway
                  CEO, Net Objectives
                  Achieving Enterprise and Team Agility

                  > -----Original Message-----
                  > From: scrumdevelopment@ yahoogroups. com
                  > [mailto:scrumdevelopment@ yahoogroups. com] On Behalf Of Alan
                  Shalloway
                  > Sent: Saturday, November 15, 2008 4:40 PM
                  > To: scrumdevelopment@ yahoogroups. com
                  > Subject: [scrumdevelopment] Re: Question re purpose of Scrum of
                  Scrums
                  >
                  >
                  >
                  > <http://www.netobjec tives.com/ resources/ books/lean- software-
                  development>
                  >
                  > --- In scrumdevelopment@ <mailto:scrumdevelopment@ yahoogroups. com>
                  > yahoogroups. com, Ken Schwaber <ken.schwaber@ > wrote:
                  > >
                  > > The responsibility of getting everyone on the same page. That
                  would be
                  > > the responsibility of the Product Owner and ScrumMaster that
                  hired
                  > > more people to "scale" their effort into multiple teams. And,
                  since
                  > > they are responsible for ROI and process, respectively, they
                  would be
                  > > responsible for getting everyone they hire and who reports to
                  them to
                  > > be on the same page.
                  >
                  > I think we're talking different level of scaling. I have in mind a
                  350
                  > person group doing Scrum. There are UI devs, component devs, mid-
                  tier,
                  > database, and more. Essentially, several different products are
                  involved,
                  > but supported by the common components. There are several product
                  owners
                  > and scrum masters involved. In fact, the person who made the
                  decision to
                  > scale is well above these.
                  >
                  > Intuitively they (POs, SMs) know they need help - but aren't sure
                  what to
                  > do. The biggest problem is one of perspective. Scrum suggests
                  taking teams
                  > and scaling them up. Lean suggests looking at the entire
                  organization. How
                  > does Lean's different perspective help? Because it sees things you
                  won't
                  > see at the team level. More on this can be seen in "The Big
                  Picture" chapter
                  > of our upcoming book Lean
                  > <http://www.netobjec tives.com/ resources/ books/lean- software-
                  development>
                  > Software Development: Scaling Agile to the Enterprise.
                  Essentially, the
                  > attitude is, instead of being at the team level and trying to look
                  up, be at
                  > the organization level you are trying to improve and give direction
                  (not
                  > command and control) and support for the teams to work things out.
                  >
                  > Let me give 3 examples . One at a technical level, one at a cross-
                  team
                  > level and one at a team-structural level.
                  >
                  > Technical level. Given we're doing iterative development, teams are
                  > hopefully following the principles of emergent design. This means
                  that
                  > we're writing high quality code, but not adding functionality or
                  design
                  > structures until they are needed. Team A may write an encryptor
                  without the
                  > use of an interface simply because they have need for only one.
                  Team B may
                  > later need an encryptor which is slightly different from Team A's.
                  What
                  > would be the best way for the organization to proceed is for team A
                  to
                  > modify their code and have an encryptor interface - something that
                  wasn't
                  > needed before. First, it's likely team B will even know about
                  this. But if
                  > they do, Team A has no real incentive to help by modifying their
                  code.
                  > Their PO will suggest that it won't help their customers (remember
                  these are
                  > different albeit related products). Team A's product owner must be
                  driven
                  > not by their customer but by the organization as a whole (i.e.,
                  follow the
                  > Lean concept optimize the whole). Emergent design across groups
                  has little
                  > chance of being seen or coordinated when everyone is looking at
                  different
                  > things.
                  >
                  > Cross-Team Level. How teams work together when there are different
                  Product
                  > Owners and Scrum Masters for the different teams is not always
                  obvious.
                  > Again, a bigger picture helps. This is especially true when there
                  is a
                  > component team doing support work for several other teams. To
                  drive from
                  > business value requires looking across the product owners. They may
                  > cooperate, but then again, they may not. People are typically not
                  > magnanimous. They tend to identify with their team or product more
                  than the
                  > company. The only case I've seen this not be true is when there is
                  a very
                  > strong customer focus. But this doesn't happen a lot
                  unfortunately.
                  >
                  > Team Structural Level. Many scrum teams working together have
                  serious
                  > problems delivering an end to end feature when several teams are
                  involved.
                  > I have seen three separate teams, one comprised of UI people, one of
                  > mid-tier people and one of database people, get much more effective
                  when
                  > they reorganized into three different teams organized around
                  functionality.
                  > The people in the organized groups still performed more or less the
                  same
                  > functions but were now able to swarm around features, not parts of
                  a feature
                  > that was on a layer. This caused some integration problems across
                  the teams
                  > but enabled end-to-end functionality to be built more quickly.
                  This type of
                  > reorganization can only be made at a managerial level above the
                  first level
                  > (which was how it was done at the team I was consulting at - 3rd
                  level in
                  > this case). Huge productivity gains were almost immediately
                  achieved.
                  > These teams were following Scrum when I got there and were not
                  looking to
                  > make this change immediately because the teams liked organizing by
                  roles -
                  > it let them do what they liked. Managers intervened, said we need
                  > end-to-end structure and had the teams figure out how to do that.
                  This, by
                  > the way, is also a great example of the fact that while managers
                  can't do
                  > command and control - servant leadership is not really the answer
                  either.
                  >
                  > Managers have a responsibility for support and specifying
                  outcomes - not
                  > merely helping out the team. I believe much of the challenge in
                  getting
                  > Scrum to scale is that mid-managers feel like they are being left
                  out - that
                  > they not only have no role but are somehow bad.
                  >
                  > >A standard management responsibility, except that
                  > > it must be accomplished in Scrum with servant leadership rather
                  than
                  > > command and control.
                  >
                  > Lean never suggests command and control. Giving high level
                  outcomes that
                  > are needed is not command and control. It simply says - hey, we
                  must do
                  > this - you go figure out how to do it. I have seen a pendulum
                  swinging in
                  > this industry between command and control and cats (programmers)
                  doing what
                  > they want. Managers and teams working together makes more sense to
                  me.
                  > Deming, the foundation of Lean, has been saying how to do this for
                  60 years.
                  >
                  > > The difficulty is inherent in large organizations, and while lean
                  and
                  > > other techniques are useful in attaining this, the
                  responsibility
                  > > remains the same.
                  >
                  > Here's another point of disagreement. I believe ultimate
                  responsibility
                  > lies with management at the top of the teams working together.
                  They must
                  > assist and help those under them to get the job done. Much of this
                  involves
                  > them removing impediments (improper team organizations, etc.) that
                  those at
                  > the lower levels cannot.
                  >
                  > In any event, I appreciate your input. I suspect we just disagree
                  here - but
                  > the conversation has been useful (at least to me) so thanks. I am
                  going to
                  > try to concentrate on finishing the chapter and not so much
                  continue the
                  > conversation on this thread. I let you all know when I've
                  completed the
                  > draft and posted it.
                  >
                  > Alan Shalloway
                  > CEO, Net Objectives
                  > Achieving Enterprise and Team Agility
                  >
                  > > Ken
                  > >
                  > >
                  > > On Nov 15, 2008, at 12:54 PM, Alan Shalloway wrote:
                  > >
                  > > > So, in this case, I believe there are two possibilities: one,
                  get
                  > > > everyone on the same page (an extremely difficult task in any
                  but a
                  > > > highly functioning organization) or two, create a team that can
                  > > > coordinate the teams working together. They can't command and
                  > > > control it, but can give direction (outcomes) that create an
                  > > > enterprise view of things. How we've accomplished this is the
                  main
                  > > > part of the chapter I am writing.
                  > >
                  >

                • Ken Schwaber
                  Scaling is hard. It is probably the last thing one should do. However, when it is done, there are a number of practices that help do so. In the Scrum
                  Message 8 of 16 , Nov 16, 2008
                    Scaling is hard. It is probably the last thing one should do. However, when it is done, there are a number of practices that help do so. In the Scrum community, we stick with the basic Scrum principles and then support them using better engineering tools, infrastructures, and automated testing capabilities. As a result, two teams aren't twice as productive, maybe only 1.8 times as productive. The productivity declines further when many teams are engaged. However, we still require that they all have an integrated, integration tested increment at the end of the Sprint - otherwise, how does the Product Owner know where they and how long the stabilization phase will have to be?

                    Jeff Sutherland, myself, and others have scaled many projects and product releases using Scrum. Easy - no. Possible - certainly. Better than any alternative - yes. And the Scrum teams have to continually work to resolve dependencies and keep everything integrated. That is software development, and that is empiricism - intelligence applied to solve problems.

                    For three years I have encouraged people pursuing lean thinking to open a group where such conversations can occur in a more focused manner. It does none of us any good when someone comes on this group and says that Scrum doesn't scale, and you have to come to them and use their techniques. This reminds me of a warning from the SEI/CSMM people over five years ago - that when people followed money more than community, things could get out of hand.

                    Ken



                    On Nov 15, 2008, at 4:39 PM, Alan Shalloway wrote:


                     --- In scrumdevelopment@ yahoogroups. com, Ken Schwaber <ken.schwaber@ ...> wrote:
                    >
                    > The responsibility of getting everyone on the same page. That would be  
                    > the responsibility of the Product Owner and ScrumMaster that hired  
                    > more people to "scale" their effort into multiple teams. And, since  
                    > they are responsible for ROI and process, respectively, they would be  
                    > responsible for getting everyone they hire and who reports to them to  
                    > be on the same page.

                    I think we're talking different level of scaling. I have in mind a 350 person group doing Scrum.  There are UI devs, component devs, mid-tier, database, and more.  Essentially, several different products are involved, but supported by the common components.  There are several product owners and scrum masters involved.  In fact, the person who made the decision to scale is well above these.

                    Intuitively they (POs, SMs) know they need help - but aren't sure what to do.  The biggest problem is one of perspective.  Scrum suggests taking teams and scaling them up.  Lean suggests looking at the entire organization.  How does Lean's different perspective help?  Because it sees things you won't see at the team level. More on this can be seen in "The Big Picture" chapter of our upcoming book Lean Software Development: Scaling Agile to the Enterprise.  Essentially, the attitude is, instead of being at the team level and trying to look up, be at the organization level you are trying to improve and give direction (not command and control) and support for the teams to work things out.

                    Let me give 3 examples .  One at a technical level, one at a cross-team level and one at a team-structural level.

                    Technical level.  Given we're doing iterative development, teams are hopefully following the principles of emergent design.  This means that we're writing high quality code, but not adding functionality or design structures until they are needed.  Team A may write an encryptor without the use of an interface simply because they have need for only one.  Team B may later need an encryptor which is slightly different from Team A's.  What would be the best way for the organization to proceed is for team A to modify their code and have an encryptor interface - something that wasn't needed before.  First, it's likely team B will even know about this.  But if they do, Team A has no real incentive to help by modifying their code.  Their PO will suggest that it won't help their customers (remember these are different albeit related products).  Team A's product owner must be driven not by their customer but by the organization as a whole (i.e., follow the Lean concept optimize the whole).  Emergent design across groups has little chance of being seen or coordinated when everyone is looking at different things.

                    Cross-Team Level. How teams work together when there are different Product Owners and Scrum Masters for the different teams is not always obvious.  Again, a bigger picture helps.  This is especially true when there is a component team doing support work for several other teams.  To drive from business value requires looking across the product owners.  They may cooperate, but then again, they may not.  People are typically not magnanimous.  They tend to identify with their team or product more than the company.  The only case I've seen this not be true is when there is a very strong customer focus.  But this doesn't happen a lot unfortunately. 

                    Team Structural Level. Many scrum teams working together have serious problems delivering an end to end feature when several teams are involved.  I have seen three separate teams, one comprised of UI people, one of mid-tier people and one of database people, get much more effective when they reorganized into three different teams organized around functionality.  The people in the organized groups still performed more or less the same functions but were now able to swarm around features, not parts of a feature that was on a layer.  This caused some integration problems across the teams but enabled end-to-end functionality to be built more quickly.  This type of reorganization can only be made at a managerial level above the first level (which was how it was done at the team I was consulting at - 3rd level in this case).  Huge productivity gains were almost immediately achieved.  These teams were following Scrum when I got there and were not looking to make this change immediately because the teams liked organizing by roles - it let them do what they liked.  Managers intervened, said we need end-to-end structure and had the teams figure out how to do that.  This, by the way, is also a great example of  the fact that while managers can't do command and control - servant leadership is not really the answer either. 

                    Managers have  a responsibility for support and specifying outcomes - not merely helping out the team.  I believe much of the challenge in getting Scrum to scale is that mid-managers feel like they are being left out - that they not only have no role but are somehow bad.

                    >A standard management responsibility, except that  
                    > it must be accomplished in Scrum with servant leadership rather than  
                    > command and control.

                    Lean never suggests command and control.   Giving high level outcomes that are needed is not command and control. It simply says - hey,  we must do this - you go figure out how to do it.  I have seen a pendulum swinging in this industry between command and control and cats (programmers) doing what they want.  Managers and teams working together makes more sense to me.  Deming, the foundation of Lean, has been saying how to do this for 60 years.

                    > The difficulty is inherent in large organizations, and while lean and  
                    > other techniques are useful in attaining this, the responsibility  
                    > remains the same.

                    Here's another point of disagreement.  I believe ultimate responsibility lies with management at the top of the teams working together.  They must assist and help those under them to get the job done.  Much of this involves them removing impediments (improper team organizations, etc.) that those at the lower levels cannot.

                    In any event, I appreciate your input. I suspect we just disagree here - but the conversation has been useful (at least to me) so thanks.  I am going to try to concentrate on finishing the chapter and not so much continue the conversation on this thread.  I let you all know when I've completed the draft and posted it.

                    Alan Shalloway
                    CEO, Net Objectives
                    Achieving Enterprise and Team Agility

                    > Ken
                    > 
                    > 
                    > On Nov 15, 2008, at 12:54 PM, Alan Shalloway wrote:
                    > 
                    > > So, in this case, I believe there are two possibilities: one, get
                    > > everyone on the same page (an extremely difficult task in any but a
                    > > highly functioning organization) or two, create a team that can
                    > > coordinate the teams working together. They can't command and
                    > > control it, but can give direction (outcomes) that create an
                    > > enterprise view of things. How we've accomplished this is the main
                    > > part of the chapter I am writing.
                    >



                  • Ron Jeffries
                    Hello, Mike. On Saturday, November 15, 2008, at 11:14:45 PM, you ... I understand and accept the NDA problem. What the world needs, though, is a breakdown
                    Message 9 of 16 , Nov 16, 2008
                      Hello, Mike. On Saturday, November 15, 2008, at 11:14:45 PM, you
                      wrote:

                      > NDA's pose a bit of a problem. The specific titles of the Release Roadmap
                      > have been changed but the flow and the logic are from experience. But here
                      > goes.

                      I understand and accept the NDA problem. What the world needs,
                      though, is a breakdown like this that people can understand.

                      Ron Jeffries
                      www.XProgramming.com
                      www.xprogramming.com/blog
                      You are to act in the light of experience as guided by intelligence.
                      -- Nero Wolfe
                    Your message has been successfully submitted and would be delivered to recipients shortly.