Agile teams are the backbone of organizational agility. Find out how to keep your existing team structure and evolve it to ensure successful project delivery.
Teamwork is in the center of the Agile universe. After all, it’s no wonder that the Agile manifesto places “Individuals and interactions over processes and tools” on top of its value system. Of course, this doesn’t mean we don’t have to optimize our processes or have the right tooling in place. However, by recognizing that our people are our greatest asset, we will be able to drive true organizational success.
The way to do that is by building Agile teams and viewing them as groups of connected service providers responsible for customer value creation. Especially in today’s highly volatile business environment, having synchronization between all of your teams should be seen as the backbone of organizational agility and successful project delivery.
The main idea of an Agile team is to have a group of people with a common goal who are flexible in the way they work and more adaptable to changing customer requirements. One thing that distinguishes them from traditional teams is that they are self-directed and self-organized individuals who practice shared leadership.
Another common trait that a lot of people associate Agile teams with, is their cross-functionality. This places a focus on generalizing specialists who can contribute to several domains instead of just their own. The idea is to cross-skill people on a single team with the purpose to eliminate hand-offs and dependencies.
While this has its benefits, it requires a fine amount of disruption of existing processes especially if we are talking about more traditional organizations embarking on an Agile transformation. As a result, companies often experience high rates of chaos and resistance which could be too hard for them to deal with. Eventually, they go back to their old ways of operating, discarding the idea of building Agile teams.
That’s why to reduce this risk, a better approach would be to keep your existing structure (especially if it’s been giving you solid results so far) and look to gradually improve it through continuous experimentation.
When implementing Agile for the first time, a lot of people believe that’s a one time endeavor that ends with applying a specific framework. In reality, the process keeps progressing as you learn how to do things better and better.
That’s why Kanban takes an evolutionary and human-centric approach to form Agile teams as well as scale agility across the organization. The method simply asks us to start where we are now by visualizing our existing operations, respect the current processes and roles, and then evolve from there.
In fact, the first step to evolving your teams and making them more Agile is to see them as services (responsible for value creation) rather than expendable resources. From engineering/product development to sales and marketing, every team member is a service provider of some sort who helps the company move forward by adding value to the final offering either directly or indirectly.
So, to ensure a symbiosis between all of your teams, you need to view them as an ecosystem of interdependent services where each service evolves on its own. As a result, you will have a way to optimize the entire flow of value to your customers but also derive large scale improvements from localized optimizations at the service-level.
End-to-Еnd Organizational Visibility
Kanban, for example, aims to achieve that by using a network of interconnected Kanban boards where every team’s work (the service they provide), is visualized inside their own system. To make sure that those systems work properly and stay Agile to changing customer requirements, we abide by the following 3 service-delivery principles.
Everything that we produce should be seen from a customer perspective. That’s why the stepping stone to improving our team’s value delivery is to understand what makes the service that we provide fit for its purpose. The way to do that is by measuring what is known as “fitness criteria” which tell us how well a product or service fulfills customer’s desires.
Apart from quality (functional and non-functional), that criteria usually represents service-delivery indicators such as delivery rate (end to end duration), predictability, quantity, etc. To measure those, you can use metrics such as lead and cycle time, WIP (Work In Progress), throughput, etc. as well as charts which help you visualize and analyze how you are delivering value.
Once teams are equipped with that knowledge, they become capable to design their workflows after customer needs and produce services that are more “fit for purpose” for their target market.
To ensure a successful service-delivery, you should also focus on managing work, while letting people self-organize around it. Remember that team members are closest to the technical details of customer requests so it makes sense to have them decide how to best execute those requests.
Leaders in turn should seek to create alignment within the network of services through communicating a shared purpose. Then, they need to manage work by visualizing queues, alleviating bottlenecks, and measuring flow efficiency rather than only tracking timelines. This results in higher team morale, increased efficiency, and eventually better service-delivery to the end-customers.
Finally, to keep your systems working properly, you need to view your team’s processes as a set of policies that create a shared understanding of how work gets done. Make those policies explicit and visible to everyone. This opens them up for collaborative discussions and potential improvements.
The idea is to initially see how your teams deliver services to the market and then gradually evolve their approach by reflecting the value delivery process from a customer point of view. As a result, you will be able to improve overall business outcomes while retaining agility to quickly adapt to changing customer needs whenever necessary.
As we have already mentioned, every team in the organization provides a service of some sort and their work should be visualized. To build more Agile teams you should look to evolve that system so you can achieve better predictability and shorter cycle times to market. To accomplish that, you need to have a way to manage various types of services, risks associated with them as well as streamline team collaboration across the entire network.
Let’s see how you can achieve this in practice below.
If every team provides a service of their own, then the different types of work can represent sub-services within the team. In order to identify them, you can map your team’s work process on a Kanban board and structure it in a way for team members to easily manage the flow of different work types.
For example, fixing a defect in a product component represents a service for increasing the quality of the deliverable. In case the team responsible for that receives a steady number of similar requests, they should visualize the flow of that specific type of work and look to optimize it to better meet customer’s service delivery requirements.
In Kanbanize for example, we do that in practice with the help of Multiple workflows. There, the idea is to manage the delivery of various work types or even entire projects (depending on their size) to the end customer. This helps our teams create better organization inside their service-delivery processes and increases efficiency as they don’t have to switch between multiple boards in order to check the progress of various work types (sub-services).
Classes of service represent policies of how we treat our work. There are four typical classes of service: Expedite, Fixed Delivery Date, Standard, and Intangible. However, those are only guidelines and you are encouraged to introduce your own based on the specificity of your workflow.
The idea here is simple. Classes of service help you manage the risk of delaying specific work items based on their urgency. For example, Expedite separates tasks that are absolutely critical and bear the highest cost of delay. Fixed Delivery Date, on the other hand, classifies items that customers want delivered by a specific point in time.
To introduce different classes of service in your work process, you can visualize them on the Kanban boards. In Kanbanize we use swimlanes to define classes of service and apply them within our Multiple workflows. This helps us meet customer delivery expectations for different work types and have a way to manage the predictability of our processes as a whole.
One of the most important things for building Agile teams that we haven’t mentioned yet is team collaboration. In order to ensure proper flow of value delivery from your entire service network, you need to streamline collaboration between teams responsible for every service.
Instead of eliminating cross-team dependencies, you visualize them and then look to evolve the way you manage them. In practice, this can happen with interlinked Kanban boards where the entire flow of value from one service to the other is made visible.
Then, with the introduction of regular cadences (meetings) across the entire organization, teams will be able to collaborate with one another, sync progress, and discuss dependencies in front of the boards. As a result, they can swiftly adapt to changing customer needs or market conditions but also seek ways to collaboratively improve their service-delivery processes.
End-to-Еnd Organizational Visibility
Building Agile teams requires you to view your existing structure as an ecosystem of interdependent services and then look to evolve it by creating an individual system for each service. This way you will be able to build stable teams that provide “fit for purpose” solutions to their customers and retain agility to changes.
In order to manage your team’s services, you need to:
During the 30-day trial period you can invite your team and test the application in a production-like enviroment.