I use Sequel Pro on my mac for all my querying needs, but one thing MySQL Workbench does (aside from modeling) that Sequel Pro can't touch is administration. Seeing currently executing queries, benchmarking them, watching the slow ones, force killing any that are taking too long, viewing table locks... All stuff I didn't care about until I had a really really big MySQL DB, but once you do, it's indispensable.
A lot of people try to make UML out to be more than what it is. At the end of the day, it's extremely important in a team setting to put your data models into some form of documentation that everyone can look at and quickly understand, and UML just happens to be a popular format solely because people were drawing their models that way already and someone came along and standardized it. So the main take-away is that it's the data model documentation that's important for the success of a data-driven team project; and if UML is how you do that, then great. But UML isn't responsible for your success, the fact that you're documenting your work is.
Agile is another broader concept. The base idea is that you set up a continuous integration (CI) environment. You write code, and for everything important to your app, you write additional code to test those functions. Then you set up a CI server like Jenkins, or use something hosted like Travis. When you commit, your CI environment runs your tests and lets you know if anything fails. If nothing fails, you have your code immediately deploy to either a staging environment (if user testing is necessary) or production. Once you have that environment set up, the other half of Agile is scheduling your work into sprints. Have everyone on your team working together in one functional area of the app, continuously integrating all the new code, and finishing that functional area in a set time period (usually two weeks). Then you move on to the next scheduled sprint. Sprints should give you enough leeway for things to go wrong or for developers to revisit/replan a certain concept that doesn't pan out in the coding stage, but if things start going badly, there's usually a mutual understanding that people are burning the midnight oil to hit the sprint deadline. As such, it's a model popular with startups and despised by 501 Developers
As for me, I'm a fence-sitter. I think Agile is great as long as:
- The team can't be interrupted with other work, ESPECIALLY when that other work takes an amount of time that can't be easily predicted. You can't hold programmers responsible for deadlines that can become impossible to keep without some really unhealthy and morale-killing practices.
- There's an understanding that there may be a rare case in which the programmers will discover an issue with the plan or a service that needs to be redesigned to ensure a high-quality product, and in that case, laying different sprint schedule boundaries is acceptable.
- There's an understanding that changed requirements or miscommunicated requirements will result in sprints being changed to not destroy developers' lives.
(I've been on the bad side of Agile on more than one occasion