How to survive SCRUM
SCRUM incentivizes tech debt
SCRUM switches inward motivation to external. Developers crave to close tickets to get the points. Sprints have near-sighted focus on getting business stories done without caring about cutting corners. Cutting corners becomes tech debt. Programmers become lazy. They become machines that follow orders for short term wins. That’s the first stage of becoming a commodity. Eventually the goal is to replace code crafters with drag and drop programmers. This will make it cheaper to build software since it won’t required highly skilled professionals in order to achieve great quality software. That will allow to fulfill the programer job demand faster than ever and decrease the salaries.
Are you passionate about learning new coding skills and writing beautiful code? Do you get dopamine rush after solving problems? Wait a few months after being in SCRUM sprints. You might even start to feel that coding isn’t fun any more. You might even consider doing management instead. Sprints are like being a mouse in a wheel. Always rushing to complete sprint after sprint. Sprint induces the near-sighted focus that makes us lose sight of the bigger picture, the dream.
To survive as a code crafter I would focus on developing tools for programmers instead of developing programs. I would refuse to give up quality for sake of “getting shit done”. Once getting the habit of cutting corners it is hard to come out of it.
Close tickets when they have a quality that makes you feel good about yourself, instead of closing it when it has the minimum quality to make it work. As Eric Elliott said, “Ship when it’s done”.
Pay tech debt since it can bring a company to its knees. — Robert Cecil Martin (aka Uncle Bob)
There’s a sweet spot between being a perfectionist and being too practical. If there is no tech debt then you’re a perfectionist and you will never ship code. Become too practical and you will end up being a commodity programmer replaceable and stuck in a low wage.
Even if coders are technicians, that doesn’t mean we should not have vision. Our vision should reach farther than a sprint. We should be more involved with the business people so we get a richer context of the requirements. A lot of the context is lost on the transfer from a business meeting to a user story.
As a coder we should visualize ourselves and our teams in the future. How would we want our tech stack to look like? Let’s increase DX (developer experience) on our code base and tools. Good examples of projects that are caring about DX are the programming languages Eve, Elm, Ruby and EcmaScript Next.
Which other things do you value? It is important to invest brain hours in subjects that go far beyond a sprint scope. We’re not only sprint ticket closers. We have to take control of our destiny by having a tech vision and mission aside of the business mission. That would help us meet the long term business goals faster. Even if in the short term it might seem like we are indifferent of the Lean Startup culture (aka MVP factory).