The Seven Deadly Sins of a Software Team

Pride, Envy, Gluttony, Lust, Anger, Greed, Laziness – being a child, you were taught that those traits are BAD and should be avoided. The purpose of this post is to actually confirm what you have been taught.

Frankly speaking, repeating this at work is also BAD.

Pride

For the team – it’s often tempting to give yourself hugs for a job well done. But how do you know that something is well done? According to what metrics? Are you sure that you have them set correctly?

For the leadership – you think you are doing your job perfectly. Yes, there may be some aspects that could be better, but the process has already been set a bunch of years ago, and it is quite good. Are you sure that organizational flexibility will surely undermine your methods? Even if it helps your team, department, and/or entire company?

Envy

For the team – the envy of other products often leads to feature creep across products. In such a case, you should ask: “Do we need it?”. The killer feature of any product is simplicity, but it’s the hardest thing to design. Plus, it’s easy to lose focus when you’re constantly looking at what other companies are doing. And the ability to do one thing but do it really well is still underestimated by many teams.

For the leadership – you might envy other projects that have a clear vision and strategy. They have a clear direction in their work and an understanding of how the work they do is related to the larger goals and objectives of the company. They just have it all and seem to be happy. But couldn’t you find something interesting in what you already have, work on improving what needs to be improved, and stop being jealous of your neighbour’s 27-inch monitor?

Gluttony

For the team – It’s easy to forget that perfect code is never released. Then, as features pile up, programmers tend to lump together all the bugs of the past, resulting in a bloated, brittle code base that is too messy to work with effectively. Instead of stuffing plate after plate with new features, hold back.

Assess the quality and maintainability of your existing code, make refactoring a permanent item in your budget. Customers only see new features in every release, that’s true, but in the long run, they’ll be grateful that you washed that plate once.

For the leadership – you must manage the constraints of the project management triangle, which are budget, time, scope, and quality. If the leader suffers from “gluttony,” he/she can go beyond the triangle and destroy the restrictions. For example, taking more scope into development breaks budget or time limits.

Lust

For the team – modern programming languages are always adding new features as they develop. Today you have gigantic design patterns, and every few months, someone comes up with a new development methodology that will turn you into a god among programmers.

But what looks good on paper doesn’t always work in practice, and just because you can do something doesn’t mean you should. As Joel Spolsky says, “delivery (meaning release)” is a feature. Really important feature. Your product must have it.” Teams who have a lust for the tools lose sight of this inevitably.

For the leadership – market lust for your product can bring you huge profits. But software developers often crave perfection, which can cause serious problems. You can spend an infinite amount of time optimizing a very small part of the entire program.

Chandler (yes, that one) ultimately failed because they were building a product that no user asked for. By the time version 1.0 was released, the rest of the world had already moved to cloud and mobile devices.

Anger

For the team – sometimes, someone on a new Scrum team can get frustrated with learning to work in a new way and with the framework itself. Sometimes the Scrum Master finds it frustrating to see people doing something “wrong.” But it is important to restrain yourself and remember that people will learn better by making their own mistakes.

Scrum is a huge cultural change that requires patience and strong leadership. Remember that a good team has reasoned and established opinions about many things but also appreciates reasonable “adult” debate.

For the leadership – leaders define and communicate the objectives of the project, which must be achieved and be clear, useful, and achievable. A leader who has a “hot” nature can lose his objectivity and lose the team.

Greed

For the team – greed often leads to a focus on short-term goals, which leads to technical debt and long-term slowness. The more features we cram into a release, the harder it is to maintain the entire product. Especially with large clients, it is easy to bend over and “quickly” implement one or two features in a hurry and even not cover them with tests, which can negatively affect the product and relations with your client in the long term.

For the leadership – it can be tempting to ask the team to do more than their actual accomplishments show. “Can’t you just squeeze a couple more hours/story points into the sprint?” This should not be allowed because such permissions can lead to people spending less time on quality, cutting-edge cases, or even cheating by inflating estimates.

Trust the team to get the job done like a pro and use their real speed for what it’s supposed to do: predictably plan features and other tasks for the release.

Laziness

For the team – here, laziness is rather an apathy than just doing nothing. An apathetic team often has zero interest in quality.

For the leadership – leaders are the first point of contact for any questions or concerns that people in the company have before the issue escalates. A lazy leader causes a problem or issue to go unnoticed or unaddressed, which escalates into even bigger problems. Laziness harms the whole team and cannot be ignored.

On the other hand, a lazy team can be a good team because laziness can drive long-term efficiency. For example, if I’m too lazy, I could create a single sign-on function or write an automated deployment tool, or cover everything with automated tests, not to do it manually, etc. Laziness and scalability go hand in hand.