Project managers and developers have long been at odds with each other over deliverables like the project charter. The project management view is that the information is needed, albeit by parties outside the project team. On the other hand, the project teams see their effort being siphoned off. Generally, the charter has been considered a control document, therefore the bastion of stakeholders and project managers. Agile techniques and the institution of the Agile project charter has changed that. However, all of the parties that consumed the information from the classic charter still have information needs. There are three audiences for the information in the classic charter: the teams, stakeholders and executives. Agile while still generating and sharing information provides it via different channels.
Agile teams are the primary consumer of the Agile team charter. The charter is a tool to help the team identify the project goal in their own words and then to concentrate the team’s attention specifically on that goal. Attention is an asset that is never overabundant, but is critical for any team if they are going to deliver the stories to which they have committed. Along with direction, the charter also serves as a tool to guide the team’s behavior. The team identifies norms that establish an environment that is conductive to performance.
In the past, charters have been developed or framed by stakeholders or sponsors. Because of their authorship, it often takes on the feeling of a contract that can constrain and bind. Agile projects, and by extension Agile team charters, are flexible and dynamic to enhance the team’s ability to respond to the users and product owner needs, as they are discovered. In many circumstances what stakeholders are looking for in the charter is a communication channel, or at the very least, a place at the table to influence and guide the project. In the past they have either written the charter or have signed off on the contents in the charter. Agile projects respect and embrace this need by providing techniques that generate involvement. Inclusion of the product owner as a direct part of the team, and the participation by a wide range of stakeholders and users in demonstrations where the team seeks approval and feedback are examples of Agile team’s recognition of the business’ place at the table. Instead of asking stakeholders to specifically define what is going to be delivered in the charter up front, Agile uses inclusion to dynamically define the projects outcome. This ensures that as need change, so do the goals of the project.
The classic project charter provides executives with an understanding of the important projects within their organizations. The need for information about strategic projects, whether Agile or any other another method, is no different. Charters are often used in organizations to authorize or approve a project; when an executive signs off on the charter it signals the beginning of a project. Authorization and notification is taken care of with one signature. The Agile team charter is not the right tool for authorization because the charter now guides the team rather than authorizing the team. Agile organizations separate the team charter from authorization and typically develop a simple authorization form that is separate from the charter.
In the age of empires, kings and queens granted charters to companies. These charters identified the organization’s rights and obligations. Typically the charter established the governance structure for the endeavor. Today, many project charters follow in the same proud tradition. However when practicing Agile, much of the structure of classic project charters is overhead or shifted to other, more interactive techniques. In today’s environment rarely do we need to approach projects as if we were chartering the East India Trading Company. Agile team charters work hand-in-hand with other Agile techniques like including product owner as team members and demonstrations that seek input to share information with a wider community.