Agile Development Conference 2004 Notes

Open Space Session Structure

The idea of Open Space sessions is to allow anyone attending the conference to suggest topics for impromptu small group discussions, some of which might be continued throughout the week at other, shorter, end-of-day Open Space periods. About 12 topics were suggested. The interesting feature of this kind of session was that there were 5 chairs placed in the center of an area devoted to the discussion. Only people sitting in a chair could speak and one of the chairs had to be open at all times. If a person sat down, at least one person had to stand up making a new empty seat. (Could be an interesting experiment for routine meetings within a company.)

Key ideas from the first day

A key project success factor, because of the impact on requirements at the front end and satisfaction at the back end, is the existence of “lots of systems with lots of people who have a stake in parts of ” them. The agile principle of constant communication and feedback seeks to address this, emphasizing that “there’s nowhere to hide in agile projects.” Compared to typical project development approaches where people can “hide behind someone else’s schedule,” agile projects require people to make their status known daily. This helps maintain the constant pace, acceptance test feedback, and integration advantages agile methods pursue.

Peer-to-Peer: What a Customer of Agile Methods Should Understand (Scott Duncan)

My justification for being at the Conference to begin with was to solicit answers to this topic from people with experience in using agile methods, especially in situations where customers were used to large project process and documentation, such as government contracting situations. Alternatively people were asked to suggest the problems they had seen when agile methods met more formal ones. [This material was to be input an IEEE 1648 Working Group whose goal was to develop a Recommended Practice for customers/acquirers who would be initiating and conducting projects using agile methods. The language of an RP document uses the word “should” in its statements where a full Standard uses “must” and “will” and a purely guidance document says “may.” This puts the RP in between the other two types but does allow it to be referenced in a contract. Unfortunately, though the agile community in the US and, especially, in Europe were very supportive of the effort over the next couple of years, traditional process thinking in the US ultimately killed the idea and participants from the agile community lost interest. The RP was never completed.]

Value of trust

“Bills of Responsibility”

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store