Some Agile notes from QCon SF 2008

I'm not the most excited person about Agile (hey if it gets the job done better and quicker then great, but that's not going to turn me into a religious fanatic) but I saw some interesting stuff about Agile today so I should report.

Some guys from salesforce.com spoke about how they migrated 50 teams, over 700 people, to Scrum -- all at once! Their rationale was that it was "like burning their boat after they had rowed to the other shore", and if some teams moved and others didn't, it would be a recipe for finger-pointing, missed dependency deadlines, and recriminations. Coupled with the fact that they all commit to the same codebase (!!) it sort of makes sense.

Notes:

• Had to spend a lot of time training product owners
• Now 75% test coverage
• They have an “emergency brake” feature — if the build breaks, fixing it becomes number one priority, they don’t just roll back or deal with less coverage (this comes straight from Toyota's production system, where their assembly-line staff can stop the whole production line if they detect a problem coming from the previous workers, and all focus shifts to fixing the problem -- which usually only delays the production process by a minute or so)
• They had lots of pain, people complained a lot — but they got over it in a few months
• Phases:
  • rollout (introduced tools – own app on force.com; office hours idea for UX/documentation people)
  • adoption( release planning, sustainable velocity reducing overcommitting)
  • excellence (moved systems testing to iterative approach, scrum of scrums as issue discussions rather than status reports, dependency tracking between teams)
  • expansion
• Focus this year is working with customers and partners and helping them go agile
• Moving to IT and operations going agile..!
• Some teams use TDD, some have QA people, no one fixed type
  
• Systems testing people work with high-risk code first (which is identified at architecture stage)
  
• They have short sprints with "releases" every month, but they only do a release three times a year, and they have a non-agile month at the end of each cyclefor testing and deployment (a "release sprint")
  
• They use continuous integration even for db schema changes

What they would do differently:

• involve more individuals earlier: eg openspace/unconference meeting
• earlier, more intense training
• more coaching
• giving concrete deliverables to executives during the rollout, get them engaged

Keys to success

• exec sponsorship and commitment
• focus on principles rather than mechanics (eg not necessarily daily scrum standups etc)
• focus on making okay teams excellent to get standard-bearers, rather than working with worst teams - “know which fires to let burn and which to fight”
• radical transparency – trust.salesforce.com has uptime figures – accountable to customers
• what the heat is on, stick to your principles
• we failed – all along the way – we experimented, were patient and expected to make mistakes
• having multiple teams helped — it’s not always agile that makes teams fail, so higher number of teams gives more chance of success
  

Slides (but if you search slideshare.net for "salesforce adm" you'll see many many more presentations -- they've obviously been milking this one for a while!)

Also on Agile, I'll report a few quotes I heard from the silicon valley agile users group, which had some acronym I missed. They were having a meeting in the main room while I was doing my email, and although it started off pretty dull, they soon got animated and were saying some very intelligent things about how people were getting too caught up in the ceremonies of scrum (chickens and pigs, standups, only three questions etc) and they were forgetting that the whole point of the manifesto is to be agile, to change things when you need to, and to deliver customer value and business value. It gladdened my heart!

Some choice quotes:

• (When a prominent agile coach was asked how to sell agile to upper management:) "I ran a large agile project for (a very large organisation) for two and a half years... the whole time my boss thought it was a waterfall project"
• “agile can be gamed, just like anything else”
• "If you measure velocity by how many tasks you complete, people will complete all the easy but useless tasks. We shouldn't be measuring task velocity, we should be measuring business-value velocity... people do what they are measured by" [the mantra our VC professor Terry has drilled into us: structure drives behaviour]
  
• “we’ve gone from one dogma [waterfall] to another dogma [scrum and XP] -- I thought the whole point was that we were supposed to be agile. What happened to thinking?”