Why the need for this guide?

Synergetic cross-functional teams (XFT) contribute greatly to the success of a program. Benefits of a cross-functional team include increased innovation and efficiency through different skill sets and expertise.

However, managing teams from various departments and specialisation require close coordination and orchestration of resources to ensure that the outputs from one team transit smoothly to the other.

The top three challenges I usually face when managing XFTs are:

1. The breaking down and accountability of tasks that can be handed over from one team to another easily
2. Alignment of the timeline across the various team setups such that there would be a synergetic flow and momentum
3. Establishing a system that can handle changing requirements from users quickly and effectively to deliver value

This guide is meant to provide you with a reference implementation approach that is built upon some of the principles of the Scaled Agile Framework (SAFe) – an effective framework for program management – to address the above challenges.

The implementation approach that I adopt follows the high-level delivery plan involving cross-functional agile teams shown in the sample below.

This delivery plan was designed based on three key principles to ensure program success:

1. Deliver value quickly with integrated learning cycles
2. Constant evaluation of solution against KPIs at various milestones
3. Tailor to the teams’ structure and technology landscape

Managing a program involves a high amount of coordination. Often, the use of a collaboration tool is recommended to facilitate the tracking of tasks and work items across teams and projects. In my case, I use JIRA as a collaboration tool.

What is JIRA?

Enterprise tools like JIRA are often used as a central platform to bring the teams together to collaborate on projects.

JIRA comes together with many components that serve different project needs. I will not be covering all aspects of the tool; the focus will be on leveraging the tool for effective coordination across the various teams.

The components of the tool which I will be covering in this article are:

• Project boards that serve as boundaries across various projects
• Sprint boards that track and display the workflow and status of issues
• Product backlog that contains the list of stories and issues to be addressed
• Workflows that route issues from one party to another
• Reports that facilitate effective planning of subsequent sprints

Managing an XFT requires these components to be slightly configured to improve the clarity and accountability of the deliverables. For simplicity, the examples provided will be based on the assumption of a single project. The same setup can be applied for multiple projects with minimal changes.

How are the components configured to suit an XFT?

For each of the above-mentioned component, I will provide an example of the configurations incorporated to make my coordination of the various teams easier.

#1: Project boards

Each of the team has their own project boards where they only view information that is relevant to them.

Custom team views are achieved through the use of filters. The filters (JQL) are based on the labels of each story, which serves like hashtags. Some examples are UX_DESIGN, APP_DESIGN, etc., which are an indication of the design and architecture teams responsibility respectively.

Once a team has completed their tasks, the labels in the story/issue will be updated accordingly and it’ll disappear from their board.

#2: Sprint boards

Teams have their individual sprint boards which are divided into columns that correspond to their related workflows. A column can contain stories/issues that are in multiple workflow statuses.

A delivery team can consider adopting the following column names for their board:

1. Sprint backlog — additional stories to be delivered if possible, which includes enhancements from feedback from user study sessions placed by the product owner; can only be swapped with stories in “To-do”
2. To-do — stories from the product backlog that have been prioritised for delivery in the current sprint based on the team’s velocity to be reviewed by the lead engineer or business analyst
3. In-design — stories undergoing design by designers and architects
4. In-development — stories undergoing development by engineers
5. Development complete — completed stories to be reviewed for governance purposes, e.g. code quality by lead engineers
6. In-UAT — stories which are deployed into testing environments to be assessed by product owner and users
7. Ready for deployment — stories which have been reviewed, tested, and approved to be deployed into the production environment by the DevOps engineer

The sprint board allows you to get a sense of the overall status of the teams’ progress at a single glance based on the number of items in each column. Boards are usually updated and reviewed on a daily basis.

#3: Product backlog

Stories and issues in the product backlog are handed over across the various teams through the use of labels, filters, and workflows.

Each story follows a strict set of guidelines to ensure that sufficient information is provided to the respective parties to act on with minimal friction. Some of the underlying principles adopted include:

• Independence – minimal dependencies with other stories so that features can be shipped and tested quickly (in parallel) and impact to other features are reduced
• Consistency – stories, bugs, tests, follow a consistent format and structure to provide information to assignees working on the item
• Modularity – manageable workload to deliver value incrementally for ease of workload distribution while addressing changes easily with swapping out of various minor components rather than making large changes, which provides flexibility

You may also refer to guides that provide more information on crafting useful user stories in JIRA for Agile projects.

#4: Workflows

Workflows are customized for stories/issues to be routed to the respective teams based on the statuses for further action.

An example of a workflow for a story in an XFT can be:

1. BACKLOG
2. TODO_DESIGN
3. IN_DESIGN
4. DESIGN_COMPLETE
5. TODO_APPDESIGN
6. IN_APPDESIGN
7. APPDESIGN_COMPLETE
8. TODO_DEV
9. IN_DEV
10. DEV_COMPLETE
11. TODO_SIT
12. … DEPLOY_COMPLETE… DONE

The implementation workflows promote accountability of tasks and governance through reviews and approvals across teams.

#5: Reports

Velocity charts are used in sprint retrospectives to optimise resource allocation and workload for the subsequent sprints across the teams.

The chart shows the velocity of a team in the form of story points completed. Each team would have their own velocity based on the strengths of the team.

You can use the information to balance the workload across the teams by adjusting story points in the subsequent sprints to match their capacity.

What are the benefits?

I have found the approach useful in coordinating XFTs with more than ten members. The main benefits are:

• Efficiency: Teams are working in parallel with minimal dependencies from each other – which brings flexibility in schedules and deliverables
• Accountability: Issues transition from one party to another via a clear indication of action items and assignees; which can be easily tracked via the sprint boards
• Governance: An additional team can easily be onboarded to adopt a similar system and structure – which brings scalability

The benefits allow your project to move quickly while addressing changing requirements by scaling resources or reassigning deliverables.

What are the potential pitfalls?

While there are various Agile frameworks and methodologies out there, one should take caution when adopting them into your organisation; because akin to parenting, each child is different.

Here are some considerations:

• Technology and process maturity: failing to factor in legacy infrastructure, systems, and processes could eventually affect processes, e.g. Sprint cycles, DevOps, remote access, etc., and thus delivery timeline
• Organisational structure: team size and setup vary across organisations, which is likely to affect the project team’s structure and communications especially when time zones and multiple stakeholder interests are involved across departments – leading to an increased emphasis on communications and sales skills to get things moving
• Program scale and complexity: not having the relevant expertise and support resources to execute the project plan can lead to increased risk and costs to the organisation

There is no one-size-fits-all approach to managing XFTs. I hope that this article is useful for you as a reference to manage your digital program.