Initiators: Costa Pissaris, DeborahHartmann
Participants: Martin, Scott, George, Ross, Costa, Rick, Charlie, Michael Ben-David, RegBraithwaiteLee, Deborah (who's missing? please add your name!)
Given the fact that most companies prefer a complete requirements document before proceeding with development activities, can Agile methods be applied to development of the requirements?
Sometimes requirements act as contracts. The requirements then act as a proxy customer.
Our conclusion is that telephone book requirements documents are not very useful or productive. One function they serve is that of "plausible deniability" - team members "didn't see it in the requirements" so they are not responsible for whatever is missing - they are not responsible to think, question, participate. They require the extra overhead of "change management" because we know they are never really complete until the project is over.
Nonetheless, sometimes blockers are needed to pretend to be following traditional practices but leave the development team free to proceed in an agile manner.
Users were often quite happy with an agile approach, but traditional IT departments are the ones who like to get telephone book requirement documents - CIOs, COOs were cited. Why do these people hang onto the "phonebook approach"? Suggestions: it's what they know, they don't know another way, they can't imagine that another way will work.
Ideally the team should be proceeding to develop in an agile manner and wean IT departments from a document heavy approach and demonstrate value by delivering working software. If the team is still required to produce these same documents, under Agile they can start by using iterations to deliver small slices and they don't freeze the documents until the software is delivered for a given iteration. This requires dropping the customer sign-off before coding starts. The question was asked: how can you start coding if the requirements are not complete? Answers: a) no matter what we say, we know that they will never be complete; b) you start coding when the requirements are judged "sufficient" and go from there. Once teams are working in iterations, Agile practices can be introduced over time. They will be more attractive when the requirement is no longer seen as a "contract".
Another common customer proxy is the Business Analyst, or whoever collects the requirements in a traditional process. Is this a good or bad idea when using Agile?
Risk: when using real customers: On long projects, a dedicated customer resource on the team could become "obsolete" or out of touch with their business area due to their absence from their own work.
Suggestion: if you decide to take this discussion offline to a newsgroup, please indicate the location of the group here so others can join you.
It seems clear from the session that traditional IT departments are increasingly seen as a problem and an obstacle to effective development practices.
There is an interesting article in the January 2004 issue of CIO at http://www.cio.com/archive/011504/itwork.html in which it is stated that continued outsourcing and cost cutting by central IT groups is leading front line P&L departments to do their own IT. These 'grey' projects ignore central IT groups and funding. An unstated assumption in the article is ineffective delivery practices by central IT groups.
Grey projects are almost by definition agile. The customer is motivated and interested in working software as quickly as possible. They don't care about telephone book requirements and they don't need blockers to pretend to be following some ineffective process.
It seems to me that anyone looking to use Agile approaches should be looking to participate in these 'grey' IT projects outside the IT mainstream.