Transitioning your organization to agile ways of working often comes with much confusion from traditional managers on what is required for a team to perform under such a structure. Mainly, in organizations who are restricted or not open to changing their entire organizational structure to support an end-to-end product or service delivery. Those organizations often attempt to implement agile ways of working in a silo, e.g., only specific teams such as engineering and IT are agile. Those teams often struggle to become agile as well as seeing the benefits of their effort to become agile.
What happened?
Agile product or service delivery structure requires bringing many people from different expertise to work together on a common goal. The fundamentals of any agile structure are ownership and trust. Meaning, the team do not need to be told how to solve problems, plan, or prioritize their work. Instead, they need to have a deep understanding of a concrete problem and feel responsible to solve that problem for a real customer they care for. Moreover, their leadership would need to share the trust that the team can own it and deliver. This is much more complex to implement than it sounds.
A common belief is that if a team have all the expertise required to develop a particular product increment, they are autonomous by default. Unfortunately, this belief is untrue. Agile teams in non-agile setup often do not and can not work entirely autonomously and probably also should not. In practice, for example, a B2B software delivery team might have a cross-functional development team with diverse expertise in front-end and back-end development, design, and quality assurance. However, they will be part of an engineering department while marketing, sales, and other functions would be part of a specialized team or department working directly with the customer accounts. Meaning, development teams might have no customer interaction or impact on what product they sell, leading to issues such as over-committing to non-existent features that the team cannot deliver and delivering increments that are not aligned with what was promised to the customer.
In such a setup, traditional managers become the center of information. As they are the only ones aware of the broader context, people become highly dependent on their managers to tell them what to do and when to do it. They are unable to prioritize by themselves and continuously feel confused and disconnected. For a team to become self-managed and self-organized, the team has to understand how their goals fit into the broader vision and mission of the company as well as continuously communicate with their internal stakeholders such as marketing or sales team, and external stakeholders – their customers. Thus, the manager duty shifts from overseeing and controlling the delivery to facilitating that a process that ensures the team can gather the information they need so they can focus on the right things and deliver their best outcomes. That is often easier said than done.
I want to be agile; I need no process.
The first agile principle in the agile manifesto is “individual and interactions over processes and tools.“ Agile practitioners often understand this principle as a reason to drop all processes and assume the team can completely self-manage and organize themselves without having a process. The actuality is that by not setting an explicit process, teams often create a discrete process that is not always understood by their leadership and the larger organization. Moreover, team members are not always aware of their internal process, what ownership means on an individual level, and how does their team goal contribute to the broader organization success.
If you are part of such a team or maybe you are the leader, ask yourself how much time do you waste in your existing non-explicit process? Real agility comes from setting up the processes and tools that facilitate individuals and interactions. It means establishing processes that work for you rather than you work for it. It does not mean you have to re-invent the wheel as there are best practices out there. However, it does mean to acknowledge that every organization is driven by a set of explicit and discrete processes. As such, by not setting up an explicit process for specific workflows, you might invite unequal distribution of work, unclear ownership and responsibilities, and lack of performance measurements.
I know. Some people are allergic to performance measurements, so let me ask you – How do you know that you are getting better? How do you know that you master your work? How do you know your customers love your product? How do you know that you are not wasting your time? Maybe you do not care about knowing as long as it feels right. Perhaps you are lucky, and your intuition was always spot on. Then this article is not for you. However, if you struggle getting things done and see the results in reality, then you should ask yourself, how would you know that you are progressing in the right direction? Performance measurements.
By understanding processes, teams and individuals become aware of time investment, bottlenecks, risks, and the impact of their actions and outcomes on customers and other individuals in the organization. Exposing processes create transparency across the organization, allowing employees to have a shared understanding of the context and provide feedback that supports the organization to improve continuously.
We have an agile coach at the Engineering team. Is that not their job?
Agile coaches and scrum masters in traditional structures are often hired to support a specific team or department. Thus, they do support the team to visualize its internal processes by setting up a team board. Some agile coaches or scrum masters would also keep a visible dashboard or visualization of KPIs that would support the team in identifying where they could improve over time. They make the implicit explicit on an internal team level, not on an organizational level. Hence, no, they are not always welcome to map the end-to-end process across multiple departments on a corporate scale. Of course, they should be equipt to facilitate those discussions when they are welcome.
Our process changes all the time so let’s not waste everyone’s time here
Setting up an organizational-level explicit process together with your agile teams and the other impacted stakeholders, even if the process changes often, allows…
- … the larger organization and primarily the team leadership and stakeholders to understand how information flows and check-in on the status of a specific request, issue, idea or feedback.
- … the team to have transparency on how they are doing and identify real opportunities for improvement internally and externally to the team.
- … the team to identify bottlenecks, lack of capabilities, and request support such as training, coaching, and new members hiring.
- … the organization and team leadership to evaluate the impact of decisions such as providing training, adding or removing a team member or changes of scope.
- … everyone involved across the whole organization to focus on delivering the same thing.
Got it. How do I do that?
Setting up an organizational-level process requires collaboration across different parts of the organization. The following steps would provide you with some initial guidance on how to structure this type of effort:
- Write down all the steps required for your organization to deliver a product or service to a customer. For example, at Signavio our process is from Idea-to-Wow, and it covers idea discovery, problem definition, solution ideation, solution definition, implementation & testing in tandem, deployment, go-to-market, inspection, and adaptation.
- Bring together everyone involved in the overall process. Depending on your organization size, a leadership team and selected individuals would need to get together to collaborate on this process. Ensure you have all decision makers in the room and that together you cover and understand each step, including the input and output of each step.
- Clarify the who covers and owns what steps. E.g., solution ideation, solution definition, implementation, testing, and deployment is owned by the engineering team.
- Understand what the input and output of each team are. For example, software product delivery team input would usually include product feedback, change requests, issues, improvement ideas, and new functionality. Their output would typically include product increments such as new feature, bug fixes and improvements, and documentation such as release notes, user manual, and general how-to guidelines.
- Identify in what steps of this process you have agile teams. E.g., if your engineering is agile, but the rest of the organization is not, it is worth dedicating owners in the other department to their workstream to simplify communication — for example, dedicated sales representatives to a product.
- Create an unofficial team that consists of all people who are dedicated to the product, service, or workstream. This larger team will get together periodically to exchange knowledge and iterate on their ways of working across departments and functions.
- Trust that together they can set up their own internal process. Ensure they understand that they are expected to do so, document it and share it. Support them with facilitation, either by an agile coach or a consultant with experience designing internal processes. The input and output identified are vital to kick-start the conversation.
What would it look like at the end? a dynamic documented process that everyone can understand and explain to others. This is what we do, how we do it and why we do it.
Input-Output? What are you talking about?
Input and outputs are a simple way to discuss information flow between activities in a process. Inputs represent the prerequisite information required to start an activity while outputs represent the deliverable of the activity. E.g., for a solution ideation session to happen successfully, we need a problem statement to focus on. Solution ideation session with no problem statements can lead to solutions that solve the wrong problem. The output of such a meeting is not likely to create value.
Do not confuse outputs and outcomes. Teams can have many outputs that mean nothing and waste their times. Understanding the input and output of the team allows the team to set up their internal process and define what they need before they decide how to handle it. They will determine what information they need to accept a particular input (e.g., we need steps to reproduce a bug) and how they can measure the success of their output (e.g., acceptance criteria and definition of done). Setting those standards and expectations allows the team to communicate their stakeholders on how to provide input and how they are expected to receive the output. Also, the team can use KPIs to measure their performance (e.g., how many bugs were reported in the last 2 weeks?) and take steps in improving their speed and quality (e.g., we received many bugs related to this feature, we should have an investigation task next sprint to understand what is the problem).
To summarise, traditional companies can integrate agile teams if they are willing to invest the time and effort required to shift their mindset from top-down delegation to collaborative process optimization. It does not require changing the whole organizational structure, but it does require you to take concrete steps in setting up a supporting network of people working together across departments on one shared process.
