Team Working Agreement

eAPD Team Working Agreement

What is a Team Working Agreement

“The purpose of the working agreement is to ensure the Agile Team shares responsibility in defining expectations for how they will function together and enhance their self-organization process. It creates an awareness of both positive (and negative) behaviors that can impact the Team and empowers the Scrum Master [AKA project manager] to keep them accountable.” -General Services Administration

Our Team Working Agreement (TWA) is a document created organically by the collective voice of the team based on the needs and desires of the team. It is not generated top-down, but collectively.

The TWA is important to and fully supported by the entire eAPD team. It can be used as a tool for supporting strong team communication, for growing the team and helping to set boundaries as well as expectations, and it should help the team mature. It helps articulate the vision, values, courtesies, defines success, and assists with team communication preferences.

The TWA is readily available for reference and will be reviewed and periodically updated by the team, especially as new team members are onboarded.

The TWA is readily available for reference and will be reviewed and periodically updated by the team, especially as new team members are onboarded.

Vision and Approach

• The eAPD team is a trailblazing team. Our Product Manager works directly for CMS and is trained in product management, software development, and setting strategy. Our Product Manager is not just a Product Owner (PO) or subject matter expert (SME) who signs off for the sake of signing off, but is integral in our team processes and vision.
• We practice lowercase agile, making decisions based on what is best for the team at the time the decision needs to be made.
• At regular intervals, we reflect on how to become more effective, then change our behavior accordingly.
• We don't have a set of traditional top-down business requirements outside of the Framing document and what is required by policy and/or regulations.
• We build what CMS/users need based on research, and are able to pivot as more information is discovered.
• We practice Human Centered Design (HCD) according to the needs of our team, vs adhering to a strict list of deliverables or methods.
• We have shared vision/mission/goals. The roadmap is shared often and milestone planning (multi-sprint planning) is conducted on a regular basis so that we know what we’re working toward.

Values and Courtesies

• We have a people first approach in both our processes and for our users and stakeholders.
• We do our best and assume everyone else will too.
• We trust in the expertise of teammates when making suggestions.
• We are willing to give and receive feedback.
• We attend meetings that we are invited to and are engaged while there.
• If we can’t attend a meeting, we let the team know beforehand.
• We don’t place blame, we help each other solve problems.
• We create an atmosphere of safety where it's safe to fail.
• We admit mistakes, because we know it's totally ok to make mistakes.
• We agree that feeling overwhelmed is not a sign of weakness, but a need for improved understanding/discussion, or just simply a reason to reach out to the team for help.

What Success Looks Like for the eAPD Team

• One Team, One Dream
• We have fun, and enjoy a sense of humor.
• We share a similar sense of drive and enthusiasm in serving people that use the eAPD system.
• We release excellent products we’re proud of that make our users’ and stakeholders’ jobs easier.
• Building software doesn't always have a clear right or wrong answer, but we find the best answer according to the constraints and information we have at a given time.
• We pursue a standard of excellence for what we ship, knowing that perfect software doesn't exist.
• We are able to respectfully remind each other of and encourage following the TWA.
• We recognize that our teammates have the level of experience and quality of work to accomplish what is needed to build a great product.

Team Communication Preferences

• Information flows accurately between teammates and no one should feel left out of conversations.
• If someone does feel left out of a conversation, we can assume that is not on purpose and ask questions to be brought up to speed, or share information to bring a teammate up to speed.
• To limit the above, communicate through the main CMS Slack channel as often as possible and limit DMs about the work if possible so that decisions and information is not lost. Use the Fearless Slack if folks are new to the team and do not have access to the CMS Slack but generally only use the CMS slack channels.
• If a decision is made in a DM or 1:1, please transcribe the decision into the corresponding issue.
• Discipline specific (design/dev) syncs are open to other teammates, but are not required except as needed according to topic.
• Provide introverts and thinkers reasonable time and space to respond.
• Use the 8 seconds of silence rule to give people space to think about answering a small question in a meeting.
• Convey the purpose of meeting at the beginning of a call. Where applicable, use agendas to convey the topic of a meeting, preferably 24 hours ahead of time, especially where you will need feedback from the team.
• Zenhub issues are “team issues”, not just belonging to one discipline. We can all respectfully contribute and solve problems together as appropriate.
• Follow the processes outlined in our wiki to the best of our ability, or change them if they aren’t working.
• Be mindful of people’s communication preferences as documented in our communication exercise, where possible.
• Be respectful of people’s communication needs. Response to Slack messages as soon as possible, but no greater than 24 hours after they are sent (business days). Response to emails: 48 hours.

Core Hours

• Respect each other’s time by being on time for meetings, preparing agendas, and following good agile practices in ceremonies.End meetings on time by keeping things moving and tabling things that require a longer discussion.
• Communicate if we are unable to make a meeting as soon as possible.
• The team has a lot of flexibility for remote life needs and taking care of yourself and family.
• These hours are the times we might expect to be scheduled for a meeting, but are not indicative that we must be locked to our desks the whole time.
  • Core Hours (all time zones): 10-4pm ET
• Try to schedule meetings between 10-4 PM ET to allow members to work. Where possible, don’t schedule meetings on Friday.
• For eAPD related meetings aim to be done 5 minutes before the scheduled end time. We are all responsible for helping keep time and moving things along.
• If you are off (scheduled or after work hours), you are not obligated to respond to slack messages or emails.