5902[scrumdevelopment] Re: Multi-Project Development with Limited Resources
- Jan 6, 2005
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
* 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
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
"Production Super Sprints" are self-similar at a higher level of scale
to Sprints. (As "Scrum of Scrums" for multiple teams are self-similar
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
* 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.)
Michael A. Beedle
New Governance Inc.
2275 Half Day Rd,Suite 350
Bannockburn, IL 60015
- << Previous post in topic