• If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • Stop wasting time looking for files and revisions. Connect your Gmail, DriveDropbox, and Slack accounts and in less than 2 minutes, Dokkio will automatically organize all your file attachments. Learn more and claim your free account.


Scaling SCRUM

Page history last edited by Generic Account 11 years, 5 months ago

Day 2.


Scaling SCRUM by Dan LeFebvre (Osceola 6)


@ Chronos:

400 people, 30 teams, 20 products

How do you coordinate the work

- scrum of scrums (SoS) didn't work b/c of lack of coordination. VPs didn't want to do the coordination

- SoS SHOULD be all a/b removing impediments

- built the parallel PM structure


Parallel Project Structure:


1) Suite Management Team (SMT)

- steering committee

- 1 director and 1 product owner from each of the 3 organizations

- Meetings ~ once a week (1hr)


2) Suite Integration Team (SIT)

- Install suite on a set of integration servers each week

- Creates and runs series of suite - wide tests

- Meetings ~ once a week (1hr)

- Out of ~60 participants ~35 showed up at a time

- facilitated by a member of the SMT


3) Suite Release Team (SRT)

- met once a week

- Scrum Master and Product Owner from each team (60 people)

- Responsible fro coordinating dependencies and resolving suite-wide issues

- Primary communication vehicle for the suite


Sprints weren't synchronized


How to sync the suite?

- create release candidates every 6-8 week with an "RC"

- sync on the RC (release candidate) "heartbeat" (see the photo on blackberry)


Dealing with Impediments.


1st attempt: ETC (Enterprise Transition Counsel)

- senior exec doing the work of prioritizing and resolving org impediments

- identified by the dev teams

- resolve by creating small teams to remove impediments


2nd attempt: Scrum Implementation Team

- small group of 8 people from across the org

- issues:

- not all skills represented

- limited time to work on this, still had day jobs



3rd attempt: ScrumMaster Meeting

- hold a regular meeting of ScrumMasters to identify, prioritize, and volunteer to resolve impediments

- this group got some traction


4th and last attempt: Agile Leaders Meeting

- met every 3 weeks

- regular meeting of ScrumMaster, Product Owner, and Architects lead by Agile Coach

- agenda includes a brief coaching session on an agile topic from one of the team (as a freebie to improve attendance)

- review of resolved impediments, identifying and prioritizing new ones, and volunteering to resolve highest priority

- Q&A session to solicit help from team and coach on individual issues

- resolve over 50 impediments in 1 year


Problem statement:

- Alignment problem

- Dependency problem (see the pic)


Dan Greening (citrix online)


Another view:

- Optimize for ROI, cost and value-driven process (see photo)

- Run quarterly sprints for Enterprise SCRUM


Enterprise SCRUM model:

- 250 engineers, 24 scrum teams, responsible for separate products (citrix, gotomeetings, gotomypc, SaaS, different separate products) (see picture)

- Enterprise Scrum Master, VP of engineering, all PMs and SMS, Chief Architect, all architects

- Q: how often the enterprise scrum happens? A: Weekly SCRUM, not stand-up, go through backlog and check on status

- Can't put anything on the enterprise backlog unless it's at least 1 team month in scope

- about 22 items on the enterprise backlog

- plan quarterly (all items in the backlog are less than a quarter in terms of size)

- Use an Estimated Team Month as the unit of measure

- Quarter is the sprint

- Enterprise Sprint planning is ~2 hours BUT there is grooming for that (that includes estimating which itself is NOT done in that meeting)

- 1 Team Month x 100 = Enterprise Story Point (each enterprise story point costs ~$1,000)

- Use VersionOne

- they don't synchronize sprints, operate independently when they can, on different schedule (b/c of conf rooms and cross-pollination of architects etc)

- don't let anyone work on anything other than the stuff on the backlog

- estimations:

     the perfect is the enemy of the good - just do it on all levels, people/teams ahead of the process

          Q: do you portion items between the teams?

          A: Product managers do it

               - Achievable but aggressive goals

               - actual to estimated velocity ratio is 0.7


Product managers initially didn't have ROI, but they had the DCF (discounted cash flow)

Profit = DCF_Revenue/DCF_Expense (DCF_Expense is the cost of the team)


What enabled Citrix Online to do this?

1) the president

2) Dan

3) VP of Engineering (Dan's boss)

- take specialists and put them into cross-functional teams

- they have some component teams

- Can't let the backlog get too big (more than 20).

- If you can't do it manually, it's probably too complicated


Mike Cottmeyer (VersionOne)

ELF (enterprise level feature) (A, B, C)





Each team would work on each A, B, and C (see pix)

Each team can be self-organized but not the master structure itself

Feature team is the way to go... until you can't

Don't manage dependencies, break dependency

Perfect nirvana: SOA with each service covered by a team



Design Structure and Matrix (see pic)

"IS"   vs   "Does"   vs   "Are"




Comments (0)

You don't have permission to comment on this page.