Agile Coaching

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.