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 drive real 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.
An Agile team's main idea 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 with Agile teams is their cross-functionality. It 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 sufficient 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 a better approach to reduce this risk 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, many 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 and scale agility across the organization. The method encourages us to simply start where we are now by visualizing our existing operations, respect the current processes and roles, and then evolve from there.
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.
To ensure a symbiosis between all 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 and derive large scale improvements from localized optimizations at the service level.
For example, Kanban aims to achieve that by using a network of interconnected Kanban boards where every team visualizes its work (the service they provide) inside their system. To ensure that those systems work correctly and stay responsive to changing customer requirements, we abide by the following three service-delivery principles.
Everything 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 our services fit for its purpose. To do that, we measure their "fitness criteria" - an indicator that tells us how well a product or service fulfills customer's desires.
Apart from quality (functional and non-functional), it 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., and charts that help you visualize and analyze how you deliver value.
Once teams have this knowledge, they are capable of designing their workflows after customer needs and producing 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, team members are the ones closest to the technical details of customer requests, so it makes sense to let them decide how to execute those requests best.
In turn, leaders should create alignment within the network of services by communicating a shared purpose. 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 improve overall business outcomes while retaining the agility to adapt to changing customer needs whenever necessary quickly.
As 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 to 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 and 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. To identify them, you can map your team's work process on a Kanban board and structure it so that team members can easily manage the flow of different work types.
For example, fixing a defect in a product component represents a service for increasing the deliverable's quality. 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 meet customer's service delivery requirements better.
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 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 your workflow's specificity.
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 critical and bear the highest cost of delay. On the other hand, a fixed Delivery Date classifies items that customers want to be 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 our processes' predictability as a whole.
One of the most important things for building Agile teams that we haven't mentioned yet is team collaboration. To ensure the proper flow of value delivery from your entire service network, you need to streamline the collaboration between teams responsible for every service.
Instead of eliminating cross-team dependencies, you visualize them and then 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.
With the introduction of regular cadences (meetings) across the entire organization, teams will collaborate, sync progress, and discuss dependencies in front of the boards. As a result, they can swiftly adapt to changing customer needs or market conditions and collaboratively seek ways to improve their service-delivery processes.
Building Agile teams require you to view your existing structure as an ecosystem of interdependent services and then 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.
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.