"Where do you start when forming a new agile team?" + 7 answers of our Agile Coaches #AgileSeven

We asked our Agile Coaches:

"Where do you start when forming a new agile team?"

And they answered:

Christian:
There are countless ways to do that, but generally speaking, I think the two most important things are: 1. The team needs to get to know and trust each other. 2. The team needs to understand and align on their purpose and hard as well as soft goals. One way to tackle both that I have tried a couple of times is working on a Team Charter in the very first week. This goes all the way from values and work practices to “Where do we want to be in 3 months?” and “How do we know we’re in trouble?“.

Norman:
As with most things in agile, I think we should start with the user and the problem we’re trying to solve for them. Having a solid understanding of the problem we want to solve enables us to identify a route toward a viable solution. In turn, having a general idea of the solution enables us to identify the skills and expertise necessary to get there. This is where we can start to select the right people for the job. To ensure that the team stays on track, however, there should be at least one agile team member that knows the vision of the product and is able to convey and ensure it during the whole development process. A “lighthouse” that the rest of the team can look for guidance, so to speak. Along the way, the team should also be enabled to grow a healthy team spirit and become more effective along the way. A servant leader like i.e. a Scrum Master could help with that.

Marija:
Ideally, one would let the team form itself - people from a group join freely and maybe even pick additional members, in a self-organized manner. This can work nicely for scaled setups when multiple teams form simultaneously. Mutual understanding of what agile means (how the organization and extended team describe it) is a must from day one, as well as clearness (transparency) on what is expected from the team. It is also essential to give the team a chance to get to know each other, not only through a kick-off or team building but by letting them work a lot with each other and not only next to each other (in software development pair programming, mob programming, peer review, and technical knowledge transfer sessions come to mind).

Eva:
What worked out for me in the past was doing a survey about their skills and knowledge about agile teams. Based on the results I sometimes do a workshop, working session, and feedback meeting on agile basics in theory and ask them how they want to live it in reality. In addition to that, I prefer getting to know the persons in the team by doing a team meeting or 1:1 meetings to clarify clearly the teams and individual expectations about how to work together as a team in the future (team rules, team setup, ways of communication). What really helps: Don’t start to implement everything at once. Be transparent and go with tiny experiments for the team. Inspect and adapt what works out and how to improve.

Amir:
The best way to start with an agile team is to have a cup of coffee. Have that water cooler moment, and chat with each other. Find each other's likes and dislikes, and talk culture. Throw in a few moments of fun before the seriousness. Make a bingo out of it. Familiarity breeds trust and comfort, people will start acting like a team when they spend time as a team. Even online, this can be done. Do an online Pictionary game! Maybe not Monopoly because that is sure to create some fights. :)
The second part should definitely be a serious talk about what we should do when we have a problem, have agreements. Spoken or written down, depending on what the Team wants. When there's a spillover, when there's tension between two people, when somebody leaves the team, in case the product drastically changes. Have the talks nobody wants to talk about. The most important part here is that everybody is heard, even if all do not agree, that opinions are given and sentiments expressed before the work starts. Don't call them rules, call them agreements, because we all AGREE.
From there, every Sprint, the inspect and adapt will go smoother. And you should have a lot of transparency because there is trust.

Mirjana:
Any talk about business, agreements, and setting up meetings needs to start with people getting to know each other. Let them work together for some time and adjust. Let them share and build trust. Let them create goals they can work towards as a team. Somebody should keep track of inspection and adaptation (not necessarily by implementing a method right away, but by finding what best suits the team by talking with them 1on1 and in group settings). Workshops, short team building sessions, and lean coffee breaks to express issues can be extremely insightful for this purpose. Any changes should come in small chunks so they can be verified and/or adjusted. This might be done by a Scrum Master/Agile Coach/Squad Coach… If there is no such person, the team needs to settle this point: who will keep track? Document meetings if needed? Will the members switch the “Scrum Master” hat every few weeks? The developers should be open-minded about trying new things, and listening to each other. Why not have a get-to-know activity at the beginning of the meeting? Why not have an ad hoc coffee break during the afternoon? Why not play an online game together? Those are small moments that, especially in teams that work remotely, can change the game. To sum it up - you have to be brave to try something new, fail, dust yourself off and try again. Experiment with the process and ask a lot of questions.

Marco:
There is no team without a product. Try to understand where we are and what is our goal. To be more specific: What is the product for? Who are the users and what problem should solve the product? Do we have a product goal? Do we have the most needed skills in our team or do we need more or other people? Why should we develop the product in an agile way and not with the classical plan-driven approach? Do we want to use Scrum as framework or another framework? Do we have the same understanding of it? And last but not least: (play music) Let’s build the team on rock’n roll. Do some team-building workshops as a start-up.