Sometimes you don’t know where your team sucks. Here are some smells that can destroy your team culture:
1. Non Coding Architects
If you have these type of job position in your organization you should really think about getting rid of it. The team should define the architecture together. If it comes to cross team architecture, send one or two people from your team to a meeting with other teams. It’s just a waste of resources to have a guy that makes the theoretical discussion that got later overruled by the reality.
2. Committee Driven Development
Some organizations have a committee of stakeholders that decides what to do next. This smells like you don’t finish things probably. You run to the next project without finishing up the old one. If you have delivered a new feature or even a project we all know that the real work begins after that. You need to fix bugs and improve the new feature by collecting feedback from your customer. Involve the team in decisions not just a committee!
3. Developer Primadonna
Do you have a primadonna on your team that thinks technology decisions are more important than customer features and works on implementing the newest framework which is not planned for this sprint? These ego manias concentrate more on the solution then on the problem (if there is a problem at all!). Look out for those guys, they destroy your team culture. Attention: Sometimes it’s hard to distinguish between a primadonna and a passionate developer.
4. The Perfect Software
You have to release one month later, because the software is not ready? You need to test more? You want to make the feature to be perfect? Looks like you’re afraid to release your software! It’s not that hard anymore to fix bugs after a release: You don’t have to send disks around, just push the changes to the servers or have the possibility to auto-update a desktop application. Concentrate more on deliver things than deliver perfectionism.
5. Quality is the job of the QA
In bigger organizations you have a QA department which is testing the software. Developers think that bugs got found by the QA and they just have to fix them. WRONG: It’s the developers job to make sure there are no bugs in the features! That’s why testers should just help with testing, creating test data and maybe help with automation. Quality is everybody’s responsibility. The developers should be accountable for their work!
6. No Shared Vision
The team has a different or none opinion how the software should look like in one year. Start asking around in your team if they have the same vision of the product. You all should have the same goal, otherwise you can’t be passionate about what you’re doing every day. You know if you’re back on track if you could send every team member to a board meeting or to a customer in order to talk about the future because you share all the same vision.
7. Featuritis
If your software has a lot of features and it’s very flexible, but hard to maintain you probably suffer under Featureritis. If you fix something in one end you brake something in another end. Maybe you can’t say ‘No’ to your boss or your customers. Please try to concentrate to do a few things right than doing a lot of things just alright. Try to branch your product and learn to say ‘No’ , but maybe you’re also missing a vision (see point 6)?
8. Addiction to Final
Your team can’t estimate anything until everything is sketched out in detail. Of course, they should know the whole story but they should also be able to estimate parts of the story. If this is your problem you’re probably still in love with waterfall. Gain confidence inside your team that you just concentrate on a small feature set right now and see if the rest is really needed at the end.
9. Legacy Team
You still stuck with the same process than 5 years ago? You haven’t changed your development tools in years? Looks like you are afraid of change. If your team becomes legacy and can’t see the problems anymore or don’t know how to change things you should do something. Software development has changed dramatically in the last 5 years, tools are in the cloud, we have the technology to release quickly and working from home to get things done. Get out of your comfort zone!
10. Process after process
You have too many restrictive processes if you need a signature to start with a feature. If you just added some getters and setters that has to be reviewed before the deployment or you your cool new idea will take 1 week of development but 2 month of justifying. These processes are killing your development speed and stopping you from doing great work. You should just switch some processes just with rules to follow.
Sven Peters 
Number 4 is a myth
I’ve been working for a boss, that wanted to get the software 100 percent ready with all features implemented and 10 times tested by another departement before launch. He was afraid of getting bad reputation within the organisation and wanted to make sure, that we’ve done everything to release without a bug.