Positive demeanor need not mean dealing with only the positive things and ignoring or hiding the negative ones. I second @Chris in that one should keep a more or less healthy balance between focussing on positive and negative things. That is, make sure you do praise positive achievements and in general, reward team members in some way whenever they do something you want them to keep doing. The easiest and most efficient reward is a sincere "thank you, you did a great job!", but if you have a budget, you might even want to consider gamifying your development process more explicitly.
Another important aspect is that even a fault or problem can be pointed out in very different ways. E.g. a team lead may
- shout in front of the whole team: "Joe, you broke the CI build again! That's already the third time this sprint! From now on, you must pay a fee of $nnn every time you do this!"
- do the same but in a one-to-one with Joe
- say in the team retrospective: "the CI build got broken 3 times this sprint - to me that means we failed our sprint!"
- say in the team retrospective: "the CI build got broken 3 times this sprint - is there a systemic problem behind it? Can we as a team do something to avoid similar problems in the future?"
- say in the team retrospective: "the CI build got broken 3 times this sprint - that's a slight improvement over last sprint when it was broken 5 times. Does this mean we are really improving, or is it just statistical noise? Can we as a team do better and get closer to zero broken builds?"
To be clear, I am not in any way implying you are doing it wrong, just giving examples to somewhat demonstrate the gamut of choices. Some of which are - I think we can agree on that - more or less destructive and not efficient in actually solving problems and helping the team bond, while others are more effective and yes, positive in these regards.
One can point out problems to blame persons, or explicitly avoid blaming and focus on solving the problem instead. Problem solving may also be attempted purely by rules and punishment on one end of the scale, or by asking open-ended questions to guide the team towards thinking and acting together, to identify root causes and work towards eliminating these.
Similarly, one can present the same problem towards e.g. higher management in different ways. And it also helps to understand better what their concrete expectations are. It may even be that what you consider technically imperfect is "good enough" for them. In such a case, you may still decide to prove them why it should be improved or fixed, e.g.
- "module A contains lots of very bad quality spaghetti code, so we should refactor the code and add unit tests to make it cleaner.", or
- "module A is very hard to maintain and extend, so we should refactor the code and add unit tests. In my estimates, that would cost us about 4 person days in the short term, however in the long term it would slash the implementation time of upcoming features X, Y and Z by 30%, that is 6 person days. This is a net saving of 2 person days within 4 months!"
These two examples talk about the same problem, but the latter one is probably regarded by business people as more convincing and positive. Being positive may simply mean that you are focusing on solving the business' problems and helping them deliver value to their customers, even when talking about a software / process problem.
But (depending on company culture and managers' personality) you may also follow the adage "it's better to ask forgiveness than permission", and plan the needed refactoring into your regular tasks anyway, without bothering business. If the team agrees it's a must, you just do it (maybe in small steps over a longer time period), then present the results afterwards - again, making sure that it is presented in terms they can understand and support. Telling your managers "oh and btw we improved the maintainability of the system and fixed n bugs while developing this release" sounds way more positive than repeated complaints about "the code is hard to maintain and full of bugs".