We worry too often about what will happen when it breaks. What if it’s not perfect? What if it’s not seamless? Make it break. When it’s broken, you have to fix it, you have no choice. A car with a punctured tire is very different from one with a slow leak – the slow leak keeps you going to the gas station to get it refilled, a puncture forces you to fix the root cause.

The best thing about writing code is the immediate feedback. It works or it doesn’t. Your code pumps out oodles of value or it returns bugs. Bugs are great, they never go out of style and you get the same level of response to what you are doing – immediate feedback as to whether you’re on the right path or the wrong one. Never fear the bug, fear the program that has no bugs.

“We don’t do it that way.” “We don’t need all that.” “We’re doing just fine.” “We’ll figure it out when we get there.” “We’re switching gears to this, forget what we said.” These are all signs of a delivery system that is tilting on the rails, about to careen.

Doing everything differently for every project isn’t going to help you move faster. Redefining your methodology during a project is never going to work, that’s an outside-of-project task when no project will be affected. Tweaks are good, but changes are not good. Tweaks – “Let’s log these types of issues as bugs instead of tasks” Changes – “Let’s stop using sub-tasks and stories and go to epics and tasks” Your methodology might not do one…