Formulate Effective Ways of Working for Your Agile Teams

A non-exhaustive but essential set of principles that you need to establish with your agile teams.

Source: Unsplash

Why Are “Ways of Working” Important?

When running your team’s day-to-day operations, having an agreed manifesto of Ways of Working will help keep the engine running as smoothly as possible. Codifying this in a readily available document makes it handy to remind the team what the agreed ways of working are.

The agreed “Ways of Working” manifesto should be readily available to remind the team how to work effectively together. It will be a living document that has to be updated continuously based on your team’s situation. Ways of Working usually are initiated during an agile team’s kickoff. Ideally, during sprint retrospectives, health checks, and team refresh sessions, the updates to Ways of Working are best discussed.

As an engineering manager or lead, you need to help your team/s in establishing ways of working early on, ensuring that the team is set up for success in their sprints — these ways of working need to align with your organization’s engineering principles and production standards.

Theteamin this context refers to the smallest unit of a group of people in an organization. For example, if you are using the tribes and squads model, then the squad is the equivalent of ateamin this write up.

Let’s cover the essential Ways of Working principles in the next sections.

Ways of working mindmap.

1. Definitions of Ticket or Card Statuses

When working on a ticket, the definition ofDoneis essential; however, whatIn ProgressandReady for Developmentmeans are also important. When reporting the status of the task assigned to you, sometimes it can be vague what that exactly means for other team members if its meaning is not correctly defined. We can be as specific as we can on the status or swimlanes depending on the tool we are using. But we can only have as many swimlanes that we are allowed to configure by the means that we use.

For example, the team should agree that when the ticket’s status is Done, depending on the type of task, it could mean that:

• If it’s a new feature: it is merged to master, and it is live on production.
• If it’s an experiment: the feature is in production and rolled out to 20% of users.
• If it’s a spike: the tasks with all the necessary information are established and reviewed by the team.

The definition ofReady for developmentcould mean that:

• The story has the requirements provided by the product manager.
• The ticket should be broken down into actionable subtasks.

Agreeing to these definitions with your team will save you time in your daily stand-ups and unnecessary clarifications and check-ins in the future.

Definitions mindmap.

2. Support Rota — Someone on “Support” Is Assigned Every Sprint

As your products and services grow, customer support tickets, bug reports, business-as-usual work (BAU), repetitive tasks, and inquiries from other teams will start to feel unmanageable at a certain point. Which is a good problem to have — it means that you are working on something important. Though this can be partially resolved by providing adequate documentation or an FAQ document, and automation tooling, it could still take a good chunk of time from your team’s weekly sprint. These good problems could accumulate over time and decrease your teams’ velocity.

One way to solve this is to establish a support rota in your team. The rota can change every sprint, depending on your preference. Every sprint, there will be one person who will be on “support.” The intent is that this assigned support person will be responsible for acting as a cushion for the rest of the team. “Support” should prioritize the tasks mentioned above like BAU, answering inquiries from other groups, and triaging customer support tickets. Depending on the volume of support tasks, sprint tickets should be of secondary priority for whoever is assigned on support. Please note that this is different from the out of hours support responsibility; this is regular, working hour, 9 a.m.–5 p.m. daytime support. Though some duties like responding to alerts and pages may overlap, this does not require the assigned person to respond to incidents at 3 a.m.

By having someone to work on non-sprint tasks for your team primarily, empowers your team to focus on sprint work and minimize small tasks and distractions that could affect their ‘flow’ while working on sprint tasks.

I am happy to write more about this Support Rotation topic in detail in another post, please leave a comment or reach out to me if you feel that you’ll find it useful.

3. Working on an Epic: Best Practices

An Epic can either be a project, a new product or feature, or an initiative that will take weeks or months to complete. It typically involves stakeholders and collaborators from outside your team. Epics require commitment and leadership from the assigned engineer. Anyone who is assigned to lead an epic should have sufficient experience and skills to get the Epic to its completion; hence they are usually given to senior engineers or to those who are ready to take on one. Sometimes when Epics are not appropriately managed due to its complexity, it could cause miscommunication and misalignment within the team, which delays its execution. Other issues in the form of misinterpreted requirements or “scope creeping” also comes into play for poorly executed Epics.

To avoid the pitfalls mentioned above, your team has to agree on a set of best practices. These best practices should align with your organization’s standards to fit your team and wider group preferences.

Here are some examples of best practices that your team can adopt when working on an epic:

1. For any new epic, the product manager must conduct a “kickoff” session, setting the stage for the team, getting everyone ready for what’s ahead. The session also gives the team a chance to ask questions.
2. Create a temporary Slack channel for the epic. A Slack channel is essential, especially when you need to work across multiple teams and stakeholders. e.g., You can name your Slack channel like the following #tmp-< Epic or project name>.
3. Ensure that potential blockers are highlighted and addressed early.
4. Notify the stakeholders before the kickoff. Stakeholders can also help in identifying blockers mentioned in #2.
5. Create an engineering design document and conduct a design review.
6. Record all technical decisions made in a decision log.

The list could go on depending on your team’s situation. The point here is to agree on a set of best practices on how to work on an epic effectively.

4. Working on a Task or User Story: Best Practices

User stories and tasks make up an epic. A task or story is ideally achievable within a sprint, though we all know that’s not always the case. Sometimes a user story can spill over the next sprint if it’s poorly estimated, blocked, or took some time to execute. There are times when the assigned engineer spent too much time in isolation, fixing a problem without asking for help.

Even though a task is smaller than an epic, the delays in finishing it could accumulate and hinder the team’s progress, which could cause further delays to the overarching team’s goal or epic.

Here are some examples of best practices when working on a task:

1. Identify dependencies on other squads beforehand. For example, if you need to make a change to another squad’s code to finish your task, raise a Pull Request (PR), and be explicit that this is a dependency. Follow-up via Slack or instant messaging if the PR is taking longer than initially agreed or if there is no acknowledgment or reply.
2. Raise a draft/WIP pull request to get early feedback or start a discussion whenever necessary.
3. If you are stuck working on your task for 30 minutes, raise it to the team. Ask for help if anyone is available to have a pair or mob programming session with you, depending on the complexity of the task.
4. If your PR is taking too long to review from within the team, remind specific people via Slack.

• If you are a reviewer, ensure that you follow-up on your request for any change requests or PR comments.
• If you are a reviewer and won’t be around to follow-up (e.g., on annual leave), ensure that you notify the PR author and agree on what will be the next steps.

Some of the best practices above best complement your code review guidelines and coding practices.

Conclusion

By adhering to an agreed “Ways of Working,” the team will have a common understanding of what good looks like when working together. The team is held accountable to abide by the set of principles and guidelines that were collectively agreed on together.