Assembly lines. Used since the dawn of the industrial age to produce one thing repeatedly over and over with as little cost as possible and as quickly as possibly. The thing could be simple object, let's say an hammer or an object made out of several components and parts, moving or bolted solidly together, fr instance a car.
One way to speed up the assembly line and rate of output rate was to divide the assembly of the parts of an object into a series of separate, repeatable work steps, performed by different persons or teams along the assembly line. In this way, a set of tools and the parts required for the assembly could be stacked along the assembly line. This in turn lead to the specialization of work tasks along the assembly line, and it became possible to measure the output per work step (number of parts assembled), the failure rate and, not the least, the time different workers or teams spent on their section of the assembly line. To improve quality levels and outputs, teams were trained for their special assembly task, and baseline metrics set for number of assemblies to be made per hour or workday. In this way worker and team specialization were born, and we got organisational compartmentalization ("to separate into isolated compartments or categories"), were the workings of one functionally aligned team shouldn't interfere with others, but just interact along clearly defined borders, interfaces or hand-over points.
Work specialization, grouping of repeatable tasks and organisational compartmentalization has been going on ever since, providing a especially good fit in hierarchical organisations, i.e. most businesses, where span of control, costs of goods sold, margins and performance tracking of each employee are part of everyday life for quarterly results and internal business reviews. Production units can be measured, monitored and reported upon with a set of basic production KPIs and cost baselines consistently over time (down to the minutes if one wants). making it easy to identify good and bad performance over time per unit/compartment.
So far so good for most, or certainly for accountants or the finance dept. For organisations doing the same thing over and over this proved a unbeatable model. For organisations and businesses that provided a range of customer specific goods or services, or relied on a heavy dose of product development to constantly field the market with a series of new products or offering to stay competitive, not so much. Compartmentalization doesn't play well goods or services that needs a degree of tailoring for a set of customers, that are dependent upon flexible financing and wide range of competencies to understand market and customer, innovation opportunities and open communication across organisational units.
Enter DevOps cross-functional teams, employing agile work methods and team workings. For our discussion of "structured, compartmentalized work units for assembly lines", it's interesting to compare the approach and mindset in the Agile Manifesto with compartmentalization:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
Anyone doing a production line for standardized assembly would aim for right-hand side and feel quite foreign to left-hand side. Or it wouldn't ever cross their mind.
Anyone doing service development, software development, supporting customers with customer-specific services (sometimes legacy services even) or portfolios, or anything that can been seen as competency-intensive requiring a large degree of organisational flexibility, would start left-hand side. As "individuals and interactions", "customer collaboration" are a huge part of reaching "organisation flexibility", attracting and retaining top talent and evolving cross-functionalities with customers to stay competitive.
The key feature of DevOps and agile mindset, culture and work methods are the cross-functional composition of teams, consisting of members with different competencies and professional training, project experiences and the aggregated experience they bring to the team in their role and task at hand. In fact, putting together teams with team members having widely different and alternative, for the task at hand, competencies, work experiences and background are seen as a key dynamic for the cross-functional team. Different opinions, ways of working and skill sets will produce more dynamic and interesting results than monolithic, coherent teams.
Part and parcel of the cross-functional team setup are entrusting the teams with a large degree of autonomy on how a task is done, what the actual output can be and even which tasks or business challenges they choose to work on. A cross-functional team might be tasked with a specific product development area or business function, for instance customer facing services, but ultimately the team decides which area to attack how, with which tools and what the key deliverables will be when per their product backlog.
Cross-functional teams doesn't easily lead themselves to be monitored, base lined and reported as monolithic teams, making them somewhat an outsider approach for many traditionally rigged businesses that are brought up with waterfall project ways, tight line of command & control and budget control as the key management vehicle.
As "digitalisation" becomes an integral part of most business strategies, it will be hard for most businesses not to employ cross-functional teams and competencies to thoroughly perform and understand multi-channel customer journey mapping, analysis and mapping to service development and product management of big data collections and impact of "digitalisation" on organisation and management of the business.
Erik Jensen
September 6th, 2017
One way to speed up the assembly line and rate of output rate was to divide the assembly of the parts of an object into a series of separate, repeatable work steps, performed by different persons or teams along the assembly line. In this way, a set of tools and the parts required for the assembly could be stacked along the assembly line. This in turn lead to the specialization of work tasks along the assembly line, and it became possible to measure the output per work step (number of parts assembled), the failure rate and, not the least, the time different workers or teams spent on their section of the assembly line. To improve quality levels and outputs, teams were trained for their special assembly task, and baseline metrics set for number of assemblies to be made per hour or workday. In this way worker and team specialization were born, and we got organisational compartmentalization ("to separate into isolated compartments or categories"), were the workings of one functionally aligned team shouldn't interfere with others, but just interact along clearly defined borders, interfaces or hand-over points.
Work specialization, grouping of repeatable tasks and organisational compartmentalization has been going on ever since, providing a especially good fit in hierarchical organisations, i.e. most businesses, where span of control, costs of goods sold, margins and performance tracking of each employee are part of everyday life for quarterly results and internal business reviews. Production units can be measured, monitored and reported upon with a set of basic production KPIs and cost baselines consistently over time (down to the minutes if one wants). making it easy to identify good and bad performance over time per unit/compartment.
So far so good for most, or certainly for accountants or the finance dept. For organisations doing the same thing over and over this proved a unbeatable model. For organisations and businesses that provided a range of customer specific goods or services, or relied on a heavy dose of product development to constantly field the market with a series of new products or offering to stay competitive, not so much. Compartmentalization doesn't play well goods or services that needs a degree of tailoring for a set of customers, that are dependent upon flexible financing and wide range of competencies to understand market and customer, innovation opportunities and open communication across organisational units.
Enter DevOps cross-functional teams, employing agile work methods and team workings. For our discussion of "structured, compartmentalized work units for assembly lines", it's interesting to compare the approach and mindset in the Agile Manifesto with compartmentalization:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
Anyone doing service development, software development, supporting customers with customer-specific services (sometimes legacy services even) or portfolios, or anything that can been seen as competency-intensive requiring a large degree of organisational flexibility, would start left-hand side. As "individuals and interactions", "customer collaboration" are a huge part of reaching "organisation flexibility", attracting and retaining top talent and evolving cross-functionalities with customers to stay competitive.
The key feature of DevOps and agile mindset, culture and work methods are the cross-functional composition of teams, consisting of members with different competencies and professional training, project experiences and the aggregated experience they bring to the team in their role and task at hand. In fact, putting together teams with team members having widely different and alternative, for the task at hand, competencies, work experiences and background are seen as a key dynamic for the cross-functional team. Different opinions, ways of working and skill sets will produce more dynamic and interesting results than monolithic, coherent teams.
Part and parcel of the cross-functional team setup are entrusting the teams with a large degree of autonomy on how a task is done, what the actual output can be and even which tasks or business challenges they choose to work on. A cross-functional team might be tasked with a specific product development area or business function, for instance customer facing services, but ultimately the team decides which area to attack how, with which tools and what the key deliverables will be when per their product backlog.
Cross-functional teams doesn't easily lead themselves to be monitored, base lined and reported as monolithic teams, making them somewhat an outsider approach for many traditionally rigged businesses that are brought up with waterfall project ways, tight line of command & control and budget control as the key management vehicle.
As "digitalisation" becomes an integral part of most business strategies, it will be hard for most businesses not to employ cross-functional teams and competencies to thoroughly perform and understand multi-channel customer journey mapping, analysis and mapping to service development and product management of big data collections and impact of "digitalisation" on organisation and management of the business.
Erik Jensen
September 6th, 2017
