program selection system

In this experience report, we will show how Agile brought about multiple waves of transformative change – one at the team level, and the other at the organizational/business unit level. We will go through the history of one such team in Yahoo! to highlight some of the transformational changes that the team went through, and how their changes affected the levels up the organization. This will be a 30-minute presentation followed by Q&A session, with a paper published in the proceedings.

The First Wave: 2005/2006
1. History
- Prior to adopting agile development process, the team had challenges to deliver business objectives and communication was a major issue.
- Fire drills after fire drills and heavy burnout
- Half of the team were relocated to Southern California (from Northern California) in Q4 ’05
2. Agile Transition
- The team was trained in Scrum in Dec 2005, and started running scrum first Monday of Jan 2006 (Jan 9th, 06)
- Agile coach was involved with the team.
- Team had a hard time initially (a. Breaking down tasks, b. Coming up with a product backlog)
- Team consistently worked on improvements through retrospectives
- Instituted a “sprint break” – a break after doing a number of sprints back to back
3. Results
- By the end of Q1 of 2006, the team delivered so much more that they were specially mentioned in the State of the Product report released by the Chief Product Office
- Team morale increased
- Team was able to collaborate even when they were 300+ miles apart
4. Transformative Change: Team Level
- Team started delivering
- Team’s pride and morale increased

The Second Wave: 2006/2007
1. History
- Q2 2006 the team learned Story Points
- Team was using Scrum, but quarterly release planning was still done in a waterfall manner.
- It was hated by the team, and release planning became the curse word.
2. Logistics
- The team was trained on multi-level planning (Jean Tabaka) – November 2006
- First release planning was done after training – Jan ’07 for Q1 ‘07
i. Stories for the entire quarter were divided into the 3 months based on business priority
ii. Then the team created high level tasks against each story (by month)
iii. Then the team started out with the top priority story of the month and put it in that month and continue this process until the team thinks they are full for the month
- Then repeat step iii) for the following month.
- When it came to the 3rd month of the quarter, the team looked at the leftovers from first 2 months + the originally assigned for 3rd month and re-prioritize
3. Result of first release
- The team – using Scrum – started delivering consistently every quarter.
- With release planning, they were able to track the progress of Q1’07 – delivered 85% of planned (+ unplanned/changed stuff)
4. Transformative Change: Team and Business Unit level
- The team was able to build trust with upper management
- The team was more comfortable and started to spread the Agile DNA within the business unit; other groups in the division started to use Scrum

The Third Wave: 2007
1. History
- Inspect and Adapt: the team over the subsequent release planning started to use unique practices to the team
- Release planning PostIts replicated in both Sunnyvale and Santa Monica
- Distributed team release planning among Sunnyvale, Santa Monica, and Bangalore:
- Q1 release planning:
i. Bangalore team did not participate in Q1 07
ii. Santa Monica (SM) team stayed in SM except for the head designer and one product manager. The rest of the SM team communicated via video conference
iii. Result: Santa Monica team felt disconnected. It was better to be all in the same location.
- Q2 release planning:
i. One visiting member of the Bangalore team, without being trained, participated (and he got the gist of it!)
ii. So, moving forward, the team requested one member of the Bangalore team to be present in Sunnyvale
iii. The head of product management and all of the designers flew up to Sunnyvale. The rest of product management team was available via video conference.
iv. Result: New process worked, the team had better collaboration. They also had better knowledge of priorities and goals.
- Q3 release planning:
i. One member of the Bangalore team, the head of product management and all designers flew up to Sunnyvale to join the engineering team.
ii. Rest of the product management team was available via video conference
- Roles and artifacts in each locale
i. Santa Monica – Product Management, Designers, Web Developers
ii. Sunnyvale – Engineering
iii. Bangalore – QA
2. Logistics
- Q1:
i. Since no team can do everything, every time there was an additional request from upper management, the Scrum Master went to the general manager(GM) to prioritize or tradeoff the latest additions against the committed items
ii. The stories in release plan were prioritized, with approval by the GM and head of engineering
- Q2:
i. The stories were put in 4 priority buckets, with one non-negotiable bucket and one bucket indicating additional resources needed
ii. Same process with the GM
- Mid-Q2 and onwards:
i. Stories priority buckets were the same
ii. At this point, upper management and GM no longer needed to be reminded that the team could not do everything. The tradeoff happened in the Product Management level
3. Results
- Q1 – delivered 85% of planned (+ unplanned stuff)
- Q2 – delivered 90% of planned (+ unplanned stuff)
- Q3 – delivered 92% of planned (+ unplanned stuff)
- Easily integrate unplanned items
- Limiting features to the essential
- Team commitment increased
- Team participation increased
- Team health and morale stabilized – mandatory sprint break
4. Transformative Change: Organization and Business Unit
- Instead of one big bang for a release, the team was able to negotiate 3 iterative release schedules with the VP of the Business Unit
- By the end of the 2nd release, the team was ahead of financial plan metrics
- As a result, VP had de-scoped and called off the 3rd release – a first ever for a product at Yahoo!