BT

Agile Development Team Charter

Posted by Terry Bunio on Feb 27, 2012 |

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

Deliverable Legend

Template Hyperlink/Mingle Deliverable

Process/Meeting

Software Deliverable

 

When ?

Before the Iterations

During Iterations

Throughout the Project

 

As A

I will

When

So That

Project Manager

Hold the Client Project Charter Meeting for the Client

At the start of the project

All Clients understand their role and expectations on the project

Project Manager

Hold the Development Team Project Charter Meeting for the Development Team

At the start of the project

All Development team members understand their role and expectations on the project

Agile Team Member

Review and understand the User Story Map

Before the first Iteration

So that I understand the plan for the project and the content of the work required.

Agile Project Manager

Create the Release Plan

Before the first Iteration

So that we can transfer an Initial Plan to a Manageable plan.

Agile Project Manager

Update my tasks on the Kan Ban Board

Every Day

The status of the project is available to everyone

Agile Team Member

Provide my update at the Stand-up Meeting

Every Day

The entire team is aware of what I am working on an any issues I may be having

Agile Project Manager

Hold the Iteration Planning Meeting

At the start of every Iteration

The team can jointly determine the content of the next Iteration.

Agile Project Manager

Hold the Planning Poker Meeting

At the start of every Iteration

The team can jointly estimate the User Stories in the next Iteration and refine the requirements.

Agile Project Manager

Hold the Iteration Retrospective

At the end of every Iteration

The team can provide feedback and improve for the next Iteration.

Agile Leader

Promote Collaboration over Documentation

Continuously

Miscommunication and Documentation waste is minimized

Agile Leader

Promote light weight Documentation

Continuously

Documentation waste is minimized

Agile Leader

Promote frequent delivery

Continuously

True progress is shown and realized

Agile Project Manager

Defer all setting of priority decisions to the client

Continuously

We work on the true priorities of the client.

Agile Project Manager

Promote the use of Visual Project Management and Agile Project Management Tools

Continuously

We communicate relentlessly the status of the project to the project team and the Stakeholders in a graphical and easy to consume manner.

 

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.

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Can every agile team self-organize? by Udayan Banerjee

Which of the following statement is true?
1. SOME self-organizing teams can be significantly more productive
2. EVERY team can benefit from self-organization

I do not think any agile proponent will disagree with the first statement. However, is the second statement true?

setandbma.wordpress.com/2012/03/05/agile-self-o...

Can every agile team self-organize? by Udayan Banerjee

Which of the following statement is true?
1. SOME self-organizing teams can be significantly more productive
2. EVERY team can benefit from self-organization

I do not think any agile proponent will disagree with the first statement. However, is the second statement true?

setandbma.wordpress.com/2012/03/05/agile-self-o...

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

2 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT