Working with a new Agile team

Starting a new team is always challenging. So many things have to be discussed and agreed upon as a group. People most likely just met each other, so they are in the very early forming stage and have a long way to go. They’ve got various backgrounds and skills. Also, they may be from different countries or have distinct cultures. Besides, some of them may have never worked in an Agile environment and need to be trained in this area. This is the time when the team needs help probably the most.

Here is the list of things a Scrum Master can do to assist the team in getting started:

Agile framework overview
I assume that by the time the team was formed, it was already agreed whether they are going to use Scrum, Kanban, Safe, Less, etc. As a Scrum Master, you should walk your team through the basics of the chosen framework and explain what the process is going to look like. You may be surprised, but Agile can mean different things to every person, so it’s essential to get things clarified. Sometimes discussing as simple topics as the purpose of Daily Scrum or Limit of WIP can uncover that people have divergent interpretations and perspectives. Also, it’s crucial to explain not just WHAT Agile is, but WHY and HOW it will help the team. For this reason, besides describing the process, make sure to go over Agile principles and values with your teams.

Workflow Process
It’s essential that a team agrees on a process to follow and what happens at each step. For example, team members need to discuss at what point code review occurs, who does testing, or what to do with a story that requires changes.
Research has shown that the easiest and most efficient way to reach this agreement is to create a visual board. Such a board will show all the steps that are necessary to move a story from being defined to getting accepted and merged. This tool also helps to get everyone on the same page, reduce miscommunication, and decide on possible WIP limits to minimize bottlenecks. Make the board accessible by everyone at any time. Consider using project management tools such as Jira, Rally, and so on.

Definition of Done (DoD)
DoD is a list of criteria every story has to satisfy to call it DONE. Having such a list helps understand what is expected from delivered items regardless of its owner, size, or blockers that a team may face during an iteration. There is no such thing as a partially completed story, which means all criteria have to be met unless it’s not applicable for a given work.

Ideally, DoD should include criteria that a team can meet on their own. Otherwise, your group’s commitments may often be dependent on others, which can make people frustrated and discouraged at some point; also, it will get quite challenging to plan work and track the team’s velocity.

Your team may also want to look into DoD for features because, at this level, you may need to follow additional criteria that are relevant to feature but not to stories underneath. In other words, even if all stories are done, the parent feature is not yet ready.
Here are some examples of extra conditions that a feature must meet to be accepted:
— UAT testing is performed by the client.
— Functionality was demonstrated on a system demo.

Getting your backlog ready
To start working and deliver value, a team needs to learn how to break requested requirements into smaller chunks of work — user stories. As a Scrum Master, you can coach the Product Owner and the rest of the group about techniques of splitting features and stories, so they meet DoR.

The entire team should be involved in this process, so both business and technical sides are well discussed and negotiated. If story splitting happens by the business person only, lots of architectural and logical design points can be missing, or development efforts can be duplicated. On the other hand, if only developers break the stories, most likely, they will turn out to be just tasks needed to implement the given work with no user value. As a result, due to the lack of conversation around what a user would do — the team will fail to discover many uncovered edge cases.

The next step would be to size the work. This helps teams to plan their capacity better, provide estimates to the customer, and support the PO with easier prioritizing of the backlog. The most commonly used sizing technique is Fibbonachi, but there are more. Pick the one which works best for your team.

Here are some resources that can help:

Team calendar
It’s always good to have a team calendar where everyone can see each other’s availability during an iteration. Quite often, managers are the only people who know an individual’s time off as they approve PTO. Having such a calendar gives excellent visibility when scheduling meetings, discussing risks related to the team’s availability, planning events, and so much more.

The calendar is especially valuable for remote teams in which team members can be in different time zones, locations, and can have various local public holidays.

Working agreement (Social Contract)
A working agreement allows teams to clarify expected behavior and signs of respect within a group. It helps to create an awareness of a shared understanding of good vs. not so good. Since it’s a mutual agreement, it can become a useful reference when someone is not following the rules. For example, the team may not feel comfortable speaking up when there is one person who is constantly late or dominates the conversations, but when it violates the agreement, it’s easier to bring it up.

There are many samples of such an agreement available on the internet; I encourage you to check them out.

Keeping the feedback loop open
Last but not least, is getting your team’s feedback. As a servant leader, you need to make sure that you help the team and do everything which allows them to get better. Don’t assume but rather ask what they think. Otherwise, you can always try to come up with some ideas to fix minor issues while overlooking major things your team needs the most.

Keep in mind that people are not always good at giving feedback, especially a constructive one, so I would recommend doing it anonymously.

Good luck with your new team!

Related posts:

In sadness to what is happening around the world from COVID to Racism. I poured my mind on canvas. A time comes when silence is betrayal. No man is free until all men are free. No Child was born a…