Although organisations are getting better at understanding customer needs – while IT is getting more agile – they seem to be optimising the way they work in isolation, not together. Thus, creating a competitive edge requires new ways of thinking and doing. How can you get organised and lead people in a complex and rapidly changing business environment? In this article, we take you through the logic of working in cross-functional teams, and how to form and lead them effectively. Stop fighting, start collaborating!
IT vs Business – stop fighting, start collaborating
Complex problems in modern business development
Today’s business development deals with complex problems. The problem can’t be solved with a specific kind of know-how. You need many different talents to create viable and lasting impact on the organisation and its business. Complex business problems can be, for example:
What should we do in order to optimise our business with advanced analytics and automation? How does it impact our business, organisation, people, ways of working, or technology stack?
You are facing a complex problem if you can’t predict nor plan your way to a solution. The solution is revealed by a series of experiments.
- The problem may seem known, but there are many underlying assumptions, either known or unknown.
- Solution requires a multidisciplinary team. A single set of skills, background or education does not lead to the optimal solution.
- The key is learning how to approach the problem. It helps to start small and scale up from there.
When solving business problems, results should show up in customer behaviour
The complex problems you want to solve have been solved once you can see the impact of the solution. In other words: you can see the change your solution has created. You can witness the impact in customer behaviour, both as leading indicators (awareness or interest) and lagging indicators (contract signing, higher customer satisfaction, or passion to share a reference story).
A business problem starts with the customer, and ends with a change in customer behaviour. You might call this a value stream or a value network. The customer expects something, you deliver a solution to the customer, their behaviour changes, resulting in the business capturing the value (e.g. in terms of money). Read more about the customer lifetime value in Tero’s blog post.
A typical functional organisation doesn’t support the value stream
Now we have established the claim of an end-to-end value stream from customer demand to a customer demand that’s been met. Looking at a typical established corporation, its design is often functional. They have a sales function, a marketing function, a development function, an operations function, a support function, and so on. This design is from an era of Taylorism, optimised to solve the same repeated problem, like manufacturing one thing over and over again with maximised utilisation in mind.
Towards cross-functional teams
What’s the problem with functional organisation?
As stated above, modern problems are complex. They demand creative problem solving in a multidisciplinary setting. In practice, this means that organisational design should be based on multidisciplinary teams, or cross-functional teams, bringing together all the skills and functions that are needed to solve complex problems.
Sounds simple, but it rarely is. It’s not enough to set up a new team with one person from each function and call it cross-functional. They don’t know how to co-operate to solve the complex problems as a team, because their legacy is in the functional way of working.
We need new ways of working. And we need to lead that work effectively and efficiently.
Agile ways of working help solve business problems in cross-functional teams
What are these new ways of working? How do you start? The answer is agile methods and practices that are targeted to solve complex problems with cross-functional teams. While there’s no one-size-fits-all model or silver bullets, you don’t need to reinvent the wheel either.
Agile ways need to be applied to your organisational and business context.
Why is modern business development so challenging?
We’ve seen companies make big organisational changes for a couple of reasons:
- To keep up with the competition
- To prepare for a potentially challenging economic climate in the future
- To embrace data-driven business and digitalisation
These changes usually aim to improve collaboration between business and IT. This leads to silo cutting, cross-functional collaboration where different talents are flexibly used in different projects, and value streams. And we’ve seen these plans.
The real problem isn’t what to do, it’s how to do it.
And that’s what most companies struggle with.
When developing collaboration between business and IT, you need to consider and measure both specific business goals and strategic goals like becoming more data-driven.
For instance, a simple-sounding problem like “increasing sales of a commodity in a saturated market” or “creating a competitive edge by combining data from two business areas in order to optimise the running of both business areas”, calls for the following:
- Problem definition: business design, service design, end-customer understanding
- Solution hypothesis creation: service design
- Creation of a minimum viable product (MVP) to test those hypotheses: design, software development in the cloud, perhaps data science to create an initial algorithm
- Organising and creating a model for running the development work using agile methods
In short, usually the need for new solutions cross-cuts the existing organisational silos, requiring many different talents and know-how to land an optimal solution.
A successful execution also includes the proof of achieved impact, for example business, customer experience, or employee experience that is evidence-based.
To put it bluntly: business and IT need to find a common language, common business goals, and a common way of working.
And companies need to find the right measures for impact to guide the development work.
5 things you need to succeed in modern business development
1
High performing structures: cross-business units, cross-organisational, cross-functional.
2
A new organisational structure in action – from PowerPoints to practice.
3
Tackle business, design and technology aspects: desirability, feasibility and viability.
4
Lead the work with evidence-based impact measures.
5
Partners who can execute on a goal (not on a task level) and operate in a multidisciplinary structure, thus having the competence to help tackle difficult problems.
Towards a successful collaboration between business and IT
Business and IT need to find a common language, common business goals, and a common way of working in order to co-operate towards real and desired concrete impact. To achieve these ambitions, you need organisational level guidelines and principles combined with operational level methods and practises, targeted to solve complex problems in cross-functional teams.
WHAT to do: Organisational level guidelines
Your organisation will need two levels of guidelines to be able to determine what to do before moving into how to do it.
- Key concepts for agile portfolio management.
- Adaptation of lean startup and design thinking.
1. Key concepts for agile portfolio management
Most companies that implement agile miss a crucial step: connecting strategy with daily deliverables. In order to tackle daily challenges in the first place, they need to internalise key concepts for agile portfolio management aligned to company strategy. The portfolio layer is important, because without this piece, you and your company will be working on “stuff” instead of “strategic investments”.
Make sure your organisation internalises these key concepts for portfolio management:
- Portfolio items mapped to strategy. Hence, the portfolio is set to validate the chosen strategy.
- Evidence-based funding and rolling-wave forecasts instead of annual fixed budgets.
- Business case validation as part of portfolio, business outcomes as hypotheses.
- Balanced portfolio for different innovation horizons.
- Initiatives built around motivated individuals. Leaders give them the environment and support they need, and trust them to get the job done. People are organised to support continuous flow of value, either into value streams or networks.
- The best solutions emerge from self-organising teams that are led by a clear vision.
- Business, technology and design people must work together already on portfolio level.
- At regular intervals, the team working also on portfolio level reflects on how to become more effective, then fine-tunes and adjusts its behaviour accordingly.
2. Lean startup and design thinking
You also need lean startup and design thinking guidelines to make your team agile and to ensure you will get to the heart of the problems you are trying to solve.
Make sure your cross-functional teams have both internalised and are willing and ready to use these lean startup and design thinking guidelines in their daily work:
- Customer value = business value
- Work in short cycles
- Hold regular retrospectives
- Go and see instead of reporting
- Test high-risk assumptions
- Do less, more often
- Work as a balanced team
- Radical transparency
- Review incentives and performance management
- Make learning the first-class citizen of the backlog
That being said, we recommend agile programs to have an easy-to-remember shortlist of guiding principles. Here’s an example list used by one of our customer’s programs:
- Test high- risk assumptions first.
- Respond to change over following a plan.
- Embrace fast & decentralised decision making for incremental value delivery.
- Demonstrate and encourage others for radical transparency.
- Improve continuously your daily work.
HOW to do it: Operational level
Now you know the key principles to follow. Next, let’s take a look at how you should operationalise these principles.
Set the goal or vision state
In order to direct self-organising teams to solve the complex problems, they all need to have a clear vision and understanding of the impact the organisation is after.
Once you have formulated the vision, break it down to objectives that can be reflected iteratively and incrementally. Form the structures (team setup, division of labour, supporting organisations, dependency management) so that teams can work on deliverables end-to-end continuously without high coupling between the teams or other parties.
Because the teams are working on complex problems, it’s a good idea to have different planning and execution horizons to ensure the big picture and fast execution are aligned. Typically teams start with a plan of 8–12 weeks for the bigger picture, and then split that plan into 2–4- week sprint plans, which gradually get more accurate. This enables your organisation to validate the bigger plan in a few weeks’ batches, and reflect how realistic your big plan is in terms of investment, time-to-market, and so on.
Leading agile teams
One of the most common questions is: How should I behave as a leader towards agile teams? What are the responsibilities of steering or stakeholders? Which decisions should be made at which organisational level?
Luckily, pragmatic tools and practices exist to resolve these types of questions. One of the most common changes is to break down the typical monthly and weekly steering group meeting into two levels of support: fast ad-hoc, on-demand decision making by 1-x stakeholders who are capable and empowered to decide within themselves, plus the product owner in each team responding to issues raising about direction, objectives, priorities, asset and resources. A steering group meeting that takes place weekly or monthly is simply too slow to react to such an uncertain and complex environment.
There’ s no one-size-fits- all answer to empowering the team level to decision making. What is crucial, however, is that there’s clarity on this issue and, as said, tools to get to the level of clarity required.
We often help the product owners, steering groups, stakeholders, and any parties that are involved in creating clarity by playing delegation poker. The idea is to help leaders empower their teams with “+1 level of decision making power” compared to the starting point, and then gradually empower the teams further without granting too much responsibility to the teams, while ensuring the leaders get enough certainty to feel they are sufficiently in control.
One of the common patterns we see is that the teams and product owners think they are less empowered than they really are. This is due to a lack of clarity in the beginning. This exercise also helps the leaders understand how and when their decision making support is required by the teams.
Key responsibilities of any agile program leader:
1
Create and reinforce the structures to enable self-organisation. Setting the vision is one, clarifying empowerment another.
2
Help and coach the teams to resolve organisational impediments.
3
Go and see. Don’t wait for a report or rely only on reporting or status updates to gain awareness on where the program is at and how you could help.
Typical changes that will take place in an organisation transforming their ways of working towards agile, lean startup and design thinking
From project-based funding to value stream funding
‘Work moves towards the people’ instead of ‘People get organised around the work’
Traditional organisations are set up to get things done as projects. However, once the organisation starts building new services, businesses or products, they realise that in addition to establishing these services, businesses or products, they need to be continuously developed and optimised to create value for the customer and to react to market changes.
It’s costly and inefficient to reorganise teams every time a project starts, to allocate people, to get the project organisation operational, and so on, when in fact the customer remains the same, as does the underlying value stream. Once this is understood, the organisation starts moving into value stream-based funding rather than project based, and also begins moving work to the teams rather than moving teams and individuals to the work. Having said this, there are still a few occasions where projects make sense. It’s just important to acknowledge when that’s the case.
From project overload to demand management and WIP limits
When we take a look at the portfolios of traditional organisation, they are filled with projects which, on the portfolio level, seem to be ongoing forever. Digging deeper, we see that the organisation is filled with high over utilisation of people working in multiple projects at the same time, and even projects that only have a project manager, if anybody, struggling with resourcing.
It’s astonishing how a simple step to limit the work (the number of ongoing projects) in process can increase the throughput 2–10- fold in an organisation. It’s counter intuitive for many organisations to think that starting something later can actually help get it done faster. If you are curious about why, check out the This is Lean, Little’s law (yes, it’s scientifically proven).
From centralised control to decentralised control
We talked about empowerment, tools and practices to empower the teams. After doing all that, the following usually happens: decision making becomes less centralised, elevating the leaders to use more time on strategic thinking and giving them the detachment and clarity of distance. This means the ability to see situations more clearly when we are not close to them, in order to make better decisions.
From annual planning to rolling-wave planning
Many organisations are still working on annual planning cycles. These cycles are not necessarily unproductive, but if the organisation takes those plans as set in stone and neglects the possibility to embrace change in market conditions or deliverables, then these plans drive the behaviour, potentially leading to endless replanning. Single programs are requested to produce a plan that aligns itself to the target set in the beginning of the year – when everyone knew the least.
This is a wasteful process. Once the organisation realises that the annual cycle is purely an internal structure that needs to be validated by the shorter cycle execution and reflection on what is really happening, then the organisation starts to consider and implement rolling- wave planning elements: rolling-wave budgeting, forecasting, drip funding, retrospectives, plan/actual reviews, and iterative and incremental planning cycles.
From arbitrary milestones to evidence-based decision making
Milestones are not a bad practice – it’ s good to have clear objectives to reflect on continuously. However, milestones that are not informed by evidence are just schedule driven or purely conforming to some internal stage gate model. And those are pure waste. You should be reflecting your progress towards outcomes, not output. Towards impact rather than arbitrary process goals.
Validated learning is first-class citizen on your backlog
Uncertainty is your biggest enemy. How good are you de-risking your strategic decisions and validating if there’s a customer need for your thing, whether your solution is truly the preferred one, whether you can capture, create and change the market and find the optimal business model? And also adapt to any change that might occur in these? That’s essentially what you are trying to do.
Validated learning and the speed of learning becomes the main competitive advantage for any company. Your core process is not the business process you do today, but the process of how you identify, inspect and adapt your business to changes in the marketplace.
From project prioritisation to portfolio items with light weight business case, benefit analysis and prioritisation
Every organisation is working hard to prioritise their portfolio. One of the key activities is to do the validation as described earlier. That validation should be driven by the initial business analysis and reflected on the portfolio when making a decision to move forwards and allocate even bigger resources to the program. Prioritisation should be relative rather than absolute, as you can’t know how valuable something is until you have actually proven the value. Typical dimensions organisations use for prioritisation are: strategic fit, customer value, business value, complexity, and risk involved.
Case example: problem, solution and how-to
Let’s imagine you are starting up a new program that is given a priority from the portfolio. You have defined an initial business case and done some rough calculations and statements of what the benefit would be. You’ve formulated a vision statement of the impact you want to leave in the universe. You know you still have high uncertainty about the solution, and even though the problem on a high level is known, there are underlying unknowns in the problem definition. Where should you start?
The first step is to get together and break down the vision into more concrete objectives. A good practice is to set a timebox for the objectives, like 8–12 weeks, in order to have targets that are easy to track and within reach. We’ll call this timebox a program increment.
Once you have the objectives, you form the program into cross-functional teams. Each team should be able to work on an objective from end to end. Once you get to defining dependencies, you still might restructure the teams to avoid dependencies across the teams.
Cross-functional teams plan their 2–4- week sprints (two weeks is often preferred for faster feedback cycles and for learning and reflecting on how the teams and the whole program is doing) for the 8–12- week program increment. One of the key aspects of their planning is to define the most critical assumptions that need to be validated and prioritise those as part of their plan. Each team identifies the work that needs to be done for each sprint and also checks the risks and dependencies within.
One might question the value of these plans as they are not very trustworthy in the beginning of the program. It’s true that very few plans will survive contact with reality. However, there’s still value in planning as an activity. The teams will get together and get to know each other, people will connect and they will know who to call once the plans go south. The teams create shared objectives, common goals, and clarity on dependencies and priorities. All these are important when reality strikes and the program needs to inspect itself and adapt to reality – yet again.
Now the teams are ready to start working. They will have their internal sprint plannings/reviews and also program-level reviews and dependency checks. Product owners will have their corresponding steering group members to help them tackle ad-hoc issues when needed. After the program increment, the teams get together again and plan the next cycle with the data and information gathered from the previous cycle.
Radical transparency unfolds as every team demonstrates their progress towards the objectives every two weeks, while leaders demonstrate their leadership by providing support to tackle any raising issues and give feedback on the progress at all reviews.
Where to start?
We were forced to leave out a lot of details and descriptions of good practices to keep this text concise. All the more reason for you to be in contact with us or join our upcoming webinar on ‘How to succeed with cross-functional teams’. Give us a call or drop a line and let’s take it from there!
Solita is a digital data and customer value driven transformation company. We create culture, services and tech solutions that help us reinvent businesses and society for the better. Our services range from strategic consulting to service design, digital development, data, AI & analytics and managed cloud services. Established in 1996, Solita employs almost 1000 digital business specialists in Finland, Sweden, Denmark, Estonia, Belgium and Germany. We have created and helped cross-functional teams and championed agile ways of working for over 10 years. We help our customers to find out where they need to go and help them get there. We create impact that lasts.
