Agile & Organizational Culture
Scaling Scrum with Feature Teams
Fri, 2009-01-30 09:33 — Bas VoddeHow do you scale Scrum to hundreds of people? This presentation will explain a way of organizing your development so that it scales up well. It involves breaking the link between architecture and organization, breaking code ownership and organize the development in a more customer centric way. This has its drawbacks too! These are explained and some techniques for overcoming these drawbacks are discussed. This talk is based on the “feature teams” and “requirement areas” chapters in the recently published “Scaling Agile & Lean Development” by Bas Vodde and Craig Larman.
Agile in the Enterprise Corporation
Thu, 2009-01-29 19:18 — Laureen Knudsen
We know why engineers use agile but should Executives fund it? Through this panel discussion learn the benefits of Agile 4 those that hold the checkbooks:
*Why Executives should see Agile as a necessary change
*Benefits of Agile 2 an enterprise business, including non-engineers
*Justify funding 4 training, tools, etc
*Link Agile metrics 2 the balanced scorecard without compromising the principles of Agile
Diagrams for understanding and improving Agile practice
Thu, 2009-01-29 02:13 — Bonnie Aumann, Arlo Belshee
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.
Introducing Agile in the Very Large: Microsoft Developer Division’s Journey
Mon, 2009-01-26 19:41 — Sam GuckenheimerIn 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.
Shock Therapy: How to Bootstrap a Hyperproductive Team
Sun, 2009-01-25 21:14 — Jeff Sutherland
, Scott Downey
The design goal for Scrum teams is 5 to 10 times waterfall performance yet the majority of Scrum teams never achieve this goal. A pattern is emerging at MySpace in Beverly Hills and Jayway in Sweden, for bootstrapping high performance Scrum teams. Rigorous implementation by an experienced coach creates a total immersion experience akin to Shock Therapy. Unfortunately, management disrupts hyperproductive teams by removing key resources. Velocity data is provided on five teams at MySpace and one team at Jayway where management repeatedly “killed the golden goose.”
The Scrum Bestiary: Pigs, Foxes, Chickens and Seagulls a behavioral taxonomy
Wed, 2009-01-21 21:44 — Ade Miller
Our ability to identify patterns of behavior and the likely reasons behind them helps when addressing team dynamics issues. The popular Scrum characters chicken and the pig turn out to be just two of many behaviors that comprise the Scrum Bestiary. Other examples include the seagull - who derails the team and leaves - and the fox - who is intent on stealing vital resources. This humorous workshop presents a taxonomy of some common behaviors on teams and looks at the drivers behind them and strategies for addressing them.
Death by Scrum Meeting
Wed, 2009-01-21 06:11 — Pete Behrens
There is no better way to gauge an organization’s culture than to watch its meetings - usually dull and lifeless. Meetings are often cited as one of the most wasteful activities in business - yet Scrum demands more meetings more often. Engineers find themselves micro-managed with little time left to get “real” work done. This session provides leaders a whole new perspective and techniques for Scrum Meetings in building high-performing disciplined teams through focused, active, engaged, visual and time-boxed facilitation techniques to take teams from DOING Scrum to OWNING Scrum!
Agile: placebo or real solution?
Mon, 2009-01-19 20:51 — Linda Rising
The power of the placebo is based on our brain’s belief system. Because we believe the medication can work it does. I wonder if there is some of that placebo effect in our successes with agile? Could it be that all our successes are really a matter of proper expectation?
It often seems that the software industry is seeking one magic potion after another. We embrace the latest and greatest and hope it will cure our ills. Is agile just the latest elixir?
The impact of Agile Architect Teams in Scaling Enterprise Efforts
Thu, 2009-01-15 20:39 — Mike Dwyer
This talk presents an evolutionary roadmap for architects to support Product Owners, Scrum Teams and ScrumMasters through Agile Architecture Teams. Based on coaching and practical experience, a pattern of growth in Architectural teams has emerged as Agile scales up in an organization. This talk describes the possibilities when Agile Architects transform into a collaborative team and find better ways to extend Agile Principles, Agile Architecture foundations, and Scrum based workframes in adding value.
Mapping the Agile Enablement Battlefield
Sun, 2009-01-11 00:30 — George Schlitz
, Giora Morein
Most Agile initiatives focus on delivery while neglecting the impact that such a radical change may have on the project and organization. The Agile PM must protect the team and help influence the change effort when there is no formal change management. Leveraging a military battle metaphor a lightweight technique can be used to map influences acting on a project. Participants will learn how to identify potential risks and how and where to respond. Spending minutes a day using this technique can mean the difference between an Agile change effort and the end of one Agile project.

Add to calendar