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

RE: [scrumdevelopment] Scaling Scrum

Expand Messages
  • Mike Beedle
    ... scale Scrum ... Tim, Sorry for the delayed response. Here are some things that we do beyond the “Scrum of Scrums”: Shared Resources Scrum *
    Message 1 of 2 , Jan 25, 2005
    • 0 Attachment
      Nachricht

       

      Tim wrote:

      >> Mb wrote:

      >>In our experience, the "Scrum of Scrums" is one of the necessary things to scale Scrum

      >>or Agile, but by far not  the only one.

       >

      > Could you give me some tips what I have to consider too?

       

      Tim,

       

      Sorry for the delayed response.  Here are some things that we do beyond the “Scrum of Scrums”:

       

      Shared Resources Scrum

      ·        Shared Resources Team (sometimes called Architecture team)

      ·        Shared Resources Scrum Team

      ·        Shared Resources Scrum Master

      ·        Shared Resources Daily Scrums

      ·        Shared Backlogs == Backlogs that are being co-developed and shared i.e. logging, security,

      Document management, workflow, etc.

      ·        Visiting Coach/Architect (resource from Shared Resources at Application Team)

      ·        Shared Resources Product Owner == Applications

       

      Multi-Application Scrum

      ·        All Applications Sprints

      ·        All Applications Planning Meetings

      ·        All Applications Review Meetings

      ·        All Applications Scrum of Scrums

      ·        Global Backlogs == All backlogs from all applications

      ·        Product Owner == high-level executive: CEO, CIO, VP of LOB (line-of-business), etc.

       

      Application-Level Scrums (2 or more)

      ·        Application Scrum Masters

      ·        Application Scrum Teams

      ·        Application Sprints

      ·        Applications Backlogs

      ·        Application Daily Scrums

      ·        Large Applications Scrum of Scrums

      ·        Product Owner == Customers or Business Owners of the functionality i.e. Customer Service,

      Product Delivery, Sales, Trading Desk, Network Monitoring, etc.

      Etc.

       

      A system like the one described above can swirl 200+ developers into Scrum development with some large applications,

      many concurrent applications, a common base of infrastructure, corporate development standards, and

      of course save many millions of dollars on development, maintenance; while delivering applications to make

      the business organization more competitive.

       

       

      Tim wrote:

      >> mb wrote:

      >>There is also another important list that we call the "shared backlog" -

      >>backlog that one or more teams are co-developing.

      > 

      >Upps - never heard of this before. Could you explain to me, what exactly is in there?

       

      The “shared backlog” is backlog that is being co-developed by a partnership from either two applications,

      the shared resources team, or two subsystems within an application.

       

      For example, if a new workflow system is being developed with a partnership through two

      Application team and the shared resources team, then this shared backlog is discussed in the

      Shared Services Scrum of Scrums, and in the All Applications Scrum of Scrums.

       

       

      Tim wrote:

      >Some more questions:

      > 

      >What will you do, when a product backlog item has to be implemented by more than one

      >subsystem project? My idea was to decompose it, so to assign broken down

      > component backlog items to the projects (of course they will do this on their own ;-).

       

      I think this is very close to what we call “Shared Backlog” in a large application, in this case

      2 subsystem teams partnering to develop “shared functionality”.

       

      Tim wrote: 

      > What about the initial questions of commiting the value of a sprint?

       

      For all the teams at once this is typically done at the All Applications Planning Meeting – a high-level

      executive is the Product Owner i.e. like the CIO, or CEO, but it varies with the company.

       

      For each team individually it is done at the Application-level Scrum and needs to be compatible

      with the multi-application Scrum – each application has its own Product Owner.

       

      For the Shared Resources Scrum Team, it is done at the Shared Resources team with the

      Product Owners being at the applications themselves.

       

       

      Tim wrote: 

      >Having two components tied together in one scrum of scrums,

      >how will the sprint planning meeting take place?

       

      If at all possible, get the Product Owner of the large application and all the subsystem (or application-level)

      Scrum Masters in one room to determine the Large Application Sprint Backlog.

       

       

      Tim wrote: 

      > Because there are three scrums, are there three planning meetings?

       

      In a large application environment typically no – the backlog is simply partitioned, and managed through 3 different

      Sprint Backlogs through 3 different Daily Scrums.  After all, the application must be coherent.

       

      This is because the backlogs of a single large application are typically much more dependent and much more

      coherence is expected.

       

      As I have always said, the key is in daily testing, daily integration, and (at least) daily builds that

      *prove* real progress.

       

      In a multi-application environment with shared components typically there are typically less dependencies,

      so it is much easier to have 3 Scrum Planning Meetings with 3 different Daily Scrums, but again

      if there are shared components, only *frequent* testing, integration and builds are going to prove

      the dependencies are taken care of.

       

      Tim wrote: 

      > How can the people in the scrum of scrum planning meeting commit to something?

       

      As they always do, all Scrum Teams must estimate what they can do.  If a multi-subsystem large app,

      each team must evaluate how much more they can commit to.

       

      In very large apps, the need for a Large App Shared Resources team can also be justified,

       

      I hope this is helpful,

       

      -        Mike

       

      ** Co-author: Agile Software Development with Scrum, Schwaber and Beedle 2001

       

      Michael A. Beedle

      CEO

      New Governance Inc.

      2275 Half Day Rd,Suite 350

      Bannockburn, IL 60015

      www: http://www.newgovernance.com

      Office: 847-821-2631

      Cell: 847-840-9890

       

       

       

       

      -----Ursprüngliche Nachricht-----
      Von: Mike Beedle [mailto:beedlem@...]
      Gesendet: Montag, 24. Januar 2005 21:20
      An: scrumdevelopment@yahoogroups.com
      Betreff: RE: [scrumdevelopment] Scaling Scrum

       

      Tim wrote:

      > I have got a few questions for the community here - I did not find the answers in the already

      > discussed entries or in the net....it is all concerning Scrum of Scrums:

       

      Tim,

       

      In our experience, the "Scrum of Scrums" is one of the necessary things to scale Scrum or Agile, but

      by far not  the only one.

       

      Tim wrote:

      > product backlog: is there a product backlog for each scrum?

       

      Yes, but in our world the project backlogs are sub-lists of what we call a "global backlog".

       

      There is also another important list that we call the "shared backlog" - backlog that one or more teams

      are co-developing.

       

      Tim wrote:

      > Are the items on the top level product backlog decomposed into a top level sprint backlog, which then

      > becomes part of the product backlogs for the next layers of scrums?

       

      Not, in our experience, the backlog is flat, and it is only partitioned in chunks, not layered.

      (Layering typically brings more problems and also "flattening" gives you the ability to easily query

      across one of more projects much easier, in our experience.)

       

       

      Tim wrote:

      > One more: Has somebody practical experience in scaling scrum...?

       

      Yes, many of us do.  So far our record is 15 concurrent applications sharing the same infrastructure.

       

      I would be interested to know if anyone has beaten that.

       

      In my opinion, the conquering the enterprise in large numbers is the next step for Scrum.

       

      I will go further and predict that Scrum has the most "enterprise agile projects" under development, and that

      also quite possibly has the largest number of successful "enterprise agile projects",

       

      -        Mike

       

       



      To Post a message, send it to:   scrumdevelopment@...
      To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...




      To Post a message, send it to:   scrumdevelopment@...
      To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...

      <hr

    Your message has been successfully submitted and would be delivered to recipients shortly.