Agile Development Team Charter

Traditionally, Project Charter discussions and documentation has focused on project scope and the goals and objectives for the project. Although these ‘what’ discussions are very important and required on all projects, we have had team members ask for more information and clarity as to the ‘how’ of the project. To address these questions, we have recently created and successfully utilized an Agile Development Team Charter.

On other projects I have been part of, these traditional project kick-off activities often involve a meeting that can have a lack of energy and enthusiasm. The project charter document is typically reviewed; it details the project goals and objectives, project scope, and roles and responsibilities of the clients and team members. In many cases the document can be overly textual and team members come away from reading the document not understanding what a typical day or week will be like on the project. Even when a meeting is held to review the document, the content can still be somewhat generic and not allow people to understand their place on the project and the expectations of all team members.

This is especially important for team members on an Agile project for the first time. They are anxious to gain more understanding and clarity in what they will be expected to do on the project. In addition, Agile projects usually have additional expectations in regards to team work, collaboration, continuous improvement, and innovation.

Objectives of an Agile Development Team Charter

The objectives of an Agile Development Team Charter are three fold:

1) Build a team culture of safety and confidence

If you can build a culture where people feel safe in making suggestions or recommendations and where people are confident their ideas will be heard and truly considered, I firmly believe you will get more team work and ultimately more innovation. I think frequently people limit the ideas they bring forward because they feel they might be blamed if the idea has unintended consequences. (or they may be criticized for an incomplete idea) In addition, people want to be sure that the idea will be seriously considered if they are going to put the time in to develop the idea.

To accomplish this, we rely and review the Agile Prime Directive:

“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”

–Norm Kerth, Project Retrospectives: A Handbook for Team Reviews

The Agile Prime Directive is invaluable as it removes blame and us versus them thinking from the project. It sets the stage for people to feel comfortable in raising ideas and suggestions without the fear of initial criticism and blame somewhere down the road. It also places the onus on the individuals to hear their team mate’s ideas without being critical. It places the emphasis on “seek to understand” rather than “seek to find fault”.

2) Create a culture of Innovation

To create the culture of innovation that is desired on Agile projects, we review the following two concepts:

I)                   Encouraging the small innovations

If you encourage the small innovations in people, process, and technology, I have found that the large innovations will follow. If you analyze what is perceived as large innovations, you will typically find that they were made up of a lot of small innovations along the way. How do we encourage the small innovations? Recently our teams have created incremental improvement statements to focus on small improvements. The small improvement statements we reviewed on the last project were:

1.      I will strive to be a better team member tomorrow than I am today

2.      I will strive to be a better [BA/PM/DBA/Developer] tomorrow than I am today

3.      I will strive to help to make the solution better tomorrow than it was today

4.      I will strive to help to make problems, issues, and risks less tomorrow than they were today

5.      I will strive to help to provide more value to the client tomorrow than they had today

6.      I will strive to help to create better processes tomorrow than we have today

II)                Let the team innovate

Many teams that have a perceived lack of innovation share the same structure. There are a few leaders that ‘approve’ the innovations that will be implemented and they expect their team members to submit their innovations for approval. This very structure stifles the innovative process. How can the few leaders at the top have the same wealth of ideas and domain knowledge as all the members of the team to evaluate what is a good innovation? Anytime there is an approval process, you can be sure there is not going to be much innovation.

“As a leader, you don’t need to be convinced or believe in every innovation, you just need to believe in your team.”

Many times you may believe that the innovation may not work. But you again need to trust your team. Otherwise, the team will get a sense of what ideas you are likely to approve and only raise those ideas to your attention. And before you know it you are only getting one person’s idea of innovation from a team of many. And then in the Project Retrospective we will bemoan the lack of innovation.

The team doesn’t submit ideas or innovations for approval; they just inform the team as to what innovations or ideas they are currently implementing.

3) Communicate Team Member activities in a new but familiar format

After thinking about the problem of team members not fully understanding what their expected activities on the project will be after reading the Project Charter, I was reminded I had heard these issues and comments before. I think we have all heard these comments many times about User Requirement sessions that reviewed a large textual document and then scheduled excruciating meetings to review the documents in detail. And then at the end of those sessions, the clients still didn’t have a good understanding of what those requirements meant to them personally and understand what their place in the solution was.

So I thought if User Stories are successful in grounding clients with the solution and enhancing communication on User Requirements by making them personal, why not try the same with Project Team User Stories to describe the team member’s project interactions in the same way?

Project Manager Example

Here is an example of what a Project Manager’s interaction could be. There are some heavier weight documents listed that are required on my current project that would not be used all the time, but I thought it would be good to include them for completeness. Although you may have a different opinion of what deliverables are required on your Agile projects, I think this table communicates the intent of the idea that you can customize to fit your projects.

Legend

Summary

The components of an Agile Development Team Charter are unique and valuable. We have reviewed them on my current project and the development team thought they were very invaluable to help them to understand their activities on the project and the expectations of for all team members on an Agile project.

About the Author

Terry Bunio currently performs iterations at Protegra. Terry never wanted to be known as a Project Manager. His main career has been in Data Architecture. Along the way Terry discovered that he enjoys helping to build teams, grow client trust, encourage individual growth, doing project work, and helping to coach teams and solutions. It seems that some people like to call that Project Management. As an Agile Coach, Terry is known to question assumptions and propose compromises that deliver the most value to the clients and teams he is part of. Terry is committed to Agile implemented according to Lean Principles.

Terry is still bitter about the Green Bay Packers early exit from the NFL Playoffs.