program selection system

This talk will tell the story of how to do agile development in the upcoming version of visual studio. We’ll talk about agile planning, quality early, TDD, continuous integration and improvement, connecting with customers and a host of other agile practices enabled through the new VS tools. This talk will showcase the tools by walking through the story of building Team Foundation Server v.next using the Visual Studio tools.

You’re the executive-sponsor of your division’s foray into agile. It was successful with the first development team; you saw good results with the second and third; by the fourth you knew you had something! Now you want to roll it out across the entire organization. But each of your teams approaches agile differently. You’d like a consistent approach, but you don’t want to stifle the culture of cooperation and coordination that agile has brought to the organization. How do you scale with a consistent approach that also supports The Manifesto?

This session is designed for agile practioners who are seeking to improve practices in large agile programs. It is targeted for experienced and inexperienced sponsors, product owners, scrum masters, project managers and people involved in business development and contract negociation.

There is so much focus these days, and at Agile2008 especially, on “scaling Agile”, and it bothers me. There is something about that term that leaves a bad taste in my mouth. Why does everything always have to get bigger? Isn’t the giant distributed team phenomena (and adding more and more people) the thing that caused the need for Agile approaches in the first place?

With Continuous Integration, the chances rise exponentially with team size that as you fix a build or test problem, the integration of somebody else’s work creates a new build or test problem. Multi Stage CI addresses this problem by extending the practice of temporary individual isolation to features, teams, staging, QA, and release. This demonstration will show how Multi-Stage Continuous Integration works in the real world by drawing on the experiences of three large distributed teams. See changes by hundreds of simulated developers make their way through the system.

Dean Leffingwell describes how agile methods are being successfully applied to enterprise-class development. • Part I describes best practices that natively scale to the enterprise level—structuring agile component teams, mastering the iteration, two levels of planning, concurrent testing and continuous integration. • Part II describes capabilities necessary to achieve enterprise-scale agility—intentional architecture, lean requirements, multi-level release planning and managing highly distributed development.

Salesforce.com’s R&D organization made a comprehensive large scale transition to agile software development in October 2006. Since that time we have delivered five on-time major releases of our Salesforce application suite and Force.com platform using the new agile approach. There are currently over 40 scrum teams contributing to each major release, and all teams work in a single release code branch. When combined with an aggressive, risk-tolerant culture, this results in many team interdependencies.

Single team implementations are where Scrum is most comfortable. Having successfully adopted Scrum for single teams within the central BBC Future Media and Technology department, we were now faced with the choice of dropping the use of Scrum on a large multi-team project or scaling Scrum up. We chose the latter, despite the fact that neither we nor anyone else seemed to know exactly what was involved. This is the story of how we dragged Scrum kicking and screaming out of its (and our) Comfort Zone.