Constraining Agility
An outsider walking into an organisation can almost feel the waste and bureaucracy impeding it's progress. On the same day, a person of similar skills, beliefs and capabilities that works within the company feels they are working in a clearly organised, functional entity.
Perceptions
The difference between the 2 people is their perception of impediments and constraints.
CONSTRAINT - (courtesy of dictionary.com)
con-straint [kuhn-streynt]
-noun
1. limitation or restriction.
2. repression of natural feelings and impulses: to practice constraint.
3. unnatural restraint in manner, conversation etc.; embarrassment.
4. something that constrains.
5. the act of constraining.
6. the condition of being constrained.
7. Linguistics. a restriction on the operation of a linguistic rule or the occurrence of a linguistic construction.
-Synonyms
1. force, obligation, pressure.
For me, the difference between an impediment and a constraint is whether the individual, team, organisation, enterprise, or industry considers the obstacle as removable. If whoever is working with the obstacle believes it can be removed then it is considered an impediment, if the same person doesn't not believe it can be removed, or doesn't wish to work towards it's removal, it's considered a constraint.
THIS IS THE FUNDAMENTAL CRUX OF AGILE ADOPTION!
For the opening statement of this blog, we could infer that the outsider has not fought any battles within the organisation to effect change, nor do they know how to work through the bureaucracy, they have not had to live and be successful in this environment and so can see all the waste.
Our categorisation of an obstacle as a constraint or an impediment fundamentally defines how agile we are, and an organisation's ability to see impediments rather than constraints and remove these impediments will ultimately define the success of their agile adoption.
Example:
A team are adopting agile and have 20 guys in the UK and 20 guys in India. What's the best way to run Scrum?
The best way to run Scrum is to have a co-located team. Now, is the above obstacle an impediment or constraint for your project, and what are you going to do about it? Will the organisation remove the obstacle of a distributed team to become more agile, or is it a constraint to be worked around introducing waste in administration and latency in communication.
Obstacles come at us at every layer of an organisation trying to develop software:
The individual team member who doesn't want to do the scrum until 10:30am because they start late and want their coffee first
Or
The wise experienced senior developer who is so good he doesn't need to pair program
Or
The project portfolio that needs to be defined and estimated in Q3 of the previous year
Or
the industry regulator-imposed legal standards that require multiple product backlog items.
Which of these obstacles are impediments and which are constraints?
In my experience the answer is different for every individual, team, organisation, company and industry that looks at it.
BUT... Those of you that see them all as impediments are thinking like scrum masters rather than project managers. The next step is to work out how to start removing them all piece by piece. Essentially this continuous improvement is lean thinking and this takes years of work to achieve.
We need to develop organisational mindsets (or dominant logic) that sees only impediments!
A collaborative organisation that knows its vision, understands where its trying to get to, and works collectively to remove impediments, eliminate waste, create flow and therefore increase velocity.
Perceptions
The difference between the 2 people is their perception of impediments and constraints.
CONSTRAINT - (courtesy of dictionary.com)
con-straint [kuhn-streynt]
-noun
1. limitation or restriction.
2. repression of natural feelings and impulses: to practice constraint.
3. unnatural restraint in manner, conversation etc.; embarrassment.
4. something that constrains.
5. the act of constraining.
6. the condition of being constrained.
7. Linguistics. a restriction on the operation of a linguistic rule or the occurrence of a linguistic construction.
-Synonyms
1. force, obligation, pressure.
For me, the difference between an impediment and a constraint is whether the individual, team, organisation, enterprise, or industry considers the obstacle as removable. If whoever is working with the obstacle believes it can be removed then it is considered an impediment, if the same person doesn't not believe it can be removed, or doesn't wish to work towards it's removal, it's considered a constraint.
THIS IS THE FUNDAMENTAL CRUX OF AGILE ADOPTION!
For the opening statement of this blog, we could infer that the outsider has not fought any battles within the organisation to effect change, nor do they know how to work through the bureaucracy, they have not had to live and be successful in this environment and so can see all the waste.
Conversely, the insider understands the process, how things get done within the existing bureaucracy (be it slowly) and has invested time and effort in understanding how it works. They are themselves valued on their ability to be successful within this constrained environment - pushing to change it does not help themselves or those people they are working with.
We are Constantly Categorising ObstaclesOur categorisation of an obstacle as a constraint or an impediment fundamentally defines how agile we are, and an organisation's ability to see impediments rather than constraints and remove these impediments will ultimately define the success of their agile adoption.
Example:
A team are adopting agile and have 20 guys in the UK and 20 guys in India. What's the best way to run Scrum?
The best way to run Scrum is to have a co-located team. Now, is the above obstacle an impediment or constraint for your project, and what are you going to do about it? Will the organisation remove the obstacle of a distributed team to become more agile, or is it a constraint to be worked around introducing waste in administration and latency in communication.
Obstacles come at us at every layer of an organisation trying to develop software:
The individual team member who doesn't want to do the scrum until 10:30am because they start late and want their coffee first
Or
The wise experienced senior developer who is so good he doesn't need to pair program
Or
The project portfolio that needs to be defined and estimated in Q3 of the previous year
Or
the industry regulator-imposed legal standards that require multiple product backlog items.
Which of these obstacles are impediments and which are constraints?
In my experience the answer is different for every individual, team, organisation, company and industry that looks at it.
BUT... Those of you that see them all as impediments are thinking like scrum masters rather than project managers. The next step is to work out how to start removing them all piece by piece. Essentially this continuous improvement is lean thinking and this takes years of work to achieve.
We need to develop organisational mindsets (or dominant logic) that sees only impediments!
A collaborative organisation that knows its vision, understands where its trying to get to, and works collectively to remove impediments, eliminate waste, create flow and therefore increase velocity.
Comments
As an outsider, it's easy to assess a system, this is often referred to as 'Beginners Mind' or simply, a fresh perspective.
Lean can help with this using tools like Value Stream Mapping to visually show how the system works and where the waste is.