Safety to Change
It’s interesting to me, as I work with more and more teams, how nearly every problem companies face, at their core, have to do in some way, with organizational alignment and having more to do than they can possibly do.
Scrum solves this problem by creating teams that regularly deliver a increments of working software and empowering the them to decide how much work to pull in every sprint.
Simple guidance, but getting there is a non-trivial problem in most large organizations. These companies have people in functionally aligned silos with pretty strict management hierarchies and a slew of projects already underway.
Most organizations can’t even think about slowing down enough (initially) to write good unit tests or to automate regression, let alone learn TDD or try pair programming. Their structure and workload don’t allow for it.
Most people can’t even think about letting go of command and control project management, because if they let go of the wheel, the organization would spin out of control. As much as we’d like to think otherwise, they are right.
Killing inf-flight projects and aligning your organization toward value creation, is an act of bravery. You have to be willing to say no now, so your yes in the future will mean something.
You have to be brave to make radical change in your organization. You have to be willing to take personal risk. You have to compromise your own personal safety for the success of your organization.
And to me, that is what’s really at the core of most agile transformation work. How do we make our leaders safe to lead this kind of change? These people have mortgages and kids in college and don’t want to put that at risk.
But at the end of the day, sending a bunch of folks to training and adopting a few practices doesn’t really cut it. You have to be willing to lead change, you have to be willing to say no, so you can confidently say yes when it matters.