🙇‍♂️ Thoughts on software development process

I was talking to a developer, over lunch, about some of the struggles the team I’m currently with is facing. I was telling him about the long hours we had to spend to deliver some work to the client, our code quality issues and the overall experience level of the team.

His answer: Well, that’s because you don’t do sprints and you don’t do SCRUM.

Let’s set this straight. Imagine your non-delivering, junior-riddled, no-BA, requirements-lacking, yes-sir-managed team is a fat person. Do you know what happens to fat people when they go on a diet? Not a lifestyle change/choice, just a diet. Any kind of diet.

THEY LOSE WEIGHT!

Putting structure into their eating habits helps them lose weight. It helps their body to stop retaining water, it improves their breathing, the heart rate goes down a notch, their skin looks better, their eyes are shinier.

The same thing happens to software development teams. I get so upset when I see people from the business end of software development, still fall for the stories they’re preached to, about SCRUM being the thing that solves all problems. Then they go and brainwash their teams with it. It’s only a thing you will later use to help you to utter crap like “Our velocity is going down, we need to have more committment/be more responsible/be more accountable!”.

Neverland is not real, there’s no magic, people can’t fly and there’s no crocodile with a big clock in its stomach, so quit acting like Peter Pan.

If your team progress sucks, don’t look for a framework that’s outside the team, look for problems within the team first. Actual problems! I bet you 9 times out of 10 it’s not the team that’s at fault. It’s either that requirements aren’t collected properly by the person in charge of that or that person is lacking. Or that work and progress are not made visible, and you just go and yell your requirements at the devs, to get them implemented. Or that you lack proper communication and follow-up skills and fail to properly gather status from your team and relay it to the client.

Don’t think that story points and 2-week sprints with fixed scope that you end up changing 2 days into the sprint because the client dreamt of something else and now you have to implement the new-new urgent-urgent task, is going to fix the issue. Or that the 1355 meeting types and Gantt and burndown charts will compensate for the fact that you fail at communication or at hiring the right people.

In conclusion, please stop adopting ludicrous processes to make up for your flaws. Everybody should be learning and so should you. You’re not spared of the effort of going through learning and bettering yourself. Don’t try to make others better, when you, yourself are broken. Learn about your shortcomings as a person managing / supporting the team, assess the issues the team is facing and put in place the simplest process as you can get by with. The English Common Law contains extraordinary examples of getting the facts right, gathering the evidence necessary to understand both sides and also consider the precedent one decision or the other would create. Incrementally adding things based on the size of the problems you’re facing is the best thing to do.

Image credits

Lisby — Edwin Sandys, Archbishop of York, and his wife Cicely Wilford

P.S. Say “Hi!” — https://twitter.com/@oprearocks