PMI Agile, Agile PMP, MegaScrum, Scaling Scrum, Massive Scrum, PMI Agile

1. Distributed globally; it is unrealistic to assume that the people involved can get face-to-face time
2. Volunteers populate the leadership and teams
3. The work may not be related to IT or Software
4. The work has fuzzy requirements that are ever-changing and based on events
5. The work has the potential to dramatically scale up or down, meaning the total number of people involved must shift quickly to match

An object example project is the PMI Agile project, where I currently serve as Scrum Master.

The PMI-Agile project is an effort to establish an Agile Community of Practice with the Project Management Institute (PMI). PMI issues the Project Management Professional (PMP) credential. The PMI has charted the Agile Community of Practice. This volunteer effort is staffed by volunteers who live all over the world and are working to accomplish a single mission: "to bring Agile knowledge and Agile skills to all PMI practitioners."

Projects like this need a flexible Scrum structure. The following Scrum structure can adapt and be flexible as the project scales up and down. The structure can contain the current workload and scale—up and down. We do not want to change Scrum structure all the time as the project shrinks and grows. We need a durable and lasting and effective structure. It must handle distributed, global, all time zones, non-IT project, fuzzy ever-changing requirements, and no known end date, all done with volunteers.

A Scrum structure for Massively Distributed non-IT projects

The following diagram and text describes a candidate structure that addresses the challenges of a distributed volunteer project while remaining true to the Scrum values. This diagram depicts the largest scale and is fractal; that is, it can be repeated to any arbitrary size and scope.

Projects with the characteristics above need a flexible Scrum structure. The following Scrum structure can adapt and be flexible as the project scales up and down. The structure can contain the current workload and scale—up and down. We do not want to change Scrum structure all the time as the project shrinks and grows. We need a durable and lasting and effective structure. It must handle distributed, global, all time zones, non-IT project, fuzzy ever-changing requirements, and no known end date, all done with volunteers.

Please note that a more compact form of this structure is described at the end of this document. That more compact structure can be used as a starting point. As the project grows, it can grow in this direction. Click the link to see this more compact form, based on the Bioteams model.

This is a flexible Scrum form, that is durable at any size, from very small to very big. Thus this structure encourages shared understanding at all phases. This eliminates the waste inherent in having to negotiate a new structure every time the project changes in size, scope, up or down, etc.

Diagram notes:

1. AUTHENTIC SCRUM STRUCTURE
a. Team Count. Topmost structure is bounded by green perimeter. It includes PO, SM and team of 7 or less members. This 7 is a rule to keep complexity low for the topmost PO.

b. Roles. The 3 Scrum roles serve to reduce complexity. Many roles, much complexity. Fewer (3 Scrum) roles, dramatically reduced complexity.

c. Top PO. The Topmost PO’s primary role is to a)see the big picture, b)make adjustments to direction based on that, and c) to at all times encourage and enforce values via positive and negative reinforcement of same. The top-level PO is/must be the key influencer of Culture across the entire project.

2. AUTHENTIC SCRUM CULTURE IS KEY
a. Culture. Culture is a collection of Values which inform the behavior of a group. Beliefs inform Values. Therefore Culture and Beliefs are linked via Values. The [Beliefs-Values-Behavior] needs to be constantly reiterated to the entire community of project participants. This is what makes the distributed worldwide effort cohesive and effective. Therefore, the Scrum values are key, as is reiteration, repetition and reinforcement of those values. The top level PO must embody these ideas.

3. ADAPTED SCRUM STRUCTURE:
a. Structure: Topmost Backlog is never more than 7 Epics. Each Team member owns one Epic. The red border depicts how each Team member is also a (sub)PO for a (sub) project, 1 per Epic.

4. 1:1 TEAM MEMBER:EPIC relationship, 1-to-1.
a. Each Team member is in turn a (sub)PO for a (sub)Backlog. The (sub)Backlog deconstructs the Epic into many Stories.
b. Topmost Team members play a two roles at two levels: Team member and PO for an Epic-based (sub)Project.

5. CADENCE; ITERATION PERIOD.
a. Iterations are two weeks long.
b. The topmost PO and SM run a weekly concall. This concall is in the daily Scrum format. The primary purpose of the concall is to track progress since the last call and to detect any “values events” since last call, to be addressed.

6. 1:M SM:TEAMS.
a. Each (sub)Project that addresses a single Epic is managed via a Scrum PO and SM. One SM can Scrum 2 or more projects. The area bounded in blue depicts one person occupying multiple SM roles across 2 or more projects. Thus, only 3 or 4 SMs are needed at the top.

7. AUTONOMY.
a. (sub)PO’s are free to run the project as they see fit, consistent with Scrum values. Each PO has a Team and if it grows in size, a Scrum Master to help get rid of obstacles in the way of the Team.

8. BACKLOG GROOMING AND PRIORITIZATION.

a. Current items. Each iteration, PO prioritizes the 7 items. If backlog item X is topmost for current iteration, then PO says that. If X and Y need to be priority #1 and #2 on backlog for this iteration, with a 60-40 split, PO says that.
i. From there Team members figure it out, AFTER the call.

b. New Items. If a new item appears, PO places on backlog. Team figures out where it fall ‘under’. If it is a top-most item, one of the existing 7 must be folded-under-another to keep the count at 7.
i. The team figures all of this out during call but likely (and probably more effectively) the next day after thinking hard about it.

c. Item completion. When one of the 7 items is complete, it can be deleted to make room for another new item to add in to form the 7-max. As a top-most item becomes done or less important or nearly done, it can be subsumed by the existing remaining 6, opening up a new spot for a new item.

d. Summary. The topmost 7 items are adaptive yet highly structured with intent to dramatically reduce complexity for PO, who can now focus on the horizon and near-term effects without being overwhelmed.

9. SCALE.
a. (sub)Projects that become large may further subdivide, by taking on the adapted yet authentic Scrum PO/SM/Team structure, where each item on the backlog is an Epic, there are never more than 7 items, and each Team member owns an Epic and develops a (sub)Backlog. This is done as needed, as the project evolves in scope, magnitude and volume of work.

10. STAKEHOLDERS.
a. Not depicted in the diagram are the stakeholders related to each PO in the structure. Stakeholders may advise any any PO on any matter at any time.

11. BACKLOG MAINTENANCE BY PO
a. Add Item
i. Items are held to 7, when a new item is added, it as appended to become 8. The team figures out how to incorporate the item to bring the count down to 7. How this is accomplished can take many forms. The team decides the form of incorporation of the new element in to the 7.

b. Change Item
i. PO communicates to team about the changed item. Team figures out how to incorporate the change to maintain stability of the 7 items while incorporating the change.

c. Remove Item
i. Done. Items may be removed as the backlog item gets done. A backlog item’s remaining few elements may be placed elsewhere, such that the backlog item is nullified. Takes the count down to 6 and makes room for a new 7th item. PO’s job as backlog owner is to notice the done-ness and communicate to team the perception that this backlog item is done. Team decides how to clean it up.

ii. Obsolete. Items may become obsolete. Events and situation may render an item so unimportant that does not just have a low priority, but in fact needs to be removed from the backlog to make room for a more pressing set of concerns. PO communicates the fact that the backlog item is obsolete; team decides how to close it down in a timely manner.

iii. Items may need to be split due to growth. In this case PO communicates to team the perception that a Epic is too big, and needs to be split. If there are now 6 items, this is easy since there is room for a 7th. If there are now 7 items, some items need to be collapsed elsewhere to make room. In all cases team works with PO to accomplish the split and related delete(s) that may be needed.

d. Prioritize Item
i. At the start of each iteration, PO prioritizes backlog. PO orders the 7 items and communicates to team the percentage of focus on each item for this iteration. Team figures out how to accomplish this during the iteration.

1. Typically, the iteration focuses on the top 2 or 3 backlog items. Each of these is assigned a percentage of the total effort, for example 60-40 or 50-30-20.

2. Top-level team members (1 of the 7) who have bottom-most backlog items for this iteration volunteer to the extent they are willing, to enlist as sub-backlog team members. The team figures this out.

3. Note that the entire focus of the team of 7 is on the topmost prioritized backlog items as communicated by the PO. This is pure Scrum, adapted to a distributed, all-volunteer, non-IT project.

12. CORE TEAM MAINTENANCE

a. Seven backlog Items, seven people: The team is always 7 or less people, each tied to an Epic on the topmost backlog.

b. Selection of the 7. Initially there are 7, selected according to some criteria. Once the 7 are formed and linked to the 7 backlog Epics, some process for rotating people out and selecting new people in to the team is needed.

i. Fluidity. The team of 7 work as a fluid team, working where they need to work per iteration,. This is based on PO’s prioritization. If my Epic is low-priority, I enlist as a member of the sub-team that is addressing the work for this iteration. Thus, I work with you (as a peer), I work for you (as a member of your team) , and sometimes you work for me as a member of my team when my Epic is the focus of the iteration. Note that this requires an advanced skills in teamwork and a real sense of team overall.

ii. Term limits. The top-level 7 team members probably need to have some kind of term limit, such that new candidates are constantly being groomed. This encourages a healthy, robust system of team development and a farm system based on accountability, mentoring and trust. The 3-rings of Accountability inherent in the Bioteams model is the preferred way of pulling this off. However each individual in the team of 7 may organize their teams in the way they prefer. Over time best practices emerge and everyone gains experience on each other’s teams, on a per-iteration basis. See 12.b.i.

iii. Core team, Extended team, Ancillary team. The bioteams model has 3 rings.

1. Core team. The Core team is the center and has the most authority and information and connection to sub-PO. The Core team takes direction from the PO.

a. Core team members are candidates for ‘team of 7’ membership on the top-most backlog.

2. Extended team. The Extended team has a little less authority, less information, and less direct contact with PO. The extended team executes on work that is largely prepared by the Core Team.

3. Ancillary team. This Ancillary Team has little authority, and little information beyond the detail found in pullable backlog items. This is the entry point for anyone that wants to come into the project.

BIOTEAMS RINGED STRUCTURE

3: Core team; 2: Extended team; 1: Ancillary team

13. ALTERNATE STARTING POINT; SMALLER SCALE
a. Overview. The project can start smaller, with a team that has a bioteam structure, with the same max 7 Core team members, and an Extended and Ancillary team as outer concentric rings. In this compact form, there is one huge backlog, one top-level PO, one top-level SM, and one Team with 7 Core members. This structure can later scale up as needed.

b. Detail.
i. The bioteams structure provides an entry point, a “farm system”, and a progression of Commitment.

1. Entry point. The outermost Ancillary team is the porous entry point where anyone can probe the project by pulling backlog items. These items available to Ancillary team members are NEVER on the critical path.

2. Farm system. One of the 3 rings is the Extended team. This non-Core team layer provides the candidates for Core team membership and allows a rotation of Core team members.

3. Progression of Commitment. People who join the project can enter at the Ancillary Team level, prove they can do work, and then move into the Extended team, where they get closer to the Core, get more access to more responsibility, authority and information, and develop as candidates for Core team membership

Jeff Sutherland on Bioteams:

"The values inherent in the Bioteams model are a near-100% overlap with Scrum values"

BioTeams References:

http://www.bioteams.com/2008/09/08/the_3_rings.html#more

http://www.bioteams.com/flash/IsYourGroupaBioteam.html

http://www.bioteams.com/2008/04/04/online_team_assessment.html

http://www.bioteams.com/2009/01/12/bioteams_101_introduction.html#more

**end**