Organizational Inertia - A Predictor for Success of Agile Transformations? (Part 2)
Join the DZone community and get the full member experience.Join For Free
In part 1 (Organisational Inertia - Part 1) I have focused on the question: 'Organizational Inertia - What is it?’. This blog addresses the question ‘How do we measure it?’.
I'll start from the definition of Organizational Inertia as defined in part 1. Then connect to existing models of Organizational Inertia and the relation to Agile teams and show how the analog with Physics is used to find a measure for the 'acceleration'. Then I'll combine these elements to provide a way of measuring inertia. Finally I'll provide basic examples.
Definition of Organizational Inertia
Following the analogy with physics I defined Organizational Inertia in Organizational Inertia - Part 1 as:
Organizational Inertia is an organization's capability to change after applying some force to it. Specifically, I define it as the ratio of the force applied and the speed of organizational change (acceleration) in reaction to some applied force, or in formula "Inertia (M) = Force / Acceleration".
We just shifted the problem of defining Organizational Inertia to defining ‘some applied force’ and ‘speed of change’. The next sections will provide an interpretation of these in the context of Agile teams and a model to describe 'some applied forces'.
Origin of the Forces Driving Organizational Change: Change Restraining and Change Facilitating Forces
Associated with Organizational Inertia are two competing forces as described in the Inertia model of Connor & Lake [Con88] (see also [Kin98]). This model describes the Change-restraining forces and the Change-facilitating forces.
The model recognizes that there are forces that hinder change and that there are forces that facilitate change.
One of the Agile principles is to regularly reflect on how you are doing and improve. By doing so Agile teams not only improve over time but they change too. An Agile team will force the environment to change with it. For more information on this, check out the 'fitness landscape' [App 11] chapter 15 "How to Improve Everything."
Another common way Agile teams force the environment to change is by pulling more work in than the environment is capable of delivering. Or, by pushing more working software into production and thereby literally pushing the limits of what the environment is capable to process. The latter mechanism drives organizations towards DevOps [Deb11]. The combination of applying a force to both the up- and down-stream teams is what drives the need for BusDevOps (Agile Delivery Model), see Agile Delivery.
Examples I often see in practice of how Agile teams force the organization (or environment) to change include:
- a faster delivery rate forces the environment to cope with more releases and simultaneously forces the business to keep up by supplying user stories at a higher rate,
- raising impediments,
- the business wants more features than IT can deliver (this often drives the need to transition form a traditional way of working to an agile way of working).
For a systemic view on cause and effect related to Organizational Inertia see e.g. [Lar96].
How (Agile) Teams Act As Change-Facilitating Forces
Agile teams continuously improve. The way they improve I divide in 3 types. With each type I associate a 'force'. The next section will go into details of quantifying them.
In Management 3.0 [App11] chapter 15 “How to improve everything” the concept of the ‘fitness landscape’ is explained. In this metaphor the team is part of the landscape (the environment of the team within the organization) in which the team optimizes a certain variable, for instance the business value it creates. The optimum is symbolized by the highest mountain peak. Through improvements the team finds its way to the highest peak. Besides team intrinsic changes the team can also change the environment and thereby change the landscape by moving mountains towards the team instead of moving towards the mountain.
Following this metaphor there are three ways for a team to reach the top of the highest peak:
I) gradually improve (changes intrinsic to the team),
II) large improvements (kaikaku) and jump to other (nearby or remote) mountains, or
III) change the environment, i.e. moving the mountains to the team.
Gradual Improvements (Type I Changes)
Agile teams regularly evaluate how they are doing. A common practice is to perform a retrospective every two weeks. In the retrospective the team decides what to change and executes these improvements in the next sprint (or time period). With these improvements the team walks the ‘fitness landscape’ to the nearest mountain peak. The improvements may be gradual and internal to the team. By this we mean that it increases the velocity and does not force the environment of the team, i.e. the organization, to change. The team does not exert a force to the organization.
Large Improvements (Type II Changes)
It may also be the case that the improvements within the team either dramatically increase the velocity or many gradual improvements increases the velocity over a certain threshold. When this happens - in my experience it is not a question whether this will happen but rather ‘when’ - it will force the direct environment of the team to change with it.
For example, when teams start to deliver user stories faster the business needs to keep up by having enough user stories ready.
Another example is that operations needs to keep up by putting more features into production.
This way the team applies a force to the surrounding organization that needs to change as well. The team is not just walking the ‘fitness landscape’ but forcing the landscape to change as well [App11].
Moving Mountains (Type III Changes)
￼The third way for teams to apply a force is to raise impediments and have the organization help them by addressing the most important impediments. By structurally solving impediments the organization is changing the ‘fitness landscape’ [App11] by moving the mountain peaks to the team.
With 'structurally solving impediments' I mean that solving the impediments requires company policies to be changed.
An Organization's Speed of Change
The final part is to have a way of measuring the speed of change while the Agile team exerts a force upon the organisation. Before we can answer this question we need to identify how to observe that an organisation changes. Possible variables are:
- the trend of the (average) resolution time of impediments,
- change in the rate of bringing features to production,
- change in the rate of taking work to the team(s),
- company policies being changed.
Potentially this could become a long list. But are all these changes relevant? Ultimately it’s the bottom line that counts. It’s all about the outcome. Let’s try to come up with variables that are of value to the business. This is pretty close to the bottom line. At least close enough. Variables that come into mind include:
- change in the rate of business value per unit of time,
- change in rate of an organisation’s (agile) maturity rating,
- change in rate of product incidents per unit time.
These are all variables that can be measured and are the (complex) outcome of the changes made.
The choice depends on the goal that you want to achieve with the (agile) transition. As long as this is communicated clearly to the organisation and progress is being made as measured using this or these variables, you are measuring the rate of success and there will be enough energy in the organisation to continue the transition and avoid Organisational Gravity kicking in.
Metrics for Organisational Inertia
From the aforementioned examples we recognise the following metrics for the 'forces' (Change Facilitating):
- [F1] the number of raised impediments per time period, e.g. per sprint or per month,
Force = <Number of Raised Impediments per Period>,
- [F2] difference in rate (throughput) for pre-sprint, sprint and post-sprint parts in a so-called cumulative flow diagram,Force [F2a] = <Business Value Delivered in Production per Period> - <Work According to DoR Worth of Business Value per Period>, orForce [F2b] = <Business Value Delivered in Production per Period> - <Work Completed according to DoD Worth of Business Value per Period>
Force [F2a] measures the 'strength' with which the (Scrum) team is pulling work from the Product Owner. A positive value means that the PO cannot keep up with the team.
Force [F2b] is similar for the IT-Ops - (Scrum) team interaction. Positive values indicate the (Scrum) team is pushing work for production at a faster rate than the organisation is capable of taking into production.
The associated metrics for measuring the 'acceleration' (speed of change) are:
- the trend of the average number of resolved impediments per time period; count only resolved impediments that required changes in company policies,
Acceleration = Δ(<Number of Resolved Impediments per Period>)/<Period>,
- [A2] the trend or change in the rate of business value (outcome) delivered per time period,
Acceleration = Δ(<Business Value Delivered in Production per Period>)/<Period>.
The metrics just given are readily available to Scrum teams and can easily be applied to any team, kanban type of system, or to any part of the total value stream.
Putting It All Together
Using the results of the previous section I quantify Organisational Inertia in terms of measurable variables available to (Agile) teams.
Gradual internal improvements that the team makes (Type I changes) often lead to Type II changes after a certain period of time. Therefore I only explicitly address Type II and Type III changes (as explained earlier).
Are We Moving the Mountains? (Type II Changes)
Taking the change facilitating forces as a basis the Organisational Inertia is derived as follows.
First, consider the metric for inertia ( Morg ) based on business value, i.e. [F2b] and [A2] from the previous section. Combining these gives:
What does this formula tell us?
- if the team’s delivery rate balances the organisation's rate of putting features into production no force is exerted and the organisation will not be forced to change; then also no change (Δ) in the delivery rate,
- if the team delivers more functionality than the organisation can take into production, the team exerts a certain force upon the organisation which needs to undergo structural improvements causing a positive change (Δ) in the delivery rate,
- for small values of the inertia ( Morg ) the effect on the change in delivery rate is larger.
Note: A unit of measure for Morg is ‘time’, e.g. 'weeks' or 'sprints' for Scrum teams.
Example 1. Suppose that the team delivers 5% more business value each sprint. Suppose further that they deliver 20% worth of value faster than can be taken to production. Then the inertia is ’4 sprint’ (20% divided by 5%).
Example 2. Suppose that no change in the rate of delivered business value is measured. Then the Organisational Inertia is infinitely large; under a change facilitating force it does not change.
The effect of Organisational Inertia on delivered business value
Example 3. Suppose an inertia of ’4 sprint’ (Example 1). Further suppose that the team pushes 20% worth of features per sprint more than can be taken into production. Then it will take Morg /20% = 20 sprints to double the production rate.
Example 4. As in the previous example, the graph to the right shows the same team but in an environment in which the inertia is twice the inertia of the other environment. The team in the environment with the least inertia delivers value at a rate that increases twice as fast as compared to the other team. This results in twice as much business value being generated.
Are the Mountains Moving? (Type III Changes)
Another possibility is to take impediments as a basis to define and measure the Organisational Inertia ( Morg ):
Note: Only impediments that actually result in changes in the organisation should be taken into account.
Note: This can also be translated in terms of business value by estimating how much more business value the team would be able to put into production if the impediment is resolved.
Note: The unit of measure is ‘time’, e.f. 'weeks' or 'sprints'.
Organisational Inertia is supplementary to the concept of Organisational Gravity and an indicator for how well the team’s environment is facilitating the team’s growth. The two counter balancing driving forces of the speed of organisational change are the Change-restraining and Change-facilitating forces.
An indicator available to agile teams for the Change-restraining forces is the average number of solved impediments per time period. Change-facilitating forces are the forces that teams exert on their environment. Indicators available to agile teams are the amount of pulling from the business for more ready features and pushing completed work into production.
Using the interpretation of the formula F=MA , well-known in physics, in terms of the Change-restraining and Change-facilitating forces as defined in the model for Organisational Inertia from Connor and Lake [Con88], and identifying M with Morg expressions for Organisational Inertia are derived.
Once the organisation's inertia is known, this can serve as a prediction how long it will take to increase the organisation's delivery rate with a certain amount and is related to the business case of Agile Transformations.
|Management 3.0, Jurgen Appelo, 2011, Pearson Education,|
|[Deb11]||Devops: A Software Revolution in the Making, Patrick Debois, August 2011, Cutter IT Journal, Vol. 24, No. 8, [a href="http://www.cutter.com/promotions/itj1108/itj1108.pdf"]http://www.cutter.com/promotions/itj1108/itj1108.pdf,|
|[Con88]||Managing organization change, P.E. Connor & L.K. Lake, 1988, New York: Praeger,|
|[Kin98]||The development of an instrument for measuring organisational inertia, C Kinnear, G Roodt, Journal of Industrial Psychology, 1998, 24(2), 44-54; see http://ujdigispace.uj.ac.za/handle/10210/1047,|
|[Lar96]||The Dynamics of Organisational Inertia, Survival and Change, Erik R. Larsen, Alessandro Lomi, 1996, System Dynamics conference, http://www.systemdynamics.org/conferences/1996/proceed/papers/larse308.pdf|
Published at DZone with permission of Pieter Rijken. See the original article here.
Opinions expressed by DZone contributors are their own.
Five Java Books Beginners and Professionals Should Read
Introduction to Domain-Driven Design
AI and Cybersecurity Protecting Against Emerging Threats
10 Traits That Separate the Best Devs From the Crowd