We've recently hired a new Product Owner (PO) into our organization, which is a software engineering department inside an academic research institution. She recently asked her team to create a 'team work agreement', which she claims is "standard practice in Agile shops."

We consider ourselves to be building an Agile practice here, and I've been working in similar (for-profit) software shops for a long time, both as a developer and as a scrum master. I've never heard of such a thing as a team work agreement, but that doesn't mean it's not common, or that it doesn't add value. And thus far, she seems to be doing things right - She's asked the engineers to actively participate in creating the agreement, and it includes important artifacts like a definition of done for the team.

My experience has been that most self-organizing teams will bubble problems up to management when they become unbearable, and I'm concerned this agreement could be used more like a hammer against the engineers than a means of improving teamwork. I manage some of the developers on this team, but not the lead developer or the PO, and the PO group is managed by a separate arm of the department.

Do any of you have more experience with this kind of thing? Do you think it improves the likelihood the team will deliver more value, faster, and/or with higher quality? How likely is it to be harmful?

Update 2022.10.10:

A number of the answers and comments have referenced "Teamwork Agreements." I'm asking here about "Team Work Agreements", and the difference may matter (depending on how you look at it.)

  • 8
    How else do you, as a team, agree on how you work? The way of working should be written down somewhere. This is especially useful for onboarding new people to the team. It doesn't mean it's set in stone and immutable, but having it written down makes things clearer. I haven't heard them called that, but Atlassian appears to even have a way of working to agree to one.
    – Peter K.
    Commented Oct 3, 2022 at 14:51
  • a new purchase order?
    – Tiger Guy
    Commented Oct 3, 2022 at 15:24
  • 3
    I don't think that answers to your questions would be very helpful to you, because nobody will know how that agreement will be interpreted and used in your organization.
    – Philipp
    Commented Oct 4, 2022 at 9:27
  • @Philipp That is a great point! However, I think there's value in sourcing for knowledge here (even if it's not terribly scientific), because some answers may offer clues that indicate how likely they are to generalize to my situation. Commented Oct 10, 2022 at 21:58

7 Answers 7


Such an agreement is a standard part of Agile. It's an agreement between the team members about how work should be done, details of how processes are carried out.

In a lot of places the teamwork agreement is implicit - everyone agrees how things should be done, and so there is no need to write it down or even talk about it. Most places effectively have such an agreement even if they don't know it. It only becomes necessary to talk about it when there is disagreement within the team about how something should be done. (Also a lot of places like to say they are doing Agile when they actually have no idea about Agile principles, but that's another story.)

Examples of things that might get put in the team work agreement:

  • All code reviews should be completed inside one working day of when they are requested;
  • All changes to the database tables structure must be reviewed by the DB architect
  • The code coverage for unit tests must never drop below 50%
  • There will be 2 grooming meetings each sprint.
  • No meetings to be called before 10am

Definitions of Done are extremely useful, and no team should be without one (explicit or implicit).

The value of the agreement is that everybody knows how things work and what to expect from other people, and can work in harmony. The agreement can and should be updated if necessary as a result of a retrospective.

Here are some links on the subject from knowledgeable agile practitioners:

  • 14
    ^this. I think you're taking it to mean the PO is going to tell you how to do your job, what it actually means is everybody agrees to a set of standards. Then, if you run into problems (like a production bug), you can point to misses in your Agreement and update it as needed to make sure those problems don't happen anymore (more testing, more time for QA, more rigorous code reviews, etc) Commented Oct 3, 2022 at 15:10
  • 2
    One of my favourite items in such an agreement was "Don't be a d**k". Subjective maybe, but set the tone quite effectively. Incidentally, in some shops, this agreement is an outward facing "charter" as well as an inward facing "agreement". This again "sets the scene" for other teams working with the Agile team, giving them some idea of what to expect (and what not to expect). IMHO, such a document should be easily editable (perhaps on a wiki?), and not "issued after review" like some corporate documents. Knowing it CAN be changed is a powerful feature. Commented Oct 4, 2022 at 8:30
  • 3
    Thank you for the answer! I like most of it, but I beg to differ on the opening assertion. Having worked in seven 'Agile' shops that don't do this sort of thing, I have a substantial amount of empirical evidence that suggests this isn't a "standard part of Agile." Furthermore, there's nothing in the Manifesto that says anything about working agreements, and the very first postulate ("individuals and interactions over processes and tools") suggests not having one has more value. I'd say that's especially so if it's written down and forgotten for years until someone needs a hammer. Commented Oct 4, 2022 at 14:25
  • 2
    I don't think it is a "standard part of agile"... I've worked in various different incarnations of agile at many different companies in different sectors and I've never been asked to do this... If anything, having a "teamwork agreement" like the one you've outlined here is the antithesis of agility... Writing something down makes it more rigid, harder to change and therefore less agile Commented Oct 4, 2022 at 16:09
  • 2
    @DJClayworth - Yeah... All to companies trying to sell certifications and that are making agile far, far more complicated than it needs to be. If you ask me, agile certifications are an oxymoron, since to certify someone in something it has to be somewhat static. Agile should never be static. Commented Oct 4, 2022 at 16:19

I guess this reminds me somehow of what "Judge Wapner" said so many times on the old TV show, People's Court: "Put it in writing."

In this case, I think that the major benefit of doing such a thing is simply "the act of doing it." The act of thinking about something in such a way that your goal is to "write it down." This can actually be a very good way for the team (and, management) "to express and to describe" what often isn't expressed nor described, even though these things are very important.

Every team necessarily has these procedures, processes, and understandings. Necessary to work together as a team. But, very often, they never actually "write them down," or think about them in the level of detail and in the manner that is required in order to "write them down." It's a very good exercise. Do it.

Good ol' Judge Wapner said many times that most of the cases which wound up in his (small claims ...) court never would have gotten there, had the two parties just taken the time to first, write down what each of them thought that they had "understood." Whether or not they then signed their names to copies of it to make it a legally binding contract. A very interesting idea with, I think, applicability to the workplace.

  • I appreciate this answer, but I don't think a court of law is a good analogy here. If you've gotten to the point of needing someone outside of the team to adjudicate a hostile relationship (which is how people end up in court), someone on the team is likely to get moved or fired, regardless of the presence of a written agreement in the team. I'd rather that be the person the one who argues like a lawyer that they're inside the letter of an agreement (especially if they're violating its spirit) than the one who's reliably creating working software (which I don't need an agreement to see.) Commented Oct 4, 2022 at 14:36
  • 3
    @BillHorvath you're overthinking a probably not that deep analogy. Apart from the law thingy Mike is completely right here (likely imho): the new PO doesn't want to do or change much, they just want what's currently implicitly agreed in the team explicitly written out so they are up to date on anything (and dont unknowingly screw up), and to help potential new hires
    – Hobbamok
    Commented Oct 5, 2022 at 8:28

I admit, I'm in the same boat as you - I've been doing various forms of Agile development for quite some time and never had or needed a Team Work Agreement. In many cases, though, my corporate culture has covered much of what might be in such an agreement. When I google the world, I do find a whole lot of reference points, the majority of which relate to Agile team working agreements (but then, I'd like to think I've finely honed my Google patterns to make it think I work in SW development..., so mileage varies).

Perhaps a way to go at this is to ask for a private meetup and ask the PO to highlight what issues/gaps she sees that a Team Work Agreement would fix? If she can highlight some stuff that she thinks would go better with such an agreement - then great, you've found some places the team can improve, and maybe centering the agreement around those areas is a good way to go.

If the answer is "well, it should be there, I've always had one, etc, etc" - where all she can do is talk in generalities, then your experience with self-managing teams that don't need the agreement is just as valid as hers. In that case the "ain't broke don't fix it" comes to mind - there's not a big need to create formality if it doesn't solve a purpose. But if she's the kind of person who won't feel comfortable without clear rules, maybe she could take personal exercise upon herself to write down what she sees the team doing and what's unclear to her about what they are doing and then vet THAT with the team, and that doc could work as new PO onboarding tools? Then she can have her clearly written rules but in a less official way.

IMO - written or unwritten - if a person is going to use a set of rules to clobber a team, then that's going to have to be addressed when it happens.

Another tact would be to seriously timebox this thing - take a day, jot stuff down, and take an action to review it at the next retrospective.


Do any of you have more experience with this kind of thing?

Yes. Building an agreement or "charter" or "purpose" or "values" document is pretty common and are flavors of the same idea.

Do you think it improves the likelihood the team will deliver more value, faster, and/or with higher quality?

That depends entirely HOW the process is done. In most cases it doesn't work well since it's often dictated by management with little input no buy-in of the people who do the actual work. HOWEVER, it can be done well, even if it's a fair bit of work.

Example: You can get the team together and start with the question "what is good code"? Let everyone write down the own definition. If you ask 10 people, you will get 10 different answers. Then review all of them, figure out where there conflicting ideas and reconcile them. Discuss priorities. Brain storm ways measure the "quality" of the. Discuss what metrics and processes to use that are both meaningful and practical in everyday life. The manager should just be facilitator and do a lot of listening and very little talking. Ideally all this should come from the team and should only be overruled if there is a strong (and easy to explain) reason to do so.

How likely is it to be harmful?

Most documents of this type are considered useless blabber and mostly just ignored. Harm happens when the leadership behaves in contradiction with the document. Thats hypocrisy and breeds cynicism.


Do any of you have more experience with this kind of thing? Do you think it improves the likelihood the team will deliver more value, faster, and/or with higher quality? How likely is it to be harmful?

In my experience, such a document is rather worthless - much like a company's "Value Statement", or a team's "Mission Statement".

It's the people and work culture that matter.

A document isn't likely to cause the team to deliver more value, or deliver faster, or improve quality. People do that - people who care. To the extent that the team can come to a common agreement on their work culture and practices, it might help. But realistically, it won't make any difference, in my experience.

The document itself isn't likely to be harmful. Product owners (and others) don't need a document if their intent is to hammer engineers.

My suggestion would be to make sure the team understands what the Product Owner is looking for, and deliver it - hopefully without spending too much time. Perhaps she even has an example you could use as a template. Get that behind you, then move on to getting the real work done.

  • "It's the people and work culture that matter" - ... and documenting your standard operating procedure (definition of done, code style guidelines, minimum requirements of issues to be picked up, required contents of pull requests) is how you get a team organized into the same culture. If everybody's equal and everybody's got opinions, it helps to document stuff to create consensus. It appears like your answer states something like "documenting stuff is unnecessary, a good team organizes itself", but not every team is good from the offset.
    – CodeCaster
    Commented Oct 4, 2022 at 11:29
  • "waste of time" and "worthless" and "isn't likely to be harmful" ignores the value of having a discussion with a team to align the goal. The documentation itself might not be referred to afterwards, but the act of sitting a team down and discussing and documenting it will help create consent and expose unwritten or not uniformly carried-out rules, which has more value than your answer gives it.
    – CodeCaster
    Commented Oct 5, 2022 at 12:55

For context, I work as a Technical Lead at a major UK consultancy. I've worked in various different incarnations of "agile" for over a decade across many different companies. Although these thoughts are my own.

"Developer Covenants", "Teamwork Agreements" or whatever other buzzwordy thing you want to call it today are almost always a terrible idea regardless of what agile system you're following.

The whole point of agile is to embrace change. This doesn't just apply to changes in software requirements, it also applies to your ways of working.

You need to be constantly introspective, looking at what works well with your processes, what doesn't and tweaking and changing them over time to suit the way that your team likes to work. This will evolve as people join and leave your team, and as new practices come into the industry. It's not even important that any two teams in the same department follow the exact same systems as long as they're roughly aligned in broad brush strokes (you don't want one doing Kanban and the other doing agile).

Writing things down, even in "a living document", has a horrible habit of turning them from rough guidelines into rules. Once things become rules, they become harder and harder to change over time until they become entrenched. At this point, you're stuffed. You lose all semblance of agility and you lose your ability to adapt and to improve.

I'd recommend pushing back against this hard.

It's also worth remembering that the vast majority of companies get agile wrong and those that employ "Agile Consultants" for their transformations tend to get it even more wrong, more frequently.

  • 3
    Having an agreement does not mean you are not being Agile. And bein Agile doesn't mean you never write things down. If you read best practice on the subject, Teamwork Agreements are decided by the team and can be changed by the team whenever necessary. Read my answer for links on how they work and why they are beneficial. Commented Oct 4, 2022 at 16:18
  • 2
    @DJClayworth - I've read them, I know what they are, and I fundamentally disagree with you. Sure, being agile doesn't mean you can't write things down, but writing down things as basic as how you work together is unnecessary and so adding in that extra layer of friction towards change is just counterproductive. Agile shouldn't be complicated. Commented Oct 4, 2022 at 16:19
  • 1
    Are you sure that everybody on your team knows everything about how you work? Then don't bother writing it down. Or you might find that not everybody knows it. At the very least writing a document gives you the chance to talk about it. What are you going to do when somebody on your team suddenly decides to do things a different way? To maybe not get a code review, or not write unit tests? Commented Oct 4, 2022 at 16:23
  • 2
    So you have processes? If you have processes, and the team agrees to follow them, that's a Teamwork Agreement. How do new people get to find out about the processes? Do they have to ask someone how to do things every time? Or are those processes perhaps written down where they can look them up without disturbing people? Commented Oct 4, 2022 at 16:26
  • 2
    I know nothing of the kind. I think you are making assumptions. And I've been in situations where "implicit" agreements were a disaster, for example because communication issues meant people actually didn't know what to do, or because people used the excuse of things not being written down to ignore processes. Commented Oct 4, 2022 at 17:07

The Agile Manifesto:



The agile manifesto mentions these points:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan
  • The best architectures, requirements, and designs emerge from self-organizing teams.

(Emphasis is mine.)

Two of those points argue against the fluff of unnecessary documentation, one promotes the power of self-organising teams. On top of that producing such a document takes time and effort, so if there's no use in it, it runs counter to "Maximising the amount of work not done" (another agile principle). Once such a document is established, it may make it harder for a team to self organise as they need to keep the document up to date as their way of working changes - assuming the document is even allowed to be updated without a review process... I see a special form of hell may lie on this path!

It depends on what the document is supposed to be. A teamworking document shared with a PO should, IMO, be a lightweight mission statement on principles to make the productive relationship flourish. It is, after all, being described as a "teamwork" document, not a process description. To shamelessly rip off the sites linked above maybe something like:

"We strive to be flexible and responsive in collaboration with our POs to deliver working software through appropriate processes and tool use".

If, on the other hand, this is an attempt to capture your way of working in a "Team A's process document" then I see little value in it for yourselves, let alone for your PO who cares not a bit about code reviews and git branching techniques.

(Oh, and I've worked in agile teams for more years than I'm going to admit, and I've never seen or heard of such a document.)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .