| 
  • 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.

View
 

Scaling SCRUM

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

Day 2.

10-11am.

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)

mainframe

distributed

EOW

 

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.