The Scrum practitioner community is fond of using three terms to describe the tradeoffs made in a software development project. They are:
What if your craft is not software development but organizational change?
This is the scope of the organizational change. I would define it as a function of number of people affected, how each affected person’s work must change, and how the affected person’s mindset must be changed.
This the quality of the organizational change. People resist being coerced to change as a natural instinct. An organizational change that is forced may garner compliance but it will rarely accomplish commitment. Commitment implies workers agree and would do it even if they were not required.
This is the time constraint of the organizational change. We need to get Agile by the end of the year. We need to re-organize all our teams to be co-located this quarter. Effective immediately, everyone needs to use the new TPS report cover sheets.
Professional Scrum Development holds to a consistently high, even uncompromising level of quality leaving the Scrum Team to flex on either scope or time. Committing to high quality guards a project and a codebase against the calcification that a build up of broken software and technical debt inevitably brings. Additionally, a strict adherence to craftsmanship ensures workers are encouraged, even forced to expand their personal mastery of necessary skills and aptitudes. Moreover, those workers receive the pride of their workmanship and are afforded the time needed.
Organizational change agents should hold to a consistently high, even uncompromising level of commitment leaving the those desiring change to flex on breadth and urgency. Waiting on genuine commitment from workers guards an organization from the false change, dishonesty and the division organizational debt inevitably brings. Additionally, a strict requirement for genuine leadership ensures managers are encouraged, even forced to expand their personal mastery of necessary skills and aptitudes. Moreover, those managers receive the pride of their workmanship and are afforded the time needed.
The next time you, as a manager, force your underlings to just, “Do what I say” consider it the equivalent of an irresponsible, untested hack made made in production code that will probably cause more defects than it fixes.