Making Change a Habit

I adopted a new rule in 2000 that states, "If you think the problem can be solved by just trying a little harder, then you have the wrong solution". We spent decades of wasted time telling ourselves to just try harder to write tests, then TDD came along and it was obviously a better answer.

The try harder admonishment is an endless, repeated, diatribe about of our personal failures and how we should just buckle down and be better. Stop trying harder and start thinking.

I am not saying that, on an individual level, we don't have things we can do better at, and need to be pushed and cajoled into doing something about, but as an answer to an industry of professionals that work hard to build the best solutions they can, "try harder", is wasted breath.

Some things we here today are "Developers just have to try harder to make their code secure", this will never happen so just stop saying it. Instead, change the process to make security a primary focus on every team. Add a security engineer to every team who only, reviews, writes tests and verifies a product evolves appropriately. Enterprise level security initiatives are valuable but are not the full answer, as evidenced by the hacked reality we see every day.

Have you heard this one; "We have to try harder to share information from Scrum of Scrums with the rest of the team". I get that some of you probably do this well, but most do not, and the solution of trying hard doesn't work. Getting the right information into the right minds at the right time is an adventure in frustration. However, allowing for time-to-share and getting how-to-get-information concepts shared is much easier. The human brain works well in a limited number of prescribed scenarios and no-everything-all-the-time is not one of them. Optimize focus, intentionally limit sharing till required and allow time for understanding.

What about from your ops team; "If developers would only try harder they would understand the operations requirements and build the products we could use". Does your ops team hate you? If you are doing it right, a member of your ops team is sitting next to you for some hours of the day talking to you about what they will need to operate the feature you are adding. DevOps is a hard change, do it. Add operational intelligence as an aspect of every feature you implement with acceptance criteria and functional tests. Think of it as BI for the operations teams.

Has  your business every asked you to try harder to get BI reports out faster? "Why does it takes so long for the reporting about a feature to come out after the feature is in production? BI teams and dev teams are usually separated. This doesn't work. Every feature has a BI impact and needs consideration at the time the feature is implemented. Release your feature and the BI reporting as one package.

We have a support desk that answers the phone every day, and they hate us. "Oh please try harder to ensure we can answer customers questions. Just try harder to tell us what you are changing". How do we get support teams, with the hours they work, synchronized with feature development activity that we are working on. Send an email on release day? Sure that will work. "Oh, by the way, that button you used to use, just moved, good luck."  I don't know what the next change needs to be for this one, yet.

If you and your team want to be better, first change how you do things, then measure, and then change again. If you are not changing, you make it hard to change, and inevitably become a lagger in the ways of our ever improving approach to our profession.

If you believe that change damages teams because it introduced confusion, then you see change as an obstacle and will never master it. Don't use change as a tool, if you are not ready. With change comes chaos, and only teams experienced with change know how to own chaos. If your team members do not communicate, do not challenge each other and are not willing to be part of a solution, then change will destroy them. First empower the team, then master change.

On an experienced team, what happens is, a team member sees a change, and reacts by calling the team to order and facing it, they argue about how to address it, devise an approach to it and then reengage to the mission.

Change does disrupt, but since it offers the opportunity to grow, mastering it must be a primary goal.

Change is exciting.