Creating agile teams

Creating agile teams within the organisation’s ecosystem

juli 11th, 2018 Posted by change processes, HRM, leadership, management No Comment yet

Last week, I wrote about how a more agile ecosystem can be created within the organisation from the workforce perspective. The article briefly discussed how classic constructs need to change on various levels – on a technical, team, leadership and personal development level- to become agile and only scratched the surface of each of these topics.

This article will zoom in on the creation of a dynamic team structure within the organisation. While last week I wrote about “what” is needed to become more agile as an organisation from a workforce perspective, this article focuses on “how” organisations can ready themselves for this new way of working.

Create a leadership team

Any sizeable transition takes time, dedication, guidance, empathy, a solid strategy and a 360-degree perspective created with the ability to let go off “the way we have always done things around here”. Therefore, you can’t go without a strong leadership team during the progression towards an agile ecosystem.

Not everyone is suited to lead the organisation during transformation periods and you will need to select your strongest change agents who are known for both their strategic and creative thinking, their flexibility and their ability to mobilize their internal network. This cross-functional team will be responsible for applying agile values, principles and practices within the organisation. They are among the first that will walk the proverbial talk, personifying the agile approach.

The first team member to select is someone who will own the initiative, who will facilitate the team sessions and who is going to coach the other team members to ensure that everyone stays actively engaged, let’s call him or her the team captain. Important to emphasize is that I deliberately refrained from giving this role any form of ultimate responsibility. Every single member of the leadership team is individually accountable for the actual outcomes as team decisions are made through sociocracy.

The ideal size of your team depends on the complexity of the organisation as a whole. Anywhere between 5 and 8 members will generally create the optimal team dynamics. Core functions that are often included in the leadership team because of their knowledge are Operations, IT/Technology, Finance, HR, Customer Relations, R&D (preferably a solution architect), Risk Management and Internal Communications.

When you have assembled your team, make sure to facilitate the team’s start-up in order to create the right work structure. Here are some topics the leadership team should explore with you:

  • Why have you selected them [1]? What drives everyone to be on this team?
  • Why is that important to them?
  • Is there a sense of urgency, what are the issues the organisation faces?
  • What are the expectations of the initiator/client?
  • What does success for this team look like?
  • Define the group’s main goals and determine how the challenges can be broken down (create a backlog)
  • What is the team going to do and just as important: what not?
  • What are the interests that the team should protect and preserve?
  • What types of agile approaches could the team test[2]?
  • What is the mandate of the team?
  • What is the desired culture within the team?
  • What are the team’s KPI’s?
  • How can every member contribute to drive results?
  • What are the risks, what can the team expect and how will the team deal with friction[3]?
  • How can the team identify and remove barriers within the organisation?
  • Does the team need any other partners to reach their goals? Is the team well-rounded and complete? Which external partners will the team need along the way?
  • Who are possible catalysts of change within the organisation? And who are expected to be the frontrunners?
  • How will the team continuously engage these influencers? [4]
  • How can the organisation help every employee to deliver their best results?
  • How will the team create a pull from within the organisation?
  • Is everyone committed to the project? Does everyone truly believe in the project?

Determine where agile teams could benefit operations

Truth is, although we could focus on an entirely agile approach, it is up to each organisation to determine just how agile one needs to be. While hierarchical frameworks are complex, outdated and are often used inconsistently, there are still some departments and industries in which the need for in-depth specialisation can outweigh the need for fluid mobility and agile methods aren’t always best suited for routine activities. So be careful not to change for the sake of change alone and look for the right mix of traditional and agile structures.

Agile teams are most effective in situations where problems are complex, when there are no clear solutions yet, when requirements are likely to change, when creation in close collaboration with end users is sensible and creativity is needed.

It is advisable to create a taxonomy of opportunities using a modular approach because this encourages the organisation to explore possibilities, it enables the organisation to break down the opportunities in smaller steps, it clarifies how the organisation can engage the right people with a job that fits their talent and it aligns structure with customer behaviours[5]. Start by dividing the taxonomy into three different components:

  1. CX (Customer Experience) – to identify all experiences the customer has with your brand that affects their decision-making and satisfaction;
  2. BP (Business Process) – to examine the relationship among these experiences and business processes; and
  3. TS (Technology Systems) – to deliver technology systems to improve processes and experiences.

Within larger organisations, leadership teams can expect to identify as many as a 1000 potential experience teams alone. Next, look for possibilities to integrate components to increase collaboration and reduce overlapping responsibilities. [6]

Set priorities for the teams and align them with the limitations of your organisation

As soon as the leadership team has created the necessary taxonomy, they can start setting priorities and sequencing initiatives to prevent change saturation and putting to much pressure on the organisation’s capital by depleting capabilities. Stating the obvious, it is highly advisable to start with initiatives with the most potential in value and knowledge (learning curve).

Consider using the following criteria:

  • Strategic importance
  • Availability of resources (budget, people, tools, knowledge)
  • Risk Levels
  • Interdependencies

Highly customer-centric segments are ideal to test and refine your approach during the start-up phase. Teach these teams to use agile practices of choice, based primarily on Scrum, Kanban, and Extreme Programming (XP)

Restructure the job architecture

An important step towards building a sustainable team-oriented job system within the organisation is analysing your current architecture and restructuring the architecture in such a way that it will be easier to deploy your resources in a project-based manner. This way, your new architecture will function as the backbone of your entire HR structure and supports the dynamic job system.

Step 1: Analyse the construct of your current system and library (including job families and levels)

Step 2: Determine what your job architecture should look like based on current and future needs with robust leveling criteria -including a broadband pay structure- and with clearly defined responsibilities, scopes and expectations.

Step 3: Map dynamic career paths and define career development trajectories and measures that are aligned with the organisational needs and goals. Make sure that the architecture in itself is flexible enough to continuously develop and adapt itself.

Step 4: Create a new library with a cross-functional emphasis -and fewer titles- to make it easier to differentiate roles. Label your workforce based on knowledge, skills and try to incorporate the internal network ecosystem (based on your ONA) and your new team taxonomy.

Step 5: Determine how employees will have visibility into their development options and possible growth trajectories with a clear outline of the requirements. Design a consistent review process.

Step 6: Create a change management plan which is focused on communicating the new criteria and expectations through various platforms, giving your workforce a sense of direction and educating management and employees.

Step 7: Determine how to measure the architecture’s success and audit the construct at least every quarter -but preferably real-time-.

Step 8: Restructure and finally migrate your entire job architecture in order to create one globally-consistent version.

Decide on team set-up

When the landscape is clearly defined by the leadership team, it is time to construe other teams.

A delivery team normally consists of a Product Owner, who manages the team backlog and sets priorities based on the input of the Product Management team. A Scrum Master who facilitates the team towards its delivery objectives and makes sure the team performs well (coach) and finally, several team members who work hard to realise the deliverables. Teams apply Lean UX feature development and Built-In Quality practices to drive disciplined development and quality.

In most organisational structures, the Product Owner reports to a specific Business Owner who has the primary business and technical responsibility for fitness for use, governance, and ROI for a solution. While specialists, like mobile developers, report to Technical Managers who are responsible for managing one or two specific disciplines within the organisation. Due to this construct, these technical managers have direct reports in various teams.

Often, individual team members are enabled to switch teams every few years to further develop and diversify their own skill set. This construct gives them the opportunity to shift their focus or actively choose to remain in their position, which will possitively affect their engagement level. Team members can also change teams between these intervals if there is a clear shift in the long-term needs of their team.

Some teams dissolve because their mission is no longer valid. It is also likely that organisations will form teams that focus on short-term projects who will dissolve after completion. Whatever the lifespan or reason for dissolving the team, always celebrate the lessons learned from projects to both encourage and uphold an open and constructive team culture.

There are various points to consider when building team structures:

  • When a team is too small, specialisms that are crucial to realising the team’s mission are missing within the team. This creates a very high dependency on external resources with the likelihood of underperforming or delivering incomplete work.
  • Teams that are too big will break into sub-teams and fracture, often productivity decreases due to group politics and a larger focus on the individual.
  • Team members that are assigned to multiple teams are affected by conflicting goals and priorities.
  • Teams that don’t own the technology they work on, don’t always know how changes impact the software or structure and thus other teams. Organisations should create enough safety measures to ensure that other teams aren’t affected when multiple teams work on the same software[7].
  • Without a known backlog, teams will be unable to measure their team velocity correctly. This would make it difficult to assess the team’s progress and stability.
  • What are the boundaries for each team? What types of decisions can these teams make by themselves (don’t forget that the goal is to realise autonomy) and what type of decisions need to be made higher-up?
  • The work of a Product Owner is deeply connected to the work of other teams. Therefore, organisations normally construct Product Management teams to create the overarching Programme Backlog. This enables the Product Owners to create a more rounded Solutions backlog.
  • Personal interaction has a positive effect on team productivity since it encourages focus and strengthens a team’s mentality. But more importantly, personal connections that are formed stimulate a state of psychological safety. Therefore, it is often unwise to create teams unable to come together physically for long-term missions.

Enable fast decision-making and autonomy for your teams

You can have an agile all-star team in place but if the system in which they work is filled with bureaucracy -based on command and control-, they won’t deliver as you would expect them to. Team members will hit walls, get tangled in power plays and eventually lose their engagement. Therefore, it is paramount to enable them to be self-governing. This means that a team shouldn’t have to plough through layers of approval and control but can rely on an actively supported -and clearly communicated- agile workflow.

When the organisation has the desire to scale up its teams, the leadership team has to focus on instilling the agile values and principles throughout the entire ecosystem and addressing any impediments. More often than not, efforts of the leadership team are completely focused on the employees that are directly affected by the transition while employees who are not (yet) organised into agile teams are overlooked. Leaders should make sure that the agile process is embedded through clear communications, a supportive culture, servant leadership, integrated workstreams and guided by instilling clear decision rights. Otherwise, organisations are at high risk that bureaucratic functions will refuse to adopt innovations.

In order to create a productive flow from the inside out, in which every team member is and -more importantly- feels accountable for the work they produce, scrum masters need to have the tools to create a culture that is built around shared responsibility. Teams should own their work and feel responsible for continuous exploration, integration and release on demand. One way to create this sense of shared responsibility and autonomy is to let teams define their own measurement systems for measuring the performance of their team and individual team members.

Provide access to your teams

For agile teams to be able to adapt quickly to changing conditions in the market, they need direct and continuous access to internal and external customers and the ability to work with tight feedback loops. This will enable the team to come up with real-time responses to customer feedback.

Subsequently, the team needs to be provided with a toolkit that enables rapid prototyping, thus offering the possibility to reduce the time to market.

Maximise the learning experience for your employees

If your agile teams perform well, they will be disruptive. And, as with any change, employees will produce all kinds of antibodies that attack the transformational process, ranging from refusals to operate on an agile timetable to the withholding of funds from big opportunities that require unfamiliar solutions.

That is why so many companies create -partly- disconnected incubators that enable teams to work around most internal obstacles. While this approach really does work, it is a short-term solution for a strategic issue that needs to be addressed if you truly want to function as an agile organisation in the future. It is much like placing a bucket under a leaking sink, while it prevents damage to your house, the solution focusses on the consequence and doesn’t resolve the cause.

Agile transitions are about experimenting, learning, testing, and improving the ecosystem in which the teams will operate. This can only happen when the working conditions are realistic and as diverse as they are in real life.

To create a better learning experience for everyone in the ecosystem, organise weekly team presentations in order to help teams share their insights and best practices with other teams. Also, enable and encourage in-depth specialists to organise workshops for other employees. Lastly, create a flexible and central learning system in which knowledge sharing (communities of practice), open-learning, a sense of mutual mentorship and feedback are available and fully integrated into everyone’s day-to-day operations.

Gather data on team efficiency

The leadership team is only able to weigh the need of increasing agility against expected costs accurately when they have sufficient data about the realised value within each team. A result tracker will help to make the gains of your agile teams more tangible, as it shows concrete examples of realised gains.

As long as the benefits outweigh the costs, the organisation can continue to scale up by deploying a subsequent wave of teams and resolve issues found in the ecosystem that strain the agile system. If the costs for the organisation are too high, the leadership team should take its time to monitor the environment, learn how to increase the value of the existing teams and find ways to decrease the costs.

When teams are functioning as they should, results will begin to show quite early in the process through positive changes in customer behaviour and through better problem-solving within the team. But it is important to remember that teams do take time to become fully functional[8] – on average about 8 months-. Financial results, take more time to become apparent, many take as much as 5 years to start paying dividends.

To analyse bottlenecks and illustrate opportunities for improving throughput, a Cumulative Flow Diagram (CFD) can be used

[1] Be authentic when you introduce them to each other

[2] This will help the team guide other leaders, educate the workforce and smooth out any issues that can arise within the organisation

[3] Which contingencies does the organisation need to create?

[4] Managers that are responsible for the P&L should be shown how cross-functional teams will influence their results to further drive engagement

[5] For instance: an integrated omnichannel experience

[6] This analysis will immediately give you insight into your talent gap and enables you to hire or retain professionals before scaling up your team-based structure.

[7] Create an IT architecture designed to help developers make fast, frequent releases without jeopardizing the organisation’s complex systems.

[8] A well-known framework that describes how teams naturally evolve is the model of Tuckman, who demonstrated the four key phases teams go through :

  1. Forming Individual roles are still unclear and processes are not yet formed. There is a high degree of guidance needed from the Scrum Master.
  2. Storming The relations among team members are slowly taking shape. There is a high need for constructive issue management within the group and encouraging leadership.
  3. Norming Processes are getting optimised to better align with the team’s goals. It is important to spend time recognising individual and group efforts but also to start providing learning opportunities and feedback systems.
  4. Performing The team is running well as trust and safety are realised and team members value and understand each other’s strengths. This is the perfect moment to start team evaluations.
Maike on EmailMaike on FacebookMaike on LinkedinMaike on Pinterest
Marketing and Communication Specialist at TAS - Tells a Story
Maike van Oyen is a mother, friend, sister, daughter and dedicated communications and marketing specialist on the side. She has written many articles for several websites in both Dutch and English about Corporate Communications, Marketing, Change Management and HR.

Maike loves to sink her teeth into complex projects of change and has a good knowledge of communication on a strategical, tactical and an operational level. She is trained to work in hectic environments (she manages to write blogs while also doing the housework, watching 4 misguided missiles and working for TAS at the same time). And is used to finding creative solutions for every challenge.
Tags: , , ,