Ways of working is how a team collaborates. It should lead to connection, belonging, trust, speed, and momentum, all outcomes of successful team engagement.
Software and tools can only get you so far — assessing and improving team practices is how you build resilience, especially in times of change.
What are the elements that come under the ways of working agreement?
Team Norms and Principles
One of the easiest topics that we take for granted are basic team norms and principles because we believe these things are implicit. But a team is made up of a group of individuals who on a personal level may have different perspectives and ways of approaching things.
In order to ensure we are mindful of the diversity, we encourage documenting a few norms and principles with regards to collaborating within the team.
Communication methods
After 2020, the way we work has changed significantly and with that change, the ways of communication have also gotten more complicated. To bring back some structure to the communication, we recommend documenting a few basics with regards to how you communicate both internally and externally.
Decision making policy
Today decisions are no longer made by a select group of individuals behind closed doors, we are now moving towards a more decentralized approach towards making decisions.
While this has a lot of merits, there also comes different levels of influences on said decisions.
When establishing a decision making policy within your team it is good to first highlight the different areas and types of decisions for example : Strategy, Priority, Project, Architecture, Vacation etc and when you have the areas, map out the level of influence the different roles within the team have. This acts as a good guide to ensure we make good decisions.
Other topics that can be covers here are:
Conflict management policy, Feedback Policy, and anything else you think makes sense to document for your team.
Roles and Responsibilities mapping
Usually in a team we have multiple different roles and each role has a set of responsibilities that come with them. The more cross functional the team, the more roles and thus a more diverse set of responsibilities.
When these different roles come together, there are chances of clashes and to ensure we avoid that, and are mindful and respectful of each other, mapping out the roles and responsibilities within a team is always useful.
This also helps outline what areas are owned by whom, how decisions are made and how the different roles come together.
It is now time to move to some operations areas of the working agreement.
Defining the ways you use Tools
Each company has different project management tools like JIRA, Monday, Trello etc. and while your company might have some predetermined definitions of how to use them, it is important for you as a team to define what frameworks you follow and how these tools support you. Documenting this is important not just for your team but also for stakeholders and other members to better understand the ways of working of your team.
When documenting the way you use the tools, think about the below:
- What are the different columns you have on your board and what does each column mean
- What are the different ticket/task types your team uses
- What are your teams priorities with regards to the different tasks you have
- What is your definition of ready and done for the tickets
- Do you have review and test guidelines?
Lets elaborate on some of them,
Defining the different ticket types
Talking about differentiating between the different ticket or task types, a simple tip to follow is that of task breakdowns.
Have a dedicated format and ticket type for the project that you are working on. You can then break down the project into different milestones and describe what each of those milestones are aiming to achieve, what will be its impact and any other information you believe might be useful for you and your team.
After you have the milestones in place, it would be important to further break it down into smaller tasks that you can then work on based on the framework you are following.
Setting up the column definitions : Ticket status, criteria, and definition
Example:
Definition of Ready
A Definition of Ready describes the requirements that must be met in order for a task to move from the backlog to in-progress. This usually means that the description of the task should have all necessary information, for example:
- What is the task about?
- What are the areas of impact?
- Any and all references are linked. (screenshots, links, potentially related tickets etc.) are attached
- Acceptance criteria are defined
- Dependencies are identified
- The team has a shared understanding of what the task means
- A technical estimation has been done*
Definition of Done
As with the Definition of Ready, the Definition of Done describes the requirements that must be met in order for a task to move to done. Some examples of the requirements are,
- All acceptance criteria are fulfilled
- The task does not introduce any problems
- The task has been reviewed by some team members
- Documentation is written/updated (if necessary)
Reviews
In this section, the team is to come up with rules for code reviews and pull requests.
This is important because each team member has a different style and way of working and while we do not want every single member to work in a manner that is dictated by someone else, it is important to have defined parameters of what it is we are reviewing.
This section can be divided into 3 parts -
Forms of reviews
- Pair Programming
- Walkthroughs
- Asynchronous Reviews
- RFCs ( Request for Comments)
Criterias reviews
- Major changes
- Impacting on downstream projects
- Stakeholder requests
- New features
What is the minimum requirement for review approvals?
- Check for quality, readability, maintainability
- Information security standards
- Functionality tests
- Understand the changes to share knowledge
- Comments on what to check
- PR checklist
Team Workflow
In the last section of the Ways of working document, it is a good idea to also document your team’s workflow.
This can help with both internal and external organization.
For example, if your team works in the scrum framework, here is how you an document it.
Sprint Planning
Goal: To collectively prioritize the tasks in the backlog and have a holistic understanding of what are the requirements.
Purpose: The reason for the collective discussion is to firstly foster a team first approach and secondly to be prepared for the Hawaii factor.
The Hawaii factor states that if one member of the team
wins the lottery and decided to quit and move to Hawaii,
how will that impact the team?
Process: Team members would bring the top tickets that would be the focus of the sprint to this Round and we would discuss this in the team, see if it needs to be broken down and discuss what the acceptance criteria would be. Then the team takes on the tickets based on their capacity which we usually determine by the team’s velocity.
Daily Standup
Goal: The team to share the relevant insights on their tasks with the groups and also talk about the blockers and questions they have in this round.
Purpose: To ensure we are on track to achieving our sprint goal
Process: We meet for 15 mins everyday and go through the same.
Retrospective:
Goal: For us to look back at the sprint and talk about the positives and negatives of the same and then discuss ideas for improvements.
Purpose: To ensure that we are constantly improving things that can be improved.
Sprint Review:
Goal: For us to showcase the work we have done within the last two weeks.
Purpose: To facilitate knowledge sharing and accomplishments of what we are working on. We could also invite others to these sessions.
Process: There is no fixed format. You can either show what you did, or prepare a presentation or even talk.
