16
In an Agile team, this is turned on its head. Communication is conversation-centered – direct conversation is the primary means of communication, with documents playing a supporting role. Agile documents contain barely sufficient detail and are intentionally created to convey the instability of the information they are communicating. For example, a site map that may traditionally be created using drawing software might instead use sticky notes on a whiteboard with hand-drawn connectors. In a traditional project, a site map may have been created by an individual team member, possibly following a team session in which the site map perhaps was sketched out. In an Agile project, the document created by the team is the primary artifact – project artifacts are created less by individuals and more by the team during working sessions. Unless there is a specific requirement or direct business value, documents are never seen as an end in their own right, but rather as a means to an end, which is to create a high quality software product. A document is not expected to remain up-to-date or be comprehensive. It is only expected to be enough to move the project work forward, to be a placeholder for conversation among team members. Iterative IA A key difference between an Agile project and a traditional project is when the team actually starts to build working software. Commonly, this will be anything from two weeks to two months after the project starts. From that point forward, the software product is built in iterations, with working software being released in recurring cycles. In other words, far less IA is defined up front, and is instead defined throughout the project, leveraging what has been built so far to inform later iterations.