Google Gemini - "Create an ink drawing of a person looking at interdimensional chaos"
One of the most useful skills I’ve developed as a consultant is telling Regular Chaos apart from Big Deals.
It’s a useful skill for any software engineer, especially us consultants. Everyone has their own quirks. No team, company or process is perfect. As an engineer, you have to know when to dig in your heels and argue for change, because you can’t do that for every bad practice. You’ll drive yourself crazy if you try to fix every possible deviation from the “ideal” software development process. Don’t try to control things outside your power. Control is an illusion, anyway.
Also, trying to fix every little thing burns credibility with your coworkers. It may make you insane that every bug ticket does not have clear steps to reproduce, but if QA thinks it’s fine and management thinks it’s fine, it’s fine. Save your influence for Big Deals.
A Big Deal is different from Regular Chaos. The latter is dysfunctional software development practices that are annoying or slow things down. Big Deals seriously hurt your ability to deliver a project or succeed at your company. They literally prevent you from succeeding.
For example, imagine you’ve joined a new team that seems a bit chaotic. They claim to follow scrum, but story and bug tickets have one sentence at most. The QA test environment regularly goes down, sometimes for hours. There’s no continuous deployment. When bugs are found, they’re added to the sprint with the expectation that they will be completed in addition to the previously planned sprint work.
None of those things are ideal, but I would classify them all as Regular Chaos except for the last one. Adding stories to the sprint without taking anything out is a Big Deal.
Increasing sprint workload on the fly is a recipe for one of two things: overtime (which you should never give managers - too addictive), or missed expectations. If you limit your work to 40 hours a week, as you should, you’ll absolutely get pulled into a meeting where your manager will ask in a concerned tone if you’re having trouble meeting expectations. Never mind that those expectations are insane! You aren’t meeting them.
The best way to handle a Big Deal is clear, open, direct, honest communication. Disarm the bomb as soon as you can. In our example, you could use your happiest, nicest voice to tell your manager that you’d be happy to work on whatever was added to the sprint, but you’re so busy this week and what story would they like bumped to the backlog?
(If your manager does not accept this solution, you may want to get advice from other people at the company. Worst case, start brushing up your resume).
Differentiating Regular Chaos and Big Deals seems simple, but it requires you as a developer to always ask, “Is this going to seriously impede me or the project, or is it just annoying?” You have to let go of a lot of annoying practices with the understanding they are ultimately not going to stop you or the project from succeeding.
Again, seems obvious, but some of us have had to learn this the hard way 😅.