Dare the impossible: Cross-functional teams with end to end ownership

This is a write up of some exciting and astonishing discussions experienced in the Meetup “Dare the impossible: Cross-functional teams with end to end ownership” of the Agile Munich group on Thursday, Sept 21st 2017, hosted by HolidayCheck Group AG.

Topic:

“Teams owning the full value chain are not a fairy tale! kartenmacherei, Gini and it-agile are three companies who dared to embark on that journey. They are transforming functional verticals into true agile teams. These “cells” or “squads” are not only containing product management and development but team members from up to 9 former functions.

Why and how can breaking organizational structures make sense? Use this evening to grill 3 coaches. Their insights can help you to create your own experiments so that your team gets to enjoy the benefits of “x-functional all in” first hand.”

Format:

After a quick introduction of the three coaches and their philosophies, the audience has been asked to pair and come up with one question to set a list of topics for the evening. Setting up time box of ten minutes, the experts were asked to respond to one question after the other and discuss their views and experiences with all participants. The result were lively discussions about a wide variety of topics related to cross-functional teams, often with a direct link into existing challenges – down to ground and very engaging.

Coaches:

Anna Lorenz /it-agile – an agency of agile coaches with an organization structure, which is avoiding any kind of hierarchies and is rigidly following agile principles

Tina Dreimann /kartenmacherei – producing cards for any kind of events, working with x-functional teams, from web presence to printing

Manuel Küblböck /Gini – real-time information extraction from documents, working consequently with cross-functional teams, which encompasses the full ranges inclduing sales, marketing, development, and operations

How to make sure not to overload x-functional teams?

When working with x-functional teams, presumably not all functions will be required to the same extend all the time. The work in teams might not be balanced, so people cannot be kept busy to the same extend all the time. The assumption is, that this is creating a lot of inefficiencies.

Teams will pull their work (work will not be not push). Thereby the teams are responsible when to pull new items and which items can be pulled, which ensures a good coverage in the team.

In case there are no tasks for specific functions available at all, teams are free to send some of their members to other teams, where this function is present.

The functions are rather coarse grained to foster the exchange (we heard about 7-17 functions), while details are addressed by support of more versatile skillsets.

A central team (focus team) can help to coordinate topics in a way that functions will not become obsolete for a longer period of time.

What kind of metrics work for x-functional teams?

Typical development metrics will not work in x-functional teams, as they will not affect everyone. Still we need to measure the progress and success of teams to drive improvements. But this will require other metrics than the traditional ones.

Pass business metrics to the team. With an end to end responsibility teams will work as small business units and can be measured the same way. In the end this is also the reasoning to split team by business value.

Besides that metrics for measuring and fostering the health of a team become even more relevant. Collaboration across x-functional boundaries requires more knowledge exchange.

special mentioning: Workplace by Facebook has been agreed to be a reasonable tool to foster socializing in x-functional teams

How to avoid too many functions in team?

If you like to have a x-functional team, which covers all aspects of an end to end responsibility, and even want to ensure that there is a backup for every function, so you will not get stuck, this team would presumably exceed the size of a typical agile team of ten to twelve people maximum.

You should start and act like a startup. Accept that not all functions will be equally present from the beginning. Pressure from missing expertise has to be accepted. Gradually you will find your way towards a setup that works for you.

When working with multiple teams, chapter days are a great tool for overcoming a lack of expertise. These are specific times (e.g. 1 of 5 workdays), where people meet to work on the big picture rather than the specific tasks in a team. Expertise, which is present in one team only, thereby can be shared. Other teams can take benefit from it without the need to grow that function in their team.

What are boundaries in team responsibilities?

Being part of a bigger organization, there must be boundaries in responsibility for each of the teams. There would be no reasoning for the organization anymore, if they would act 100% autonomously.

Create transparency on the P&L. Every team needs to know how they are contributing to it. This gives them the responsibility to act in the sense of the full organization. Dependency and misses become obvious. (in this context we had some discussions on the use of social pressure as an instrument; I skipped this here as it did not add to the solutions itself)

Working with transparency brings its own boundaries with it, which is consider to always work better than some organizational boundaries or processes. Thereby the boundaries are

Another instrument mentioned in this context, was the use of public reviews. Objective must be to make audience happy, which could be the whole organization. Ignorance of common objectives would fail in such a review.

How to manage agile transformation in a federal office?

Working for a German federal office, which is managed in avery bureaucatic way, agile tranformation towards x-functional teams with end to end responsibility seem to be unrealistic. Anyhow, there need to be ways to get it started.

Identify the interfaces to other teams. Find out how they affect you and what could be reasonable approaches to interact with them. Consider where you can converge into agile methods and where not.

Talk to the people how to improve. The setup will have to evolve based on common understanding and general possibilities.

Above of all, avoid to be the bad guy. You should ask “how to support?” rather than tell “what to expect!”.

Finally do not forget to celebrate success. When others are recognizing that things are moving on, they are more likely to contribute.

How to hide slicing of vision across multiple teams from the user?

Manuel Küblböck was telling in his introduction, that the vision at Gini is sliced into smaller pieces and implemented by individual teams. One could wonder, if it would be possible to maintain a common vision towards the user if the vision is sliced this way.

One should always consider the importance of uniformity. The possibility to keep uniformity to a minimum, which works for the user, will significantly reduce the efforts to hide the slicing of a vision.

Alignment across team can be organized in chapter teams, which are solely responsible for maintaining a consistent story or simply from chapter days, where teams exchange and align on commonalities.

For the sake of standards it also pays off to ensure high quality within teams, which falls back to an align vision.

What is the recommendation to setup remote teams?

Setting up x-functional team in a on-site locations seems to be a challenge already. In a setup with remote colleagues this seems to be almost impossible.

Bring the people together (need to know how to work together). Irrespective if they are working remote, meeting in person creates a different experience and will change the way people collaborate, even if they depart afterwards and work remotely afterwards.

Use any kind of tech you can think of to ensure they can work together easily.

Preferably the team has an own budget for travel costs, so they can decide on their own, whom and when to travel depending on their current needs.

How to ensure quality and discipline?

When maintaining various different functions in a team it will be come difficult for team members to judge on quality and discipline across the various functions. Anyhow, there must be ways to get hold of it.

Prime tool is pairing. Having couples working on the same thing automatically enforces discipline and quality. Whenever possible you even should try to pair across teams.

Furthermore you should ensure seniority in teams. It encompasses not only technical savy, but also seniority on the interpersonal aspects. People who know how to collaborate and communicate contribute a lot to the aspiration as such.

What is the recommendation for x-functional teams exceeding the size of agile standards?

If you like to have a x-functional team, which covers all aspects of an end to end responsibility, and even want to ensure that there is a backup for every function, so you will not get stuck, this team would presumably exceed the size of a typical agile team of ten to twelve people maximum.

For teams, which are exceeding an affordable size, a viable way can be to determine functions, which can be isolated without affecting the process, and outsorce them to freelancers.

In general it will be important to work towards t-shape profiles, so people are capable of contributing to many functions. You should not look for perfection, but for a bearable coverage.

If all of this does not help, you will not come around to somehow split teams. Whenever necessary you can think of maintaining a central team for alignment and to split out “subteams” for more specific aspects.

If you question the autonomy of the individual teams, consider that not every team has to do everything. Specific functions might fall short in the one or the other team, which can be compensated by the organization.

special mentioning: Nils Pfläging – BetaCodex Network – e.g. Video: Future of Work, Leadership, and Value Creation

How to setup x-functional teams in regulated environments?

X-functional teams would suffer even more from constraints in regulated environments, like rules to follow specific release cycles or the need to maintain an extensive documentation.

Preferable the regulations are also managed in the team. The team will have the power to determine how to address specific needs accordingly.

CMMI Level 5, which is to be considered in the context of related environments, somehow enforces agility by itself as you are asked to adjust your processes continuously.

Especially on CMMI in combination with Agile you can find many articles in the internet (search).

What has been your way of working before agile and how did you convince the organization to change?

We have heard a lot about how the work with x-functional teams are “managed” by the coaches. But there must have been a start, where the organization had to be convinced as such.

[not much has been told about the way of working before agile…]

You should start with small cells. Convincing the whole organization at once might become too ambitious. Experiences and success from small cells will help you to grow the agile organization.

You probably should avoid to mention agile – there are negative perceptions of agile as well. Start by talking about optimization of costs, speed of development, and efficiency of working with service providers. If you follow up on this you will end up with an agile setup anyhow.

How did x-functional teams fly for you?

There must be a moment when you realized that you are on the right path.

Don’t expect it to be easy. It is a long, hard way 😉 Especially in the beginning it requires a lot of alignment. Expect thing to slow down thereby.

There is a huge relief from the start by then. Teams are keen to run the new setup, as it gives much more autonomy to them.

This is also one of the reasons why it is becoming chaotic. For three to six months you need to except that things need to settle.

Then things start to fly. Important is to stick to it and don’t loose faith. Never drop the ball and the moment will come where it flies.