Rachel Davies

Applying agile principles to the Agile2008 conference

This year Agile Alliance are supporting the team who are putting together Agile2008 in a brave new experiment in refactoring how we organize our Agile conference. We're actually applying agile principles to the way the conference is put together.

The Agile2007 conference was soldout  (1100 attendees) very quickly so we wanted to expand the conference to enable more people from the Agile community could attend. However, we did not want to lose the interactive nature of the conference - we want people to have the opportunity to learn agile techniques through hands-on interactive workshops which work best in small groups. Also our program is selected by experts from the agile community  in a peer review process and behind the scenes the committees have been overwhelmed by the effort required to review all the sessions. For example, last year we had 150 experience report proposals to review and whittle down to our top 50 reports. It was a similar story for other session types like tutorials.

We could have chosen to remain capped at 1100 attendees because new agile conferences are appearing to meet the demand for agile events. More agile events are being run by commercial organizations such as Agile Development Practices and Valtech Agile Days. Agile Alliance sponsors around 25 other agile conferences every year with special support for new conferences like Agile Open which are run as open space events.

Was there a way to grow the conference without compromising the quality and draining the volunteers who put the program together? I started thinking about how we could apply lean principles to the conference - I talked to Mary Poppendieck about this. I also listened to the bold ideas of Chris Matts (who recommended we go for co-located mini-conferences with community input on stories for the conference) and Elisabeth Hendrickson (who recommended we open up reviews to the agile community).

My final inspiration was Glastonbury Festival the largest greenfield music festival in the world. I've attended the festival on various years from 1983 to 2000 and seen it grow from a few fields to an amazing capacity. In 2007, over 700 acts played on over 80 stages  with about 177,000 people camping in the fields to take part. The way this is done is to create many different stages each organised around a particular style of music - this idea can be applied to our conference to create a . So Glastonbury provided the inspiration for the music festival metaphor which we have applied to Agile2008 conference this year - we are creating many "stages" within our program - each stage is designed around a topic and organized by experts (acting as stage producers) who are truly passionate about their particular areas. Each stage will have a feel of a smaller, focused mini-conference whilst providing the conference attendee with a wide choice of stages to choose from. This should help people find the sessions that match their interests as each stage will have a dedicated space where sessions related to the stage topic will be presented.

The boldest step in changing the way the conference is run is not the music festival metaphor but the way we are gathering and reviewing the session proposals for the conference. We are not doing this behind closed doors - anyone can actually create a user profile and add their own reviews and ratings on the sessions proposals. This will enable presenters to respond to review feedback and adjust their session proposals before the deadine for submissions which is February 25th. This approach has been used for XPDays in UK and Benelux for a couple of years which attract audiences of about 200 people - we hope it will also work for our much larger program.

Check out Grigori Melnik's Agile2008 call for participation message on YouTube

We hope this open process works and we encourage you to participate in it! We already have a good number of interesting session proposals in the system so please do your bit for the agile community and take a peek!

Pairing on Agile Retrospectives Workshop

I've joined forces with PairCoaching.net who specialise in coaching and training in pairs - there's a clue in the name ;-)

So I am excited to announce that I will be running my popular workshop Retrospectives for Agile Teams in September. Last time I was delighted that Diana Larsen co-facilitated the workshop with me. This time I have a new partner to work with Emmanuel Gaillot from Octo Technology who will bring to the workshop his experiences of facilitating retrospectives with agile teams in Paris. I've run the workshop in UK, Finland and Hungary and each time it evolves as the participants share their suggestions for improvement in our retrospective practicals throughout the day so hopefully this time we will have the best Agile Retrospectives workshop yet!

I think someone took a picture of Emmanuel and me at Agile2007 both wearing our PairCoaching T-shirts but I can't remember who that was - if it was you then please send me the photo!

Agile2007 -call for agile project stories

I would like to encourage people who have had an interesting story to tell about their agile project to propose an experience report for Agile2007 conference.

An experience report captures the story of a real agile project, summarizing what happened on the project and the key learning points. These reports allow practitioners to share their practical advice and guidance with other teams.

To make a proposal you need to write a two page summary of your experience which should include the following:

• Title and one-paragraph summary.
• Brief description of the project background
• Your story about what happened, focusing on the most interesting and unique aspects. This is   the meat of the proposal!
• Conclusions: what you learned, what you'd do next time, and advice for others.

Save your proposal in PDF format and then submit this using our on-line submission system by January 26th.

If your proposal is selected for inclusion in the conference then the Agile2007 review team will work with you to help you shape your proposal into a crafted experience report for publication in the Agile 2007 conference proceedings. We aim to have a final report that reads like an interesting story, explaining what happened, why you think it happened, who it happened to, and why we should care.

Please do not propose a report unless you can attend the conference which runs in Washington DC 13-17 August as you will be expected to present a summary of your experience report at the conference. The Agile Alliance who run the conference offer presenters one free registration per report to help facilitate your attendance.

How do you recognise an Agile company?

I just got asked this question: How do you recognise an Agile company? Looking around and making some observations is a good way to start.

Notice the characteristics of communications with the company. One of the things I notice are the amount of red-tape involved in setting up any meetings. The more paperwork the worse it is likely to be. Long company email signatures can be the first clue.

Companies who serve poor quality canteen food with plastic knives and forks don't trust their employees much and so the teams are likely to have a hard time getting the empowerment for agile.

Companies with dress down Friday who display a large cardboard cut-out of what garments constitute casual wear want drones and probably don't encourage new ideas. Motivational posters decking the walls could be a hint that the management team is clueless.

Companies with very swish offices tend not to understand the need for developer messy thinking tools such as whiteboards. Conversly, companies whose offices look in a poor state of repair are probably also neglecting their computing infrastructure so developers will have a hard time setting up development environments, etc.

A clue that teams may be open to new ideas can be books (fiction or technical) and newspapers around. Personalised team environments can hint that the team are trusted and allowed to make changes in their space. Seeing developers talking to each other around a whiteboard or screen rather than with headphones on can also hint that they are open to reviewing ideas with their peers.

Clearly, this is not an exhaustive list but maybe it will get you thinking about some signs to look for.

Bringing Agile Requirements into the light

Where a problem domain grows too large for a single product owner to hold in their head, domain experts and user experience experts are required to help explain to development teams what features are needed and  why. A pipeline starts up. Analysts beaver away at mining the requirements which are passed to developers to iterate on and emerge as software ready for the polishing mill of user acceptance testing. Care needs to be taken that this cascade does not revert into a mini-waterfall. Remembering from the agile manifesto that "Working software is the primary measure of progress", a steady flow of working software deliveries needs to be maintained. But also a steady stream of conversations is needed to keep the project community agile. Without conversations the team would slip back into the stagnant swamp of working from documents alone, isolated from the people they need to ask questions of.

Just because software development process is usually described in terms of tangible artifacts, does not mean that the artifacts are the most important elements. The reason for use case templates or story templates is to assist our learning process, as we explore a domain. The goal of a development process is not completeness.  A requirements document is a merely hollow gourd not an oracle - the learning of its subject matter is the important thing.

Agile requirements do not need to be etched in stone. It's true that stories or backlog items will need to be written down in some central location so that all teams are working from the same basis. But we need to take care not to slip back into the old ways of polishing documents and then slinging them over the wall to development. Agile requirements documents should be thought of as teaching aids, written down for reference purposes to supplement conversations not as a substitute for conversation. To communicate we should write only what is useful and discard the rest. We can only find out what information needs to be recorded by engaging in dialogue.

After all, we should not forget that agile requirements artifacts are transitory - here now but soon to change! The  job of the agile analyst is not to polish requirements but to  dig thru the pile and bring the gems into the light and help the team see where the business value lies in the project.

Blindly following Scrum Rules

Sometimes I come across teams that are following Scrum to the letter but missing the point of Scrum. They have all the roles allocated and all the artifacts in place. But, they have become slaves to the master spreadsheet. They gaze at the spreadsheet in their planning meetings rather than discussing how they will implement as a team. They log time spent and impedimentsin the spreadsheet on a daily basis without questioning where all the time is going. They make a burndown but don't use it to focus on the sprint goal! The track every single task to the Nth degree but they don't use this velocity information to plan future sprints and continue to over commit.

They miss an important point Scrum is a starting point, a means to an end. You can't truly be a Scrum team unless you "Inspect & Adapt" by using your Sprint Retrospective to make real changes rather than logging "Went Worked" and "What didn't Work" lists in the goddamn speadsheet and continuing slogging on without pause for reflection.

Why call it, Refactoring?

At XPDay, two presenters made the point that it helps to explain the practice of Refactoring if you can make code mess more visible. Joshua Kerievsky showed us a movie clip of a listing of a single method laid out page-by-page along the length of a hotel hallway. Kevlin Henney in his talk about Agile Development with C++ presented an silloutte view of a four page method subsequently refactored to a 2 page method. As it happens someone asked me "What is Refactoring?" in the Introduction to XP session. My answer was "Tidying up". It's my opinion that Refactoring is a macho engineers name to hide the true nature of Refactoring so that developers can feel good about doing it. The downside of the cool name is that it is entirely opaque to business people.

Here's a simple example of tidying up that parallels the type of thinking developers do when Refactoring. Last weekend, my office was a mess. I had workshop outputs, workshop materials, contacts and papers gathered from the spree of conferences I have been to lately (OOPSLA, Agile Business, XP Days, etc). It was getting hard to find items I needed. Removing the mess was not simple. I had to separate them into different piles and decide where to store them so that they could be easily accessed again - I even went out to purchase new storage boxes and I definitely threw a large pile of clutter away. It's exactly the same with code! If we talked about Code Cleanup rather than Refactoring it might be a little more transparent to management what we are really doing.

As a Coach I want a Story Template so that People Ask Questions

Back in 2001 I gave a talk "Tuning XP" at XPDay with Tim Mackinnon which presented the story format we used at Connextra: 

"As a role I want feature so that benefit"

This format has become widely used since then and has been nicely rephrased by Mike Cohn in his book "Agile Estimating and Planning" as

"As a type of user I want capability so that business value"

Well, I wanted to share a training exercise that I ran yesterday here which you could run to get your team started with using this story template. But before the exercise a word of caution, this format can lead people to focus more on end users interests rather than the perspective of the person putting the business case forward. Also when given a template people can start treating story cards written this way as mini-requirements specs focussing on the written words rather than using stories as tools for driving a conversations. Even worse that stories that don't fit this form will be battered into shape until they do. Stories help you ask the right questions about the context and reason for the request in release and iteration planning the important part is not about the words on the card but the shared understanding developed in the team.

Now for the exercise (which is loosely based on an exercise run by Jackie Mitchell and Lisa Hunter at XPDay4).

1. You are a family looking for a new house, each person picks a role: For example, Mum, Dad, Son, Daughter, Grandma. Choose name, age, work and pastimes for your role.

2. Based on this what budget can your team afford? Try and be realistic as this will make the trade-offs more real later on.

3. Spend 10 minutes where each person writes stories for features they need in the new house on index cards. Use the form: As a

I want

so that

4. Spend 5 minutes. Try to prioritise your stories. What’s important to tell the Estate Agent (Realtor)? Pick your top five.

Some of the rather charming example stories generated by the teams in the workshop were:

As a boy I want a big garden that can house a kennel so that my mum can buy me a dog.

As a teenage daughter, I would like my own bathroom so I don't have to share with my younger brother (Kevin).

As a teenage son, I want a garage so that I can jam with my punk band.

As a teenage son, I want thick walls so that I can rock out!

As a teenage son, I want to live near the town centre so that I can go to the arcade.

As Mum, I want a large luxury bathtub in the bathroom so that I can relax there after my stressful work day.

As Mum, I want to be near shops so that we don't need to drive miles.

As Mum, I want a less expensive house so that we can afford lots of holidays.

As a Mum, I want to be in a friendly neighbourhood so that we can have lots of parties.

As Mum, I want a big garden so that we can grow our own vegetables.

As Grandma, I want big windows to watch what is happening in the neighbourhood so that I can gossip.

As Grandma, I want to live in town so that I can get to Bingo easily on the bus.

As Grandma, I want to be close to the shops so I can get the groceries.

As Grandma, I want a large porch for a rocking chair overlooking the garden so that I can feel good.

As Grandma, I want an en-suite bathroom with a walk-in shower so that I can avoid injuries.

As Grandma, I want a ground-floor bedroom so that I don't have to climb the stairs with my bad knees.

As a Grandma, I want a surround-sound system for the telly so that I can hear it!

As a creative musical type, I want a loft studio so that I can compose music and get stoned in peace.

As an unemployed son, I want a computer room so that I can keep myself entertained all day playing Doom.

As a Dad, I would like a garage to park my car in so that I can keep my insurance premiums low.

As a Dad, I want a roof terrace so that I can dance.

As a Dad, I want the kids to have their own playroom so that we can have some peace.

As a dog, I want to live close to the park so I can go for walks and sticks to play with would be nice.

As a dog, I want an open fire so that I can curl up in front of it.

As a lonely child, I need to live where I have neighbours so that I can have someone to talk to.

As a fashion model, I want a huge walk-in wardrobe so that I can store my 200 pairs of shoes.

As a fashion model, I want a nice country kitchen with an Aga so that I can Hello magazine around.

As a welder, I need a workshop so that I don't set fire to the house.

As an assassin, I need a secure storage area so that others cannot see my dark secret.

Surprisingly, the top five from each group was pretty similar house with ensuite bedrooms, garage, and garden near park and schools.

Photos of XP workspace, build monitors, team tokens

There are a lot of neat ideas that people have tried out with their workspaces that are not in the public domain. I would like to build up a collection of these and host them as a community resource.

Setting up your workspace for XP makes a big difference. The first XP team I worked in (at Connextra back in 2000) customized their office for XP with convex desks, rolling whiteboards, etc. Since then I have seen teams find ingenious ways to get around the "furniture police" to create planning walls and pair programming workstations.

Over the last 3 years, I have been collecting photos of workspace ideas and I ran some workshops with Tim Bacon and Mike Hill (Industrial Logic) on "Informative Workspace" at XP2005 and Agile2005 conferences. In a couple of weeks I am running another Creating an Informative Workspace workshop at OOPSLA with David Hussman. Also a new workshop "Collaborative Workspaces: Keeping The Furniture Police At Bay" with Mike Hill at XPDay and SPA2007. These workshops were created as vehicles for sharing workspace stories so that techniques get shared more widely.

This morning I bought the URL informativeworkspace.org and plan to create a gallery of photos and stories about team workspace there (I have not set up the website yet but that won't take long). If you would like to share a photo (and maybe also a story about how it evolved) then I will host it there. This will not be a commercial site and I will be quite happy to anonymize any photos (let me know your preference).

Please send your photos to rachel@agilexp.com - Thank you in advance!

Software Practice Advancement conference

If you are a reflective practitioner then please consider putting forward a session for SPA2007 - the Conference for Software Practice Advancement. To be held 25th - 28th March 2007 in Homerton College, Cambridge, UK. This is a conference that prefers leading edge rather tried and tested sessions. We are especially keen in interactive sessions that involve participation rather than lectures. Let's hear your ideas..

More details below or check out conference website.

The British Computer Society's Software Practice Advancement group are putting together a diverse programme of exciting and thought-provoking sessions for the SPA2007 conference. We are seeking sessions that explore emerging practices that software teams can leverage and that create an environment for participation and exchange of ideas.

One of the most rewarding ways to participate in SPA is to lead a session. The sessions - their subjects and formats - define the character of the conference and this is your opportunity to ensure the conference deals with the issues that affect and interest you. You don't necessarily have to be an expert - a good session is one that provides a structured forum for participants to develop their ideas, skills, knowledge and understanding. A well-established shepherding process is in place to provide assistance and support to presenters.

The SPA Conference has a long tradition of active participation. We encourage conference sessions that bring people together to work and learn. In most cases, sessions are highly interactive, involving participants fully with the session leaders and each other. We welcome proposals for sessions on any aspect of contemporary software practice. The topics list is given for indication only and we encourage sessions that cut across these areas, or explore entirely new areas, as well as sessions that fall squarely within them.

Usually sessions are either 75 or 150 minutes long and can take a number of forms including workshops, tutorials, case studies, think tanks, goldfish bowls and working groups.

Themes of interest fall in the broad areas of Technology, People, Process and Practice and particular topics of interest for 2007 are Novel System Structures, What Really Works and Evolving Systems.

The closing date for submissions is 11th September 2006. Proposals must provide a clear outline of the proposed session but do not need to include materials such as completed papers and presentations. Final materials for accepted sessions are due in January 2007.

Further details can be found on the conference web site (www.spaconference.org).

If you have any queries, check the FAQ on the conference web site or contact the programme chair, Eoin Woods (eoin.woods@spaconference.org).