Agile 2009: Agile at Yahoo from the Trenches
Ow. 23 pages of notes to write up - I fell a bit behind preparing for the workshop. Of which more, later...
Agile at Yahoo from the Trenches was a good first-hand look at an organisation going through an agile adoption. I'd read the paper that Gabrielle Benefield wrote a few years back on this, so was curious to hear some more personal stories. My notes:
- Yahoo! was a business that grew through acquisition, so ended up with many "city states" of different cultures;
- Senior leadership tried to rationalise these by introducing a Product Development Process, heavily waterfall, which dev teams paid lip service to but didn't buy into;
- The first experiences with agile had an emphasis on processes and mechanics rather than principles; engineers were reluctant, UX teams wary, QA were doubtful. Only product management and upper management were sold on it, and it quickly made some organisational dysfunctions visible;
- In 2005, an Agile coach was brought in and 4 teams volunteered for a pilot of Scrum. The coach ran voluntary training classes;
- Teams that didn't volunteer felt that their product was too complex, heavy UX was required, that agile couldn't meet their needs for global simultaneous launches and that it introduced too much risk;
- The pilot succeeded in that pilot teams delivered on time, that they were cross-functional teams integrating staff from across the business, and that some of the teams were doing technically complex or UX-heavy work;
- External dependencies were still a problem, and integrating UX was tough;
- By 2007 they had 150 Scrum teams globally; successes built trust and agile was soon mandated by the business;
- This "agile boom" led to a dearth of coaches, so teams struck out on their own;
- In 2008, staff cuts led to the coaching teams being disbanded, which in turn led to many mash-ups, a lot of cherrypicking of practices, and flawed adoptions. These in turn led to severe micromanagement, "Scrummerfall", and "meeting hell"; the conclusion from this is that bad agile is worse than no agile at all;
- Between 2008 and today, top-down mandates have led to continuous integration being adopted across the board, global product roadmaps, and a balancing out of product management (Yahoo! had too many product managers unevenly distributed throughout the business previously). Meetings are also now much leaner, with meeting discipline being focused on;
- But... bad implementations had incurred technical debt, management time is scarce, management trust isn't unconditional, and the word "agile" has a bad rap within the business: it's an overused and diluted term. There's also a sense that something needs to be added to it, for it to work well: "agile with stability". (The speakers found this ridiculous);
- Third party dependencies are still a problem, particularly when dealing with open source projects like Hadoop: how do you get commitments from volunteers working on Open Source projects?
- Thoughts on how to make agile adoptions stick: understanding and trust; visit other teams in action; and talk to experienced practitioners;