DevWeek India 2008

If you live in Asia, note the DevWeek India conference announcement in our forums.

DevWeek India 2008 gives you a rare chance to meet your peers in a productive and social environment and get passionate about Software programming. By the end of DevWeek India 2008, you will learn how to increase your productivity dramatically and save cost, and how to enhance the quality of your software applications.

DevWeek India 2008 is scheduled to get underway on the 25th of August till the 28th of August
2008 at NIMHANS Auditorium, Bangalore, India.

Feel free to post similar announcements on our forums.

Agile 2008 Guide – Thursday Evening

 Agile 2008 is the premier conference of the Agile world. There are going to be almost 2000 participants and about 400 different sessions to attend. It means plenty of interesting conversations and a lot of activities to choose from. However, it also means that you have to make a choice between many different options. During the main part of the conference you have to choose between 40 to 50 different sessions.

Here is the first part of the guide to the conference program. This part covers Thursday August 7, 16:00 – 17:00 time slot. In the table below you can find links to the full description, author bio and the answer to the all important question "Why would you want to go there?" All the sessions with white background take 90 minutes, all the sessions with orange background take 180 minutes (and therefore continue from the previous time slot), all the sessions with the light blue or light green background take less, than 90 minutes.

If you feel that some summaries are inaccurate, please, comment – I will correct the mistakes.

You can find more information about the conference at http://AgileSoftwareDevelopment.com/Agile2008


Topic

Speakers

Why you would want to go there

TDD Clinic: C and Legacy Code

Bas Vodde
Michael Feathers

Come to this clinic if you like the ideas of test driven development, want to apply it for your C projects, butn’t quite see how to do it well.

Automated Testing Clinic: FitNesse.NET

Mike Stockdale 

Come to this clinic if you are an experienced C# developer who wants to get acquinted with the acceptance testing on .NET.

Advanced TDD Randori and Fishbowl

Dave Nicolette
Ryan Hoegg

Come to this workshop if you can code in Java, know what TDD is and have plenty of questions about how TDD could be applied for complex areas.

Continuous Integration Clinic

Owen Rogers 

Come to this clinic if you are one of the people responsible for builds on your team and who is not satisfied with publishing just passed/failed status. You will learn how to make much more information very well visible.

Refactoring for Testable C++

Keith Ray
Alex Aizikivski

Come to this tutorial if you are a developer who happens to work with a plenty of non-testable and hardly refactorable legacy C++ code.

Patterns Poster Children

Brian Foote 

Come to this tutorial if you are a developer, you like the idea of design patters, but find it not easy to apply them, because your particular situation is often not exactly like what the pattern was invented for.

Distributed Agile Game

Desi McAdam

Come to this workshop if you are going to start or already started the distributed Agile development and would like to *feel* what it is really like, what problems there are and how to overcome them. This session is supposed to be a large scale simulation with a lot of fun.

Agile Leadership: What Is It and How Do You Do It?

Pollyanna Pixton
Johanna Rothman

Come to this tutorial if you are going to become an Agile team leader or if you are an official leader already and find it challenging to lead in the agile environment.

The User Feedback Two-Step

Hugh Beyer 

Come to this tutorial if your team finds it challenging to unite the highy dynamic iterative development with the amount of user experience design UX specialists want. You will learn a particular technique called User Feedback Two-Step.

Lightning talks

Steve Freeman

A very special session, where you can present a micro talk or ask for a micro talk. See the session description for the details.

Open jam: create your own session at the conference

A chance to discuss what interests you most.

Workshop on build/test grids and selective testing tools

David Vydra

Come to this workshop if you are a software engineer and you are looking for the fasrer build/test tools. A number of options will be presented.

Effective test-driven database development

Gojko Adzic
Marisa Seal

Come to this demo if you are a developer who utilizes TDD and especially FitNesse, but doesn’t apply TDD for the database development. A DbFit tool will be presented.

Live aid: participate in a real agile project at the conference

Come there if you want to feel the real agile team working. Note that you might participate fully or drop for 10 minutes if you have a free time slot.

Measuring the Effect of TDD

Keith Braithwaite 

Come to this workshop if you like TDD, but lack arguments for persuading the other team members.

Technical lessons learned turning the agile dials to eleven!

Craig Smith
Paul King

Come to this experience report if you want to see what happens over the course of several years with a company exploring the Agile practices much.

Automated Functional Testing on the TransCanada Alberta Gas Accounting Program of Projects

Stephen Marsh
Stelios Pantazopoulos

An experience report focusing on FIT-based testing on the enterprise level project.

Leading Manual Test Efforts with Agile Methods

Adam Geras

Come to this experience report if your system includes many components that have to be tested manually. You will see how the manual test management could be improved with the Scrum-like methods.

Estimating Considered Wasteful: Introducing Micro-Releases

Joshua Kerievsky

Come to this talk if your team members find estimating and calculating velocity too boring and taking a lot of time. Or just if you wonder how work could look like if you had a release every couple of days.

The Agile Haiku Workshop

Elizabeth Keogh

A workshop from the fun department. Come if you want to have fun. You will learn how to write haiku and of course will dive into what haiku writing can teach to.

Successful Open Source, with little or no Agile

Dennis Byrne
Naresh Jain

Come to this panel if you wonder how comes most successful open source teams use little to no Agile.

La technique d’interview des "Neuf Cases" pour mieux comprendre votre client

Pascal Van Cauwenberghe
Portia Tung

Come to this tutorial if you speak French and understand the description.

Enterprise Agile – panel discussion

Nicola Dourambeis 

A typical panel on the enterprise adoption with a particularly impressive set of experts from Google, Yahoo, etc.

Touchy-feely Impediments to Agile Adoption

Amr Elssamadisy

Come to this talk if you are an organization leader or an Agile coach who wants to have a deeper understanding of why exactly Agile adoption fails or succeeds.

Whose Project is it Anyway?

Bonnie Aumann

Come to this workshop if you work on the team where it is not clear who is *actually* driving the project. You will collectively explore the patterns, problems and solutions.

Creating Shared Understanding with Cards

Angela Martin
Artem Marchenko

Come to this tutorial if often you find it difficult to exchange ideas with the stakeholders, colleague or whoever else, because it is just difficult to create a really shared understanding. Session is supposed to be especially useful for those new to Agile. Warning: this review is written by one of the copresenters and might be biased.

Energize your Strategy through Agility and Innovation

Joe Krebs 

Come to this tutorial if you are in position to sponsor the organizational change and are interested in supporting the entrepreneurship culture among your teams.

Exploring user stories through mind mapping

Kenji Hiranabe
Takeshi Kakeda

Come to this workshop if you are the one helping to gather requirements from the users and you find it difficult to explore the user’s mind. A particular technique for exploring the “user wish” before writing any user stories will be introduced. Mind maps are just a technical element of the technique.

Colossal, Scattered, and Chaotic (Planning with a Large Distributed Team)

Wes Williams
Mike Stout

Come to this experience report if you have to plan iterations and releases for a huge team distributed on several continents and even more cities. Especially if you are a product owner of such a team.

The Good and Bad of Offshore Agile Development

Mike Cottmeyer 

An experience report on a successful Agile development in the offshore environment.

Overcoming the Challenges of a Distributed Organization

Elaine Therrien
Michele Sliger

An experience report on a successful Scrum adoption in the distributed environment.

What Are They Doing? What A CIO Wants To Know From An Agile Development Team

Niel Nickolaisen 

Come to this talk if you work in an IT department of the enterprise and have issues understanding the reasons behind the CIO requests.

For Agile Leaders Only — Exploring the "Hard Bits"

Bob Galen

Come to this workshop if you are an Agile coach or a leader who has some really tough challenges with facilitating your team. A Force Field Analysis technique will be introduced as a tool for helping the teams drive toward a challenge facing strategy.

Product Design 101 – Why design matters

Thad Scheer

A vendor talk on.. why product design matters and without a sales pitch. I guess it is labeled as vendor talk, only because they got a right to speak due to the conference sponsorship.

Better, stronger, faster continuous integration – Jump-starting the agile heartbeat

Usman Muzaffar

Come to this vendor talk if you are thinking about building a continuous integration system on top of the Electric Cloud solutions.

Agility by Industrial Logic

Joshua Kerievsky

Come to this vendor talk if you are thinking about hiring a consulting company that specializes on Agile/XP.

Vacation Reading

Twas the night before my vacation
and all through the house
not a creature was stirring,
not even a mouse….

Oops, wrong season. But given that the scrumdevelopment list is preoccupied with profound
issues like ‘Why are we still allowing the term ‘Agile Project Manager
(75 Postings) and ‘Appropriate Postings‘ (62 Postings and counting), it
is clear that the time has come to stop and recharge our collective batteries. For
me that means reading, doing Sodokus, and spending time on the beach with
my family. So here is look inside my backpack, as I head off to Rügen…


The Art of Agile Development, by James Shore and Thomas Warden.
A couple weeks ago, I posted a reading list for the CIO about Scrum and Agile. I suggested books on Lean
and Scrum and asked for recommendations on XP. This came back. I’m
really excited about this book. A-A-D starts out by describing the
practices of XP, the nuts and bolts practices that a software developer
has to understand to develop software effectively. It introduces the
concept of ‘Études:’ like musicians practicing scales on the way to
mastery, agile teams practice their handiwork on the way to mastering
their trade. And it presents Agile in a larger context. Agility is not
about blindly following rules, but applying deeper principles to take
the individual, the team and the company to higher levels (but like in
music, you can’t reach higher levels until you have mastered the
basics). Quite refreshing after the polemics on the Scrum list.

Scrum. Produkte zuverlässig und schnell entwickeln (“Scrum: Rapid and Reliable Product Development”) by Boris Gloger. Boris has been an influential figure in the Scrum community for may years, having developed the Heartbeat Retrospective and the Ball-Point game for teaching the principles of self organization. I was drawn immediately to Chapter 9, “Introducing Scrum in Large Projects and Organizations”. This represents about a 1/4 of the book and is filled with experiences of actually deploying Scrum in large contexts. What can work, are the pitfalls? If you can read German, and want to know about Scrum in the Enterprise, this book is for you. (Boris: what are your plans for an English translation?)

One more book worth mentioning: The Secret. I didn’t bring it
with me, even though I haven’t finished it yet. I have difficulties
with this book. Not that I have a strong opinion pro or contra New Age
philosophy. But the writing is so repetitive that  I can barely read
it (and some of things they suggest are really off the wall). Having said that, it has made a difference in my life. This book might have been called ‘The Power of Positive Thinking’ (except that
title is already taken). You define your possibilities by your
expectations. I am much happier now than I was three months ago, mostly
by just deciding to be happy and seeing myself as a happy person.

I was very surprised to find a Scrum analogy in this book. You are
driving a car at night. You have two headlights, which illuminate the
next 60m (200ft) down the road. That is enough to get you from Los Angeles to
Washington, or from Madrid to Vienna. Yes it’s easier with a map. But you
don’t need a detailed itinerary, otherwise known as a big design up
front.

Book Review: User Stories Applied

Userstoriesapplied
The concept of writing user stories, as a way of documenting requirements, was introduced and popularized with Extreme Programming, and then picked up by Scrum and several other agile methods. Nowadays, for many agile developers, a project without user stories would be like a world without pizza. Impossible to imagine.

User Stories Applied
The book User Stories Applied, published in 2004 by Mike Cohn, is a landmark publication that has brought together everything the agile movement has learned about this important subject. Mike’s book deals with all the activities that people have to perform when writing user stories, like techniques for requirements gathering, defining roles, working with user proxies, and preparing for acceptance testing. Mike also clearly explains how user stories can play a pivotal role in the wider agile project management processes of estimating, planning and monitoring.

Healthy Opinions Applied
User Stories Applied also contains information on difficult and controversial issues, like how user stories relate to user interfaces, nonfunctional requirements, use cases, user scenarios, IEEE 830-style requirements and the horror of the Happy Meal Pizza. OK, I lied about that last one. But it’s nice to see that Mike doesn’t shy away from some sensitive subjects, offering healthy and strong opinions for his readers.

It seems to me that reading User Stories Applied is simply the best and easiest way to familiarize yourself with user stories. Just about everything I found on the Internet about this topic is neatly covered in Mike’s book. It is well written and complete. And best of all, it’s easy to finish in just a couple of evenings. Either with or without a pizza.

Agile 2008 Guide – Thursday Afternoon

Agile 2008 is the premier conference of the Agile world. There are going to be almost 2000 participants and about 400 different sessions to attend. It means plenty of interesting conversations and a lot of activities to choose from. However, it also means that you have to make a choice between many different options. During the main part of the conference you have to choose between 40 to 50 different sessions.

This part of the guide covers Thursday August 7, 14:00 – 15:30 time slot. In the table below you can find links to the full description, author bio and the answer to the all important question "Why would you want to go there?" All the sessions with white background take 90 minutes, all the sessions with orange background take 180 minutes (and therefore continue on the next time stot), all the sessions with the light blue or light green background take less, than 90 minutes.

If you feel that some summaries are inaccurate, please, comment – I will correct the mistakes.

You can find more information about the conference at http://AgileSoftwareDevelopment.com/Agile2008


Topic

Speakers

Why you would want to go there

"We suck less!" Isn’t mediocrity great?

David Douglas
Robin Dymond

Come to this talk if you enjoy discussing the philosophical matters such as reasons for adopting just a bit of Agile in many companies.

The Economics of Agile: The competitive advantage of developing commercial software with Agile methods

Sue McKinney
Ted Rivera

Come to this talk if despite the fact that you came to the conference on Agile you are still not sure that it is good foe the commercial software development.

Agile and Beyond – The power of aspirational teams!

Tim Mackinnon 

Unfortunately I failed to understand the intended audience of this talk. Looks like yet another motivational talk touching several particular collaboration related practices.

What Haven’t You Noticed Lately: Achieving awareness in a complex world

Mark Federman

Come to this talk if you constantly feel like you are missing something important on your day job.

Open jam: create your own session at the conference

A chance to discuss what interests you most.

JDemo – lightweight exploratory developer testing

Ilja Preuß

Come to this talk if you are Java developer who practices TDD already, but feel that setting up the application for exploratory testing takes too long time of yours.

FitNesse Demo

Naresh Jain

Come to this tutorial if you are going to use FitNesse soon or if you started using FitNess and it doesn’t work well for you.

TDD Clinic: C and Legacy Code

Bas Vodde
Michael Feathers

Come to this clinic if you like the ideas of test driven development, want to apply it for your C projects, butn’t quite see how to do it well.

Automated Testing Clinic: FitNesse.NET

Mike Stockdale 

Come to this clinic if you are an experienced C# developer who wants to get acquinted with the acceptance testing on .NET.

Advanced TDD Randori and Fishbowl

Dave Nicolette
Ryan Hoegg

Come to this workshop if you can code in Java, know what TDD is and have plenty of questions about how TDD could be applied for complex areas.

Continuous Integration Clinic

Owen Rogers 

Come to this clinic if you are one of the people responsible for builds on your team and who is not satisfied with publishing just passed/failed status. You will learn how to make much more information very well visible.

Live aid: participate in a real agile project at the conference

Come there if you want to feel the real agile team working. Note that you might participate fully or drop for 10 minutes if you have a free time slot.

Refactoring for Testable C++

Keith Ray
Alex Aizikivski

Come to this tutorial if you are a developer who happens to work with a plenty of non-testable and hardly refactorable legacy C++ code.

Patterns Poster Children

Brian Foote 

Come to this tutorial if you are a developer, you like the idea of design patters, but find it not easy to apply them, because your particular situation is often not exactly like what the pattern was invented for.

What Is Your Unit Testing Philosophy?

Alistair McKinnell
Jason Cheong-Kee-You

Come to this tutorial if your team is applying unit tests, but it always happens to be difficult to understand the other guy’s tests.

Use-Case Recording: Testing a rich client UI by recording in a domain-specific language

Geoff Bache 

Come to this talk if you are applying automated testing, but you are testing GUI manually, because automated GUI-tests happen to be non-maintainable. This talk is more about ideas, but real example will also be demonstrated.

Maintain High Quality Web Applications with a Green Web Acceptance Build that Runs Under 10 minutes

Philippe Hanrigou

Come to this talk if you are developing Web 2.0 tests, perform a lot of manual testing and despite the big number of testing, the tests are too brittle and unreliable.

Cross Cultural Casino

Sarah Edrie
Susan Borges

A workshop on a multicultural collaboration, includes a game. Unfortunately description is quite brief.

Artful Making for Agile Teams

Lee Devin
Stacia Broderick

Come to this workshop if you are leading or coaching an Agile team and would like to know how to help people realize the creativeness in them.

Mature Agile with a twist of CMMI

Carsten Jakobsen
Kent Aaron Johnson

Come to this experience report if you are tempted to merge Agile with CMMI. You’ll see how people managed to do it and liked the results.

Agile development in a medical device company

Riaan Rottier
Victor Rodrigues

Come to this experience report if you are thinking about developing for the medical industry. People will show how they successfully use Scrum while following the industrial standards.

Swarming – The Birds and the Bees and Agile

Tom Perry
Dhaval Panchal

Come to this talk if you are a coach and would like to improve your understanding of the team dynamics basis.

How much compromise is too much – when is Agile no longer agile?

Bob Screptock
Julie Brooks

Come to this workshop if in your organization the “real world” tries to twist Agile much and you are not sure if it can still be called agile with all the adaptation performed.

Contractualisation des projets Agiles

Greg Hutchings 

Come to this workshop if you speak French and understand the description.

Creating Agile Streams for business and technical value

David Spann
Zachary Hunter

Come to this experience report if you are in the product owner-like role and stakeholders constantly try shaking your priorities. An approach of splitting a single backlog will be presented.

Taking an Enterprise Agile

Roger Valade 

A typical experience report on successful Agile adoption. Includes using agile for legacy ERP system maintenance.

An Ericsson example of enterprise class Agility

Jasper Goos
Alfo Melisse

Come to this experience report if you winder how really big companies adopt Agile and what they find problematic.

Agile Supports Improved Culture and Quality for Healthwise

Ken Long
David Starr

Experience report on implementing Scrum in healthcare so well that the company became recognized by the Wall Street Journal.

Executing Agile in a Structured Organization: Government

Janette Scott, Robyn Johnson,
and Michael McCullough

Come to this experience report if you are funded by government and would like to consider adopting Agile.

From Denial to Acceptance: The 5 Stages of Grieving in a 6 Month Conversion from Waterfall to Agile to Save a Dying Project

Mary Beth Snapp
Diane Dagefoerde

Experience report on yet another successful waterfall-to-Agile transformation.

Building Self-Organization Skills through the Touchstones Discussion Project

Pam Rostal 

Come to this workshop if you are a coach or an organization leader who wants to learn yet another way of helping the team to become self-organizing.

From Concept to Product Backlog – What Happens Before Iteration 0?

Gerard Meszaros
Janice Aston

Come to this tutorial if you are on the customer side of the project and are often confused with the Agile team’s desire to expect plenty of well-thought stories when you want to work more on figuring out which product you actually need.

The Customer Role in Agile Projects

Mike Stout
Lisa Shoop

Come to this workshop if you are going to be the first time Agile customer and want to understand what is expected from you.

The Aikido of Agile Project Metrics

Alan Goerner 

Come to this tutorial if you want to measure your team development effort, but cannot make metrics work because of political or technical issues.

Distributed Agile Game

Desi McAdam

Come to this workshop if you are going to start or already started the distributed Agile development and would like to *feel* what it is really like, what problems there are and how to overcome them. This session is supposed to be a large scale simulation with a lot of fun.

Managing Database Development on Distributed Teams

Pramod Sadalage

Come to this demo if you work on the distributed Agile team, manage to work feature by feature, but find it challenging to put the database design under the collective ownership.

When Whole-Team Attacks: How can we ensure true whole-teams survive and thrive?

Angela Martin
Robert Biddle

Come to this talk if you find it challenging to move from a group of individuals to a true team acting as a whole.

The social nature of agile teams

Elizabeth Whitworth 

A “researchy” experience report that dives into personal feelings of those on the Agile projects.

Bootstrapping Scrum and XP under crisis – a story from the trenches

Henrik Kniberg
Reza Farhang

An experience report on saving a death march project by the author of Scrum and XP from the trenches.

Seeking To Perceive More Than To Be Perceived

Emmanuel Gaillot
Bernard Notarianni

Come to this tutorial if you a coach or facilitator who wants to improve his skills of resolving conflicts coming from pushing the own opinions.

Agile Leadership: What Is It and How Do You Do It?

Pollyanna Pixton
Johanna Rothman

Come to this tutorial if you are going to become an Agile team leader or if you are an official leader already and find it challenging to lead in the agile environment.

The User Feedback Two-Step

Hugh Beyer 

Come to this tutorial if your team finds it challenging to unite the highy dynamic iterative development with the amount of user experience design UX specialists want. You will learn a particular technique called User Feedback Two-Step.

Agile Tools For Agile Teams

Ian Culling

Vendor talk presenting a Version One tool basing on a real life story.

Agilizing Product Management

Rich Mironov

Vendor talk that looks like not a vendor talk, but rather a short motivational talk for product managers soon to start on the Agile team.

Agile 2008 Guide – Thursday Morning

Agile 2008 is the premier conference of the Agile world. There are going to be almost 2000 participants and about 400 different sessions to attend. It means plenty of interesting conversations and a lot of activities to choose from. However, it also means that you have to make a choice between many different options. During the main part of the conference you have to choose between 40 to 50 different sessions.

This part of the guide covers Thursday August 7, 10:30 – 12:00 time slot. In the table below you can find links to the full description, author bio and the answer to the all important question "Why would you want to go there?" All the sessions with white background take 90 minutes, all the sessions with orange background take 180 minutes (and therefore continue from the previous time slot), all the sessions with the light blue or light green background take less, than 90 minutes.

If you feel that some summaries are inaccurate, please, comment – I will correct the mistakes.

You can find more information about the conference at http://AgileSoftwareDevelopment.com/Agile2008


Topic

Speakers

Why you would want to go there

Coding Contest

Christoph Steindl
Christian Federspiel

Come to this developer contest if you are a developer wishing to have some coding fun while experiementing with the new or competitive approaches.

TDD Clinic: .Net and C#

David Starr 

Come to this clinic if you are a developer who knows something about unit testing and would like to leard more about test-driven development in C#.

Automated Testing Clinic: Testing with a Purpose

Kay Johansen
Christian Hargraves

Come to this clinic if you know what test-driven development is about, but often you find yourself buried with the large amount of poorly understandable tests.

Continuous Integration Clinic

Maciej Zawadzki 

Come to this clinic if you are a spftware developer or build manager everything you’ve heard about the continuous integration is just the name of the practice.

Backing the Truth into a Corner

Keith Braithwaite

Unfortunately I failed to understand what this workshop is exactly about. Something related to understanding why the executable requirements work.

Using TDD with Concurrent Applications

Brett Schuchert
David Nunn

Come to this workshop if you are a Java developer who knows how to apply TDD in general, but finds it difficult to test the concurrent code.

Game Design Workshop

Hubert Smits 

Come to this workshop if you are a coach who frequently wants to frame the exercises into a game. You will learn how to create them.

Meta-Agile: Using Agile Methods to Deliver Agile Training

Mishkin Berteig

Come to this session if you are a trainer or a teacher (not necessarily teaching Agile methods). You will learn how to apply the Agile methods in training from the person who applies them himself.

KFC Development – Finger Lickin’ Good

Karl Scotland
Aaron Sanders

Come to this workshop if you’ve heard a little about Lean and are willing to explore it more. You will hear about the Yahoo! expeience.

Operating on the Creative Edge: Applying Improvisation Techniques in Agile

Jim York
Tobias Mayer

Come to this workshop if you are a coach who want to learn more about how to help the teams learn how to be creative and and improvise for the better.

Beginner’s Mind–The Zen of Agile

David Hussman
Jean Tabaka

Come to this workshop if your teams frequently lean into overplanning, overthingking and over engineering.

Vision Pluridisciplinaire: Générer une charte de projet en un jour, en enfermant des gens de point de vue divers dans une salle

Alain Désilets

Come to this tutorial if you speak French and understand the description.

Creating Cultures Where Agile Emerges

Pollyanna Pixton

Come to this tutorial if you plan to frequently work with different teams as a coach.

Mr Agile Goes To Washington: The Impact of Politics on Agile Projects

Angela Martin
Rachel Davies

Come to this workshop if you happen to find winds of politics preventing good ideas from flourishing in your organization. You will take part in developing and sharing practices that will help to  handle the political situations that face agile projects today

User Story Mapping: making sense out of your user story backlog

Jeff Patton 

Come to this tutorial if you sit on the customer side of the project, work with user stories, but often find the vision blurred ad becoming difficult to communicate as new and stories are added.

How to support a collaborative atmosphere in distributed projects?

Lars Arne Skår
Jan-Erik Sandberg

Come to this workshop if you are having issues with the level of collaboration with your distributed projects and would like to collectively figure out what could be done about the difficulties.

The Secrets of High-Performance Agile Implementations

Gil Broza

Come to this tutorial if you are an organizational leader or manager starting the Agile adoption.

Sketchboards and Prototypes: Agile methods for better and faster UX solutions

Dan Harrelson
Leah Buley

Come to this tutorial if you come from UI or UE and have troubles with iterating your designs as quickly as developers are able to complete their iterations.

From High-performing to Hyper-performing Agile teams

Facilitator: Gabrielle Benefield
Panel: Jeff Sutherland, Rob Mee, Jason Titus

Come to this panel if you are looking for examples of very successful Scrum implementations in the large companies. Panelists include a Yahoo! deirector and a co-author of Scrum.

Measuring Agile in the Enterprise: 5 Success Factors for Large-Scale Agile Adoption

Michael Mah

Yet another report about a successful distributed Scrum implementation. This one is claimed to be measured particularly well.

Good Virus / Bad Virus: How Organization Culture Impacts Agile Adoptions (and Vice Versa)

Michael Spayd

Come to this talk if you want to understand whether Agile fits your organization well.

Open jam: create your own session at the conference

A chance to discuss what interests you most.

JTestMe – improving test feedback and reducing build times with dynamically defined optimised smoke tests

Joshua Graham

Come to this demo if you are a Java developer looking for ways to decrease the amount of tests run on the check-ins.

Evolution of the Tools and Practices to Achieve Organizational Change

Fabrizio Cannizzo
Paul Moser

Come to this experience report if you a Java developer who works in a distributed team and is not happy with the current tools.

Adopting agile testing practices when legacy tools and practices rule !

Xavier Warzee 

Come to this talk if you are sold on Agile and would like to promote it from the grass root level even if the organization doesn’t want the change.

Domain Specific Testing Languages

Michael Phoenix
Rand Huso

Come to this tutorial if you are a developer or tester, don’t know much about domain specific languages and would like your users to participate in the test creation.

A Hundred Days of Continuous Integration

Ade Miller

Come to this experience report if you are looking for ways to convince your distributed team give continuous integration a try.

Team pace – Keeping build times down

Graham Brooks

Sheraton Hall C

Effective and pragmatic Test Driven Development

Andrew Rendell

Sheraton Hall C

Live aid: Participate in a real agile project at the conference

Come there if you want to feel the real agile team working. Note that you might participate fully or drop for 10 minutes if you have a free time slot.

TDD Principles for Database Development

Dennis Lloyds Jr
Sebastian Meine

Come to this talk if you apply TDD for code, but don’t yet apply it for databases. You will learn a number of techniques.

Robust Performance of Complex Systems

Michael Nygard
Mary Poppendieck

Come to this workshop if you want to share and build upon your experience in creating the robust complex systems.

Why So Little Questioning? Skeptical Humanist Seeks Same for Discrete Afternoon Encounters

Michael Bolton 

Come to this session of another type if you feel like analyzing the conference itself and observing where the trends are heading (e.g. whether tools or people are emphasized). Note, that some preparation is expected.

A better culture change approach for busy practitioners

Mike Russell
Amy Levine

Come to this tutorial if you feel like your organizational change approaches lack consistency and you would like to improve them. A particular framework will be presented.

Agile Planning in Action

James Shore 

Come to this tutorial if you know what agile planning is about, but don’t practice it much yet. You will go through a simulation of building a real product.

Guerilla Agile: Stop Playing Schedule Games

Johanna Rothman

Come to this talk if you feel like you management is playing too much with the arbitrary schedules and you would like to know how to change that.

Oles 8 steps for Agile Mentors

Ole Jepsen

Come to this tutorial if you are an Agile coach or planning to become a coach and would like to learn the best tricks for traditional-to-Agile transitions. Ole will share his method.

The Road from Project Manager to Agile Coach

Lyssa Adkins

Come to this workshop if you are or were a project manager going to become an Agile coach. Together with a group and the presenter you will collectively identify and possibly learn how change yourself into a coach.

Agile and the Enterprise

Daniel Craig

Vendor talk of Command Information. Yet another consultants.

Scaling Scrum to the Enterprise with Lean Software Development

Alan Shalloway

Vendor talk of Net Objectives. They specialize on Lean Software Development and merging it with Agile.

DSDM Atern: An introduction to Europes leading Agile Framework for Agile Programmes and Projects

Barry Fazackerley

Vendor tutorial on DSDM method. Performed by the DSDM Consortium person.

Case Study – Benchmarking Agile Productivity

Zach Nies

Come to this vendor talk if you believe that tools can help you measure your Agile teams productivity. The study is likely to be biased towards Rally.

Source Code Analysis in an Agile World

Gywn Fisher

Vendor talk on source code analysis. Performed by a Klocwork person.

Refactoring in action

Quite recently I attended my company’s internal presentation regarding agile software development (ASD). During Q&A (questions and answers) part someone who was not convinced to use ASD complained that refactoring means rewriting the code from scratch. It’s bullshit, of course, but as you can see people who don’t know ASD can proliferate misconceptions about many ASD ideas.

In this post I would like to show you an example of refactoring in an unconventional way. I hope you will like it.

My very first apartment
Two years ago I bought my very fist apartment in the center of Gdynia. This picture of the kitchen was taken a day after housewarming party (before the rennovation):

Refactoring phase
We (me and my wife) didn’t want to change too many things in this flat. We wanted to have a new kitchen and bathroom but the rest should be more or less untouched. In other words we wanted to do only slight refactoring of our apartment.

We were Product Owners and we changed our mind after some pieces of advice made by our parents and friends and we decided to change electrical, heating and water infrastructures as well. The refactoring was getting more serious.

When the heating and electrical teams finished they work (they completely destroyed our bathroom – this was part of the plan, unfortunately) we employed another team in charge of making our bathroom and walls flat 😉 shiny, colorful and beautiful. At that stage we really wanted to keep the parquet on the floor but as our refactoring proceeded we discovered many unpleasant surprises 😉 We had to remove the parquet and fill some holes in our floor with new layer of concrete! Oooops!

Our “product” looked like this (the middle of the “release”):

Refactoring often hurts
I as a Product Owner was in despair – I didn’t want to watch this mess. Our apartment looked like big shit and it was getting worse and worse. Our refactoring phase was at the peek!

I was a good project manager of this project and coordinated work of 5 different teams – when one team finished the job the next one entered the flat few days later. Of course we had many many problems with the guys and it was often big hurt but my stubbornness and will made it to the happy end.

The refactoring was painful (especially that it was our beloved and very first apartment we wanted to inhabit very quickly) but the effect was stunning:

Retrospection
Our release took 2 months and the phases we went through were:

  1. completely destroyed bathroom
  2. destroyed walls in every single room
  3. destroyed floors

and maybe something more traumatic but I don’t want to remember this.

We didn’t destroy the structure of the walls and any other fixed elements of the building but within the flat we refactored almost everything. We made this flat amazingly beautiful, safe and modern (all “middleware” infrastructures are new). And it was worth it – even taking into account “renovation trauma” we still have 🙂

Software analogy
Please note that the analogy to the software refactoring is not very strong here as you will be probably tempted to perform rather shorter refactoring cycles. However, such big software refactoring happens (I used to do some) and can last even for half of the 30-day iteration but you have to perform them very carefully (hopefully you have good test coverage and you can sleep well after such operation). Going with this analogy further – it’s much easier to make another short software refactoring task after few iterations and add some more features than destroying another room in the apartment while already living there – these worlds are not 100% compatible here 🙂

Refactor or not?
I think this example is quite extreme but hopefully shows how code refactoring could look like. In the middle of the refactoring phase, which can be project-wide and affect 80% of your classes and packages, you can have complete mess (or brothel if it translates to English). But at the end refactoring pays off and you can easily get new infrastructure and internal design. Your code will be more extensible and ready to implement new features. And it’s not rewriting your code from scratch (look, we didn’t destroy the whole floor of flats – we reordered the internals).

If you need to refactor your code significantly and you know the value will be greater than the cost you should definitely go for it. It could be painful, your manager and colleagues could hate you during this period of time but when they see the effect they will love you (of course if you succeed :). And you could go on holiday – someone else will add new feature basing on new refactored code.

Start with Trust, Start with a Retrospective

Taking over responsibility for a troubled project is always a delicate situation. Something was not working as it should. There is a group of people in place, who may or may not 1) be working as a team, 2) have the necessary skills and a positive attitude, or 3) be willing to accept change. So how do you, the new project manager, get the team back on track quickly?

We all have our stories about arrogant consultants and managers who a) don’t know the business, b) reorganize everything regardless of the consequences, c) quickly move on or get promoted, and d) leave the team to clean up the mess. A certain skepticism is not only to be expected, it is healthy. So the top priority is to win the support and respect of the team. A close second is getting the team working on improving the situation.

Scrum teaches a wonderful tool: the Retrospective, which is normally performed at the end of each Sprint. At the start of a project rescue, I like to use a Retrospective to get to know the team, identify short term action items, earn the trust of the team, and plant the seeds for transitioning to Scrum (while focusing on what the project needs, not on methodology).

Scrum implements Deming’s Plan-Do-Check-Act Cycle and repeats the process at least once per month. I prefer to call it “Plan, Do, Review and Improve” because that’s a better description of what actually happens. So for a challenged project, starting with the Improve step is actually quite a logical thing to do.

The Retrospective normally addresses 5 questions:

  • What happened?
  • What did we do well?
  • What could be improved?
  • Who has jurisdiction?
  • What is top priority?

In general, everybody who is directly involved in the project should be present, but no more than 15 people or so.

The result is two prioritized lists of action items to improve productivity in the project. The first list contains actions that the team can perform on its own authority. Items from second list require agreement from somebody ‘outside’, e.g. Management, the Customer, another department, whatever.

Why do a Retrospective?

By asking what happened, you build a common understanding of the project — a common culture actually. Just getting people together at one table, giving them a chance to talk, and have them listen to each other goes a long way towards reducing emotional conflicts. You also send a message that what everyone has to say is important.

By asking what the team is doing well, you eliminate the risk of “throwing the baby out with the bath”. You give everyone a pat on the back. You send the message that you understand that people are working for the good of the project and make clear that that is what people should be doing! They will respond and work better just because of the feedback and respect they are getting from you.

Furthermore, you have an opportunity to ask questions. “I would have expected pre-release testing would be high on the list of thing we do well. What testing do we do before delivering the software?” Either people will have a good answer or they are primed to make a good suggestion. By asking the right questions, you can drive the improvement process in the direction you want.

By asking the team how to improve, you get a list of short and medium term action items which will make visible improvements in the state of the project. Furthermore, the team owns the list, even the items you slipped in through clever questioning. So they will stand behind that list and help implement it.

By determining who has jurisdiction, you determine which items the team can action itself and for which items help or negotiations are needed. For the ideas under you team’s control, they can start right away with the item at the first item on the list. For the rest, you start with the team’s top priority request and work to get it approved.

Introducing code reviews might be an item on the first list: two developers get together and discuss their code. No one really has to even know, much less give their blessing. So just do it! Items on the second list may be difficult to get approved, and the chance of approval might play a role in assigning the priority. For example, you team might request a new build server. If you don’t have the budget available, you would take responsibility for making it happen, and the team will love you when you are successful.

Some managers may be afraid that the team will come up with frivolous requests (“The whole team needs a fact-finding trip to Malta!?!”), but by prioritizing, you focus on what’s really important. (“Yes it really does, and here is why…”). This is also why it is useful to have management present, so they appreciate the validity of the process.

The team may have enough ideas to keep them busy for the next two or three months, so you will probably need to focus on just a few items so that the team can continue to do productive work. Less important items can be postponed to the next retrospective.

Last but not least — do it!

The consequence of every retrospective should be at least one concrete result — a list of things to do is nice, but you need actual results. When the team gets to do the things they’ve asked to do, that’s positive reinforcement. When you make their top priority joint-responsibility request happen, you earn their trust and respect, which makes your life and theirs much easier.

But – If you don’t allow them to do the things they identified, disillusionment can rapidly set in. So by the time you get to the next retrospective, you should have implemented (or least in the process of implementing) one or two of the top points from each list. Better to get one item done than to have 5 items in progress.

Results

My experience is that the team always identifies genuine potential for improvement (no one has suggested a trip to Malta yet). The top issues that arise out of that first retrospective are mostly organizational in nature and are easily addressed by introducing Scrum. This is the time to start talking to the team about Scrum and how it well help them solve their problems.

In the last year, I’ve been in involved in three rescues. Two were successful, one was not. In the latter case, the team identified much potential for improvement (some of it quite trivial to implement) but was not allowed to implement any of the changes they suggested, so the effort was stymied. Three months later, the project “hit the rocks,” exactly as predicted during the retrospective.

One rescue, although successful, was started without a retrospective. The team reacted negatively and, despite objectively successful results, it was not until most of the old team members had moved on and been replaced with fresh blood that the mood turned positive.

The most successful rescue was started with a Retrospective. The team had the authority to implement most of the desired changes, so motivation, productivity and quality improved quickly and dramatically. Most of the issues raised by the team were addressed by Scrum or the tools we wanted to use, so acceptance of both was high from the beginning and there was no significant resistance to the changes in methodology.

How do you make the changes stick?

You won’t change the world in one meeting. Emotional issues don’t disappear in an afternoon. I remember one retrospective (between 2 “cooperating” companies) where the only agreement from the first retrospective was to have another one a month later. The trick is to make small improvements regularly. Emotional issues are often not “resolved” but simply dissolve over time. So repetition is important, especially when emotions are involved.

In an agile context, you would do a retrospective after every Sprint, i.e. once every two or three weeks. Even if you are not using Scrum or XP, retrospectives should take place a regular intervals no more than a few weeks apart. In any case, the top improvement on each list should be implemented (or at least under way) by the next retrospective.

Further Reading

There are many right ways and few wrong ways to hold the meeting. I like variations on Boris Gloger’s Heartbeat Retrospectives. I plan to go into more detail about the retrospective meeting itself in a later article.

An understanding of Lean Principles and XP practices will help you ask good questions to the team. For a discussion of difficult project situations and the role of the retrospective, check out Saving Projects in Crisis on my blog.

Welcome Peter

Dear readers

We just got a new writer for AgileSoftwareDevelopment.com. His name is Peter Stevens. He is originally from US, but moved to Zurich, Switzerland years ago.

Peter studied Computer Science at Colgate University and was working for Microsoft for many years. Nowadays earns his living as a Scrum coach and will add the coach perspective to our site. Peter also writes to his own Scrum Breakfast blog, check it out.

Please, welcome Peter and comment on his writing.

Best regards,
Artem.

P.S.
By the way, if you are thinking about becoming a permanent contributor to AgileSoftwareDevelopment.com author, contact me directly.