Lets just try it

Years ago, a client said, "Let's just try it for a month and see how it goes." That week, I had a drink with my former boss, and he said, "Oh, that's a trick. He knows it's harder to change the process BACK but easier to sell it this way. You got played."

My former boss was spot on. The change was to go from async Slackbot standup reports to synchronous Zoom meetings. Several years later, not only did we still have Zoom standups, but many on the team had daily and a couple of weekly ones. It contributed to a lot of context-switching and slowed down the project noticeably and immediately.

It is not my intention to rail on meetings. That's for another, much longer blog post!

We'll just leave this in for a couple of sprints

Another team I worked with needed a one-off feature flag for a rush request from an important client. Instead of implementing a real feature flag system or using a third-party service, we were asked to hack in a Django setting for this particular customer's unique ID with the promise it would be removed, or we would implement some real feature flagging "in a couple of sprints."

You know where this is going. The one-off flag was still there years later and was there when the project was scrapped due to not hitting its goals. However, it didn't meaningfully impact the project in any way.

But trying things is good...

Yes, trying new things in an effort to improve is necessary and the basis for all real progress. The hard part is having the fortitude to push back on changes that don't work.

The harder part is being able to tell the difference in the first place.

Research shows that it takes about 21 days to form a new habit. Once solidified into a habit, it takes effort to overcome the inherent inertia of the new process. Conversely, trying something for a day or two can easily yield misleading information. You could have done more yesterday because of better sleep and not your new fancy issue tracker labeling system.

How to tell the difference

Here are some methods and tips you can use to make better decisions on when to push back hard on trying something:

1. Establish the metric(s) you'll judge it against upfront. Otherwise, how will you tell if it's working?
2. No metrics that make sense or you're too lazy to capture them? Ok, then it's a gut decision and more guts are better than one. At the agreed-upon time, have the whole team vote for the change to stay or go and require a 2/3rds majority to keep it. If it's not obviously good or even just not liked by the vast majority of your team, why do you want to keep it? Smells like ego or a personal preference to me.
3. Is it reasonable to assume the upside is far greater than the downside? While lots of 1% improvements add up over time, a 25% risk for a 1% gain is usually not worth it. Avoid these entirely.
4. Consider the change holistically. It may be worth trying if it's a 1% slowdown for one team member once a week but a possible 5% boost for several other team members. Note this works conversely for managers. A 10% speed up for that report you must do weekly should not slow the rest of your team down 1% each.
5. Horse trade. We'll try your idea for a month if you'll try scraping/changing this other process that gets in our way. The net effect of these two changes could be a win.

Obviously, don't push back on all changes just because they are changes and you don't like change but DO push back on changes that aren't either demonstrably positive or embraced by the majority team.

Or maybe just try it for a month?

Need help optimizing your development team’s ability to get shit done? Frank and his team at REVSYS can help guide you to 2X the velocity you’re seeing now.