The Cohort of Responsibility
Sometimes the team just isn't enough.
Delivering business value from idea to production is a complex endeavor. Development teams sit squarely in the middle of that process. Ideally, they are talking directly to the customer. Often in real life, business analysts collect requirements from customers and pass them to the development team. On the other side, development interacts with operations to deploy and run the software.
All of these groups, and more, have the responsibility to deliver the business value. But too often, there is friction between these groups on the path. Not everyone wants to move in the same direction. Some individuals or groups can slow down or altogether stop value from being delivered. They are responsible, but not always accountable.
Everyone who bears direct responsibility toward delivering business value is part of the Cohort of Responsibility in the organization. To most easily identify everyone in the cohort, we can pick out everyone who must touch a requirement along its path from customer all the way back to customer as finished product. These are the people that must do something or it will never get delivered.
The first and foremost member of the cohort is the customer themselves. Since the customer is not a member of the organization, they are "half-in" both at the start of the process, for creating ideas, and at the end of the process, for receiving the value. All cohorts of responsibility start and end with the customer. If the customer is not part of the cohort, there are no guarantees that the process is creating and delivering any value at all.
Inside of the organization, the development, business analysis, quality assurance, security, and operations teams are all part of the cohort. Those functions are all needed for delivering quality product (though some organizations may divvy those capabilities across a different arrangement of actual teams). Those teams all bear responsibility and execute the different parts of the value stream. For the best outcomes, they need to work together to deliver.
Unfortunately, the business may not have the same expectations for all these teams. Operations is judged by uptime and stability. Quality assurance measures defects found. Development counts code delivered. Sometimes these metrics conflict with each other. Adding new code means decreased stability and uptime, for example. Friction arises from these conflicts.
The cohort of responsibility needs to be assessed on a uniform standard stretching from end to end. The entire chain needs to deliver business value to the customer. The cohort needs to work together across team lines to accomplish this. They need to truly share the goal of delivering business value. They need to find a globally optimal solution that balances all the needs against the goal. They need a management and business structure that understands and supports them.
The easiest way to do this would be to just have a single team encompassing the entire cohort. They will be cross-functional. They will have a single leader, a single standard of measurement, and a single measure of accountability. This would eliminate all of the friction between different teams. The team would be fully self-sufficient.
Not every organization can have a single team, though. The teams might be too large. Or there might be bureaucratic impediments to unifying all of the functions. Having distinct teams that work closely together with frequent communication can provide the same benefits. Frequent communication lubricates the contact between the teams, reducing the friction. It will not be as smooth as on a single team, but it can be smooth enough to work effectively.
The biggest challenge the cohort faces is its own sheer size. The cohort should not include extraneous members because the process should not contain extraneous steps. The process and the cohort should be simplified as much as reasonable to get them working to their highest effectiveness.
By identifying, understanding, and coordinating the cohort of responsibility, we can deliver better value faster.
Delivering business value from idea to production is a complex endeavor. Development teams sit squarely in the middle of that process. Ideally, they are talking directly to the customer. Often in real life, business analysts collect requirements from customers and pass them to the development team. On the other side, development interacts with operations to deploy and run the software.
All of these groups, and more, have the responsibility to deliver the business value. But too often, there is friction between these groups on the path. Not everyone wants to move in the same direction. Some individuals or groups can slow down or altogether stop value from being delivered. They are responsible, but not always accountable.
Everyone who bears direct responsibility toward delivering business value is part of the Cohort of Responsibility in the organization. To most easily identify everyone in the cohort, we can pick out everyone who must touch a requirement along its path from customer all the way back to customer as finished product. These are the people that must do something or it will never get delivered.
The first and foremost member of the cohort is the customer themselves. Since the customer is not a member of the organization, they are "half-in" both at the start of the process, for creating ideas, and at the end of the process, for receiving the value. All cohorts of responsibility start and end with the customer. If the customer is not part of the cohort, there are no guarantees that the process is creating and delivering any value at all.
Inside of the organization, the development, business analysis, quality assurance, security, and operations teams are all part of the cohort. Those functions are all needed for delivering quality product (though some organizations may divvy those capabilities across a different arrangement of actual teams). Those teams all bear responsibility and execute the different parts of the value stream. For the best outcomes, they need to work together to deliver.
Unfortunately, the business may not have the same expectations for all these teams. Operations is judged by uptime and stability. Quality assurance measures defects found. Development counts code delivered. Sometimes these metrics conflict with each other. Adding new code means decreased stability and uptime, for example. Friction arises from these conflicts.
The cohort of responsibility needs to be assessed on a uniform standard stretching from end to end. The entire chain needs to deliver business value to the customer. The cohort needs to work together across team lines to accomplish this. They need to truly share the goal of delivering business value. They need to find a globally optimal solution that balances all the needs against the goal. They need a management and business structure that understands and supports them.
The easiest way to do this would be to just have a single team encompassing the entire cohort. They will be cross-functional. They will have a single leader, a single standard of measurement, and a single measure of accountability. This would eliminate all of the friction between different teams. The team would be fully self-sufficient.
Not every organization can have a single team, though. The teams might be too large. Or there might be bureaucratic impediments to unifying all of the functions. Having distinct teams that work closely together with frequent communication can provide the same benefits. Frequent communication lubricates the contact between the teams, reducing the friction. It will not be as smooth as on a single team, but it can be smooth enough to work effectively.
The biggest challenge the cohort faces is its own sheer size. The cohort should not include extraneous members because the process should not contain extraneous steps. The process and the cohort should be simplified as much as reasonable to get them working to their highest effectiveness.
By identifying, understanding, and coordinating the cohort of responsibility, we can deliver better value faster.
Comments
Post a Comment