This talk focuses around a series of diagrams that help explain how various practices work.

Many practices work to different degrees of success depending on exactly how they’re implemented. We’ll discuss why this is so, with examples of multiple ways to do pair programming, testing, and planning. Along the way, we’ll show some new work: how to get a better plan by not estimating, models to identify which practices to experiment on, and how to find what to vary.

Each concept will be explained with diagrams that get to the gist of the practice - and methods of thinking about variations.

In 2005, Microsoft’s DevDiv (with 2000 participants and 40 million lines of code) overhauled its engineering practices to improve agility, quality, and customer satisfaction. Four years into the journey, customer satisfaction has increased dramatically. Product quality improved 10x. Velocity improved 2x, with schedule time for major releases was cut by eighteen months and quarterly releases of “power tools” allowed incremental delivery to external customers. Practices that change include planning, org, quality gates, branching, testing, tooling, reporting, backlogs, transparency.

Agile has all these weird, expensive-looking practices: pair programming, test-driven development, regular planning meetings, moving the programmers and business people closer together, focusing people on a single project, multi-disciplinary teams. We can’t afford to go agile!

In this session, J. B. Rainsberger introduces agile practices by relating them to core business matters: compounding early earned value and reducing unnecessary costs. Learn why practice and learning are really profit centers. Maybe you can’t afford not to go agile!

Scheduling should be done independent of and orthogonal to workflow. In fact, you don’t have to create a schedule for a flow system. It will flow all by itself, and work will flow much faster and much more reliably than it could possibly follow a schedule. But take a closer look at that workflow: Just when you thought it was obsolete, the V model reappears. This talk will step through systems design, approval processes, and scheduling, development workflow, depolyment, from a completely different angle.

In the nature vs. nurture debate, researchers have declared nurture the winner. People who excel are the ones who work the hardest; it takes ten+ years of deliberate practice to become an expert. Deliberate practice is not about putting in hours, it’s about working to improve performance. It does not mean doing what you are good at; it means challenging yourself under the guidance of a teacher. Unfortunately, our organizations are not set up to develop experts, nor do agile practices encourage them. So how will we develop the experts we need to improve?

This talk discusses techniques that can be used to apply Agile practices to atypical technologies, and presents case studies on how to apply Agile practices to projects built with technologies including Teradata (Database), and MicroStrategy (BI).

When my Scrum-style backlog grows up, it wants to be an FDD feature list … or is it the other way round?’ Why does Feature-Driven Development (FDD) organize its feature lists into a hierarchy? Why does FDD use a specific template to name the items in a feature list? While a Scrum-style backlog for a single team may never grow to more than a couple hundred items, backlogs serving multiple teams may easily do so and become hard to work with. We compare Scrum-style backlogs and FDD-style feature lists, and consider the relative merits of different ways of working with large backlogs.

Increasing gender intelligence strengthens our ability to maximize the contributions of all members of the team while maintaining both equity and uniqueness. New research from neurobiology sheds light on the real differences in male and female brain structure, chemistry, and blood flow. This data underlies the emerging science of gender intelligence, providing a new vision of gender relationships. Gender-intelligent supervision, employee coaching/mentoring and negotiation and conflict management leads to a competitive edge in the toolkit of forward-looking companies.

Most agile methodologies tend to assume that the team is co-located in a single team room. They give little guidance as to how to address team distribution although proven practices are starting to emerge within the community. The Microsoft patterns & practices team has been experimenting with distributed teams for several years, mining proven practices from the community and experimenting them out on numerous agile projects. This talk summarizes those learnings and proven practices and gives examples of their application - both good and bad - within our teams.

In the battle of YAGNI and the performance testers, who wins out on an agile project? Join us as we walk through a historical account of what happens when you need to meet heavy performance targets on an agile project. Find out what was at stake, and the dire consequences if either side annihilated the other. We’ll focus on technical detail, planning and management techniques that led to the only outcome, collaborative success! Finally, discover the impact this battle had in the war agile wages to align the needs of end customers, the business, and IT, to see how it all worked out.