Is how you have been doing things working? Have you been successful meeting all of your deadlines and satisfying all of your customers? Is this the way you have always worked and are you planning on working with other software developers with slightly different expectations of you?
I could give you lots of recommendations about how I personally would be doing things, but the question really is what you and your team feels really works for you. If you are asking these questions merely out of interest, then perhaps you aren't yet ready to change the way you do things. If on the other hand you have been feeling that you're tasks and workload have been getting the better of you, and you feel that they way you work isn't working, then perhaps you need to review your methodology and deal with these problems at a much higher level first.
Planning tools aren't going to help you to decide what needs refactoring. Those tools are merely there to help you to organize your work and parcel it out according to your preferred development methodology.
On the subject of TDD however, if you can't see how you might use it, then you either do not test your software enough or at all, or you have the most rigid testing regimen in place that it belies your need to unit test. TDD in itself is a very different way to write software in that you decide how you want your system to work, and before you implement it, you define how you will test it, then you write your code to pass the tests. It provides a means to streamline what you do, and shifts the focus from testing that your code works before you deliver it, to delivering working code confident that it already works.
If you feel a need to provide diagrams to show how your systems work, ask yourself where the value will be in producing and maintaining all of that additional documentation. Sure, it can be useful to document how a particularly difficult to define system works at a high level, but the more detailed your documentation gets, the harder it will be to maintain.
From the content of your post, it sounds to me as if you haven't really learned HOW to write software. If this is the case (you may be new or self-taught), then I would recommend at a minimum the following reading:
I'd also recommend looking into Behaviour-Driven Development as an alternative to TDD. Learn how to write software without adding piles of additional and wasteful red tape that you may not need.
What makes a software developer professional is how you manage your relationship with your customers, how you approach problems, and how innovatively you solve them. Also, it's how you work toward minimizing the clutter in your code, how thoroughly you test and how quickly you adapt to change, how you manage your workflow, and how you keep up with commonly accepted industry best practices. Well, there's obviously more to it than that, but it's a place to start.
