I attended a talk by Jeff Sutherland at the Bellevue Harbor Club this afternoon. It was an invitation only event thrown by one of my suppliers. I wanted to capture a few memories from the event - and make them available to you all.

Venture Capital. He started out by suggesting that venture capital firms will be unwilling to invest in firms not using agile development and went further to state that as Scrum and XP has 90% market share of the agile methods space, that only firms using Scrum and XP will receive investment.

Agile Adoption. Later he was questioned about the notion, "that if agile is so great why isn't everyone doing it?" He admitted that agile still represented less than 10% of the market but that he fully expected with the current rate of growth that agile would be the dominant method soon and would be the only method by 2017. He called this the "lilly pond effect."

Test First Development. Jeff defined a difference between Test First Development and Test-Driven Development and his definitions would match mine. Test-Driven Development is a specific technique that grew out of Extreme Programming where Unit Tests are used to drive the emergent design of the code and there is no explicit design or subsequent code review against design, whereas Test First Development is simply the notion that tests are created prior to any code and effectively become part of the specification. There isn't a focus on emergent design with Test First.

Agile in a CMMI Level 5 Org. A large section of his presentation focused on a CMMI Level 5 company that had deployed Scrum and produced approximately a 2x productivity improvement over their already very high quality processes. This has allowed them to bid jobs at half the price. They now offer two bids - one based on waterfall at 2x the cost of the other based on Scrum. They ask that the customer agree to participate in Scrum as part of the contract. Very cool!

I asked Jeff if he thought he had evidence that high maturity organizations can adopted agile faster and better than low maturity organizations. He went on to quote a couple of other examples, one where the company was already good at Six Sigma, where agile was introduced as pilot under strict process improvement supervision. Once proven, it was quickly replicated throughout the organization. These high maturity organizations had scaled agile methods across the org within 9 months or so - very impressive. And further proof that high maturity and agile are highly compatible.

Lean Maturity Model. He also showed some Lean maturity and adoption model based on work by the Poppendiecks (I think. It wasn't clear with the Poppendiecks had done all the work.). This was very cool and I want to learn more about it. Corey Ladas and I have been talking recently about a Lean Adoption Cycle and providing specific guidance for how to drive Lean Software Engineering adoption. I'd like to compare the two.

New Paradigm. Jeff also talked about how Scrum is a different paradigm and how to shake some folks out of their old way of thinking. Two specific pieces of advice - ban Gantt Charts, and ban time sheets and time reporting - were in my opinion particularly poignant.

Agile at Scale. The talk focused on case studies that showed the benefits of agile practices and data that showed scale to projects in the 500K-1 Million LOCs range, with high maturity organizations with CMMI Level 5 appraisals and with distributed teams. Particularly interesting was one study where management had decided to only have distributed Scrums, i.e. teams where the members where in at least 2 locations. The typical Type B Scrum where teams collocate around some architectural decomposition - this approach has also been widely documented by others for non-Scrum-branded methods - was not adopted. Instead the teams were asked to overcome the distance challenge and achieve collocated levels of velocity despite the dual location. The result was that the management could later turn off the second location and achieve a linear reduction in velocity without loss of tacit knowledge of the system. If they'd adopted a Type B solution then they'd have lost a lot of knowledge of the 2nd part of the architecture and any maintenance to that part would have suffered a severe non-linear drop off in velocity.

Non-co-located Agile Teams. It sounds really hard to achieve non-co-located agility, but the benefits of overcoming the challenges seem to be exceptional. I've seen Ron Jeffries comment recently that when something seems hard, you should practice doing it often and get good at it, so that any one time does not become a burden. I recognize this advice with what we've been doing with respect to software releases. We've released 33 time since last September. With each release, we first practice the release in to our staging environment. So actually we've released 66 times in 46 weeks. Needless to say, we've got really good at doing releases, and it is now so smooth that no one gets stressed and the organization hardly notices when a release is going out. The transaction cost of releasing has fallen dramatically. Jeff's client appears to have achieved a similar level of capability at distributed non-co-located agility. Technorati tag: Agile, Scrum, Jeff+Sutherland, David+Anderson, Lean, Corey+Ladas, Mary+Poppendieck