In our company, we experimented the last year with various setups of Cross-functional teams. These teams consist of members from different departments for a limited time to implement a specific goal. They do not have to be IT-focused, but coming from an IT background my experience is from being in and leading IT- and Product-focused teams.
If you are reading this setup guide, chances are high that you want to set up a new Cross-functional team. Awesome! This guide should give you a hand in where to start and what the main questions you and your team should discuss are.
What is the goal of the team? Most likely, it’s an implementation requiring close communication and high-level understanding of a specific domain.
When organizing the team, be clear what is expected of the team. The scope needs to be known by all in the team and by all external stakeholders.
In the first two weeks, bring it up often and repeat, so everyone can align on this. Repeat one time too often, rather than not enough.
Depending on how clear the goal is, it can be helpful to define a mission statement everyone can agree on. In discussions about the team’s direction, this can serve as a compass.
- What is the goal of the team?
- What are the must-haves and what are nice-to-have’s?
- Which deadlines exist?
- When does the team regularly end and how?
- Under which circumstances can the team end without reaching its goal?
- Can the goal be summarized with a generic mission statement?
- And lastly, the fun part: what’s the team name going to be?
When defining the scope, you will find topics that are core to the implementation and topics that are on the side — still on topic, but not required in the MVP. Identify those and put them on the side. It helps being aware of these topics and in discussions about scope, it is good to be able to point to this list to not get distracted. Over the course of the team’s existence, these topics may be revisited, as they gain more importance or as they become valuable as filler work in case the core functionality requires waiting periods.
- Where to draw the line between core goals and side topics?
- What freedom has the team in defining or redefining the scope?
Past cross-functional teams in my company have all tried to follow an agile approach, but it was up to each team to define what they meant by this. Some teams chose a structure like Scrum, others went for Kanban. If the team’s goal is well-defined with a deadline, even an approach similar to Waterfall is possible and can serve the purpose. Of course, hybrids can also be discussed. This can be interesting when it comes to communication and rituals. More on this later.
- Does the team want to work towards one big goal?
- What milestones can be identified?
- Can the work be broken into iterative steps?
- What steps depend upon each other?
The team was set up for reaching a goal and somebody is interested in the progress towards this goal. There may be multiple stakeholders that need to be kept in-the-loop:
- departments and their heads requesting the feature
- management or execs
- maybe a department is affected in case of success which is otherwise not involved over the term of the cross-functional team
Identify who needs to get what kind of updates and how frequently they should be updated. Schedule regular updates, so they don’t have to ask and can trust to get informed as the team moves ahead. This can be meetings, but — if agreed — updates by mail or other means may be fine as well.
If your IT developers have Sprint Reviews, ask to use this platform to inform a wide range of people about your updates.
- Who requires knowledge of the progress of the team? Which departments, heads, management members?
- How often should they be informed?
- In what format do they want the updates?
- Can the work presented in the IT Sprint-Review?
Whether the team is set up with one Tech Lead coordinating its strategy and implementation or with a flat hierarchy may be outside of the scope of the team. If this was not defined, it is up to the team to agree if they want to have a layered or flat hierarchy. In smaller teams, flat structures proved working fine.
One recommendation for teams with flat hierarchies is to define roles within the team. Roles may emerge automatically from the tasks, i.e. Developer and Project Manager. Even within a group of developers you will find small-scale responsibilities that are worth talking about in the team.
Either way the hierarchy is set up, the team should have one person who is the first contact for outside stakeholders. She should receive and distribute messages from and to the team. This does not mean, other team members are asked to not directly communicate to outside stakeholders, just that the team contact should be aware of the communication. Summaries are best practice.
The team can decide to assign one member to attend the stand-ups of the IT-Dev teams to be aware of their topics and identify when topics of both teams intersect. We are going to talk about the importance of retrospects below, organizing them could be another task for one team member. Another role could be somebody to remind updating tasks and tickets.
During the existence of the team it may happen that somebody goes on vacation. Remember to prepare handovers and assign replacement(s) for the roles in vacation.
- What is the hierarchical structure?
- Is there one Tech Lead or a flat structure?
- Who is the first contact in the team?
- Who organizes meetings like retrospectives?
- Is somebody interested in attending the Sprint Standup?
- Who is responsible for taking care the team keeps updating their todos and status?
- Does anyone have leave planned during the existence of the team?
Setup a Confluence/wiki page describeing who is in the team, what the goal is, and how you organize yourselves. Any decision the team makes about its structure can be noted there.
After the team is done, this page is also helpful for documenting how the team was set up and about the learnings of the speedboat.
- Who is responsible for taking care about the care setting up and updating the team’s Confluence page?
- What topic should be documented?
Be aware that different team members work on different schedules. People with Manager’s Schedule have their day split into many blocks due to meetings and context switches. People in Maker’s Schedule tend to have an empty calendar with long blocks working on one subject without distractions.
The team should discuss which regular meetings it deems useful.
Perform regular retrospectives within the team, to have a safe place where anyone can bring up a topic.
If your team lacks people experienced with facilitating this kinds of meetings, think about calling in outside help to get you started.
- What daily or weekly update meetings does the team want?
- How regular should retrospectives be scheduled?
- Who wants to facilitate the retrospectives?
- What meetings of the IT-Dev team does the team want to attend?
This topic very much depends on how the IT-Dev team and the cross-functional team are aligned on their goals.
The recommendation is to separate the codebase the team has to touch from the codebase the ongoing IT-Devs will work on. For the duration of the project your team may get temporary ownership of the codebase. The Dev-team may still do changes, but has to check-in with the team to ensure their changes don’t interfere.
Circumstances may demand both teams to work on the same codebase, which should be reflected in closer communication between the two teams. This includes talks about intentions (what does each team plan to do next) as well as review (reviewing each other’s contributions). Think about attending each other team’s standups, sprint plannings and inviting members of both teams to pull requests.
- Which applications are included in the project scope?
- Can the cross-functional team take ownership of these projects for the duration of the project?
- How should the two teams announce, review and publish their work when working on the same codebase?
In the last few sections many aspects of communication were already addressed. The experience with previous teams was that this is the topic that can cause the most friction within or outside the team and motivated this document in the first place.
Difficulties within the team can be around ticket status or their lack of updates. Depending on the structure, pair programming may be encouraged to share knowledge and help problem-solving. Mix the pairs frequently, if two strong programmers pair often, they may progress rapidly ahead of others, making it hard for the rest of the team to catch up.
Define with your team how to handle people working remotely.
Make it clear, who to report to in case of sick leave. At the very least HR needs to be informed, writing to other team members is a courtesy.
Summaries (for example in confluence) of what happened when team members were out due to vacation or sickness are generally appreciated.
- What are the expectations about announcements and visibility of Home office?
- Who takes care of writing a summary when members return from leave?
Ending the team
The nice things about temporary cross-functional is their limited length. You can specifically plan the teams deadlines and use the last week for cleanup, handovers and documentation.
Have one final retrospect about the term of the team — and make sure you have a nice party! Document the topics the team worked on and the lessons learned in your team’s Confluence page. Talk with the IT-Dev-team, as they are likely interested in a summary of the team’s experience.
Similar to the beginning, it is important to align with the stakeholders again. Have meetings with the relevant departments to present how the team’s goals were met.
The scope of these presentations depends on your audience. Most departments are fine with a higher level explanation, while the IT-team will appreciate technical details.
Evaluate if the cross-functional team was worth it — afterall it is an expensive approach and answering this questions helps to make the decision, to setup a new team, easier next time.
- Was everything done as expected?
- What might be missing?
- How do you deal with remaining side-topics?
- What changes had to be decided on?
- What departments should be informed about the results of the cross-functional team?
- What are the lessons learned (technical, data or process-wise, organizational)?
- How was the mood in the team?
- How did the other team feel with you gone?
- Was the team worth the effort?
Take everything I described here as a recommendation. The team you setup will be unique and is free to make their own choices. Feel free to come up with ideas that are not documented here.
Cross-functional teams are a great way of experimentation!