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

5902[scrumdevelopment] Re: Multi-Project Development with Limited Resources

Expand Messages
  • Mike Beedle
    Jan 6, 2005



      Hi Mike,


      Thanks for the pointer. Some questions that I have:


      1. What do is the difference between a Shared Resources Scrum Master

         and a 'normal' (is there anyone normal among us ;-) ) Scrum Master?







      The "Shared Resources Scrum Master" is the Scrum Master for the

      Shared Resources team, if there is one (either the team or the

      ScrumMaster for it).  (Don't you love that answer?? :-)


      Let me explain.  The "shared resources team members" have as a goal:


            * promote the conceptual integrity of the enterprise architecture

        and applications

            * promote and facilitate enterprise component reuse

            * provide coaching, training and mentoring for application development      

        team members (both process and technology)


      The "Shared Resources" team codes stuff in cooperation with other teams.  

      The "Shared Resources" team members are in many cases on loan to other teams.  

      These members carry "central DNA", that reminds the application teams there are:


      ·        design and architectural standards 


      This prevents application developers from re-architecting applications

      that are not compatible with enterprise standards.


      ·        reusable business components (some under development)


            This prevents business developers from re-inventing the
            "business component wheel"

      ·        coding standards


            This helps and reminds the application developers that there are

      enterprise coding standards  (The goal is that all code throughout

      the enterprise in a particular architecture looks and feels the same.)


      ·        infrastructure components that need to be used


            This prevents teams from recreating things like "single sign on",

            "authorization services", workflow, document management, faxing,

      printing, logging, etc., etc.



      The "Shared Resources team members" live with the teams, but meet with the

      "Shared Resources Scrum Master" at least once again in the same room, where

      the 3 questions are asked.  (Yes, those 3 questions you already know from

      basic Scrum.)


      The goal of the Shared Resources team is to eventually have teams with no

      "Shared Resource team members", and instead have a representative of

      the application come to the "Shared Resources Meetings".


      The "shared resources team" is sometimes called "Architecture team", but

      I prefer "Shared resources" because the Architecture name has in some

      places negative connotations, as in "high-level non-writing code experts

      on top of white pedestals", etc.  Actually, I believe there is a

      "good breed" of architects that resemble more "coaches", but then we

      had to call the team the "Coaching Team", which is even harder to understand.



      "2. What do you mean by 'Production Super Sprints'?"



      Many applications are developed concurrently, most of which use and

      deploy reusable components.  Because of these dependencies, the

      "reusable code base" needs to be tested and deployed all-at-once in a

      "Production Super Sprint", which encompass one or more individual

      application Sprints.


      "Production Super Sprints" are self-similar at a higher level of scale

      to Sprints.  (As "Scrum of Scrums" for multiple teams are self-similar

      to "Scrums".)


      In our case we do scaling at two levels: technical and management.


      So our "Scrum of Scrums" apply to:


            * application team leaders (to decide Production Super Sprints and

        Enterprise Releases)

            * technical leaders (to decide Production Super Sprint contents)

            * Shared Resources team members (to evolve Enterprise Development and

              Architecture through application Sprints and Production Super Sprints)

            * Shared Resources sub-teams (to coordinate dependencies among shared

              Components within the Shared Resources team.)


      Of course then you have regular Scrums:


            * Application Scrums

            * Shared Resources Scrums



      "3. Would be intersting to hear, how you do this in the concrete

         -> Integration Testing across applications and reusable components?




      Throw all enterprise applications into a single integration server and

      bang away (through both automated tests and manual tests).



            (Btw: What happend to XBreed?))


      XBreed was renamed "Enterprise Agile Process" to avoid confusion -- a

      much better name for its purpose:


            Concurrent Agile Application Development


      (All references to XP engineering practices have been removed, since that

      was most of the confusing element.  "Enterprise Agile Process" can

      use *any* engineering practices.)


      Using this system we developed 17 applications at a large PBM here in Chicago ,

      and since they have extended this number to something like 25 apps.


      To my knowledge, this is the highest number of concurrent applications

      being developed in an "agile way" using reusable components.  (Some of

      the apps, at least 5, are very large 200+ screens.)


      This method has been refined over the years.  Our first experience

      with it was in 1996 at a large benefits management company, and then

      used it again in Insurance, and Financials, with different levels of



      The challenge for Agility and Scrum in particular today is:


            Enterprise Agile Development


      with multiple concurrent and dependent projects being developed all-at-once.


      This is where Agility will make "most business sense" i.e. highest

      ROI and risk mitigation.


      At this level of scale Agile Software Development is almost synonymous with

      Agile Business Development, and for the most part:


      the enterprise software is the business


      (Think Telecom, Financials, Insurance, etc.)


      - Mike


      Michael A. Beedle


      New Governance Inc.

      2275 Half Day Rd,Suite 350

      Bannockburn, IL 60015

      Email: mike.beedle@...

      www: http://www.newgovernance.com

      Office: 847-821-2631

      Cell: 847-840-9890


    • Show all 29 messages in this topic