Getting a Quick Feel for a New Software Team

I deal with many different teams and many different companies. I see a lot of teams not get the benefit of known techniques and fail to evaluate and improve. There's some check-lists out there that are used to evaluate a company/team before joining it; but I find the lists to be deeply rooted in the past. They detail such fundamental things that knowing the criteria on the list really doesn't tell you much about how your time with this team will be or your role within it.

There's so many low-level features within software development team to aid in successfully delivering software. But these low-level features are part of higher-level initiatives that if absent make the lower-level features almost moot. "Do you use source code control?" for example. Sounds like this is a fundamental part of being able to delivery quality software; and it is. But, on its own it doesn't really do a whole lot to help the team deliver software. Is the code put into source code control using accepted design practices? Is the code put into source code control in a timely fashion. Is the code put into source code control not impeding other people? Etc. etc. etc. "Yes" to "do you use source code control" without any of other initiatives that follow-on doesn't give me a warm and fuzzy feeling about getting on the team and focusing on software value and not spending a lot of time on, or stuck in, process.

Over the years I've been on many teams hired for a specific role that changed drastically almost as I began working with the team. I've observed many things about many teams and have come up with some things I like to find out about a team before I start so I can better gauge the type of work that I'll be doing and how successful the team will be fulfilling their goals.

Does the team:

have a known product owner/sponsor,
have a cross-functional team 6-9 people in size,
use appropriate tools,
foster SOLID design principles,
use continuous integration,
use continuous deployment,
foster communications with team members and stakeholders,
have a known and managed process and visualize workflow,
evaluate and improve process as a team,
have new candidates write code in their interviews,
have a plan that limits work in progress,
have a plan that orders or prioritized tasks;

and, how easy is it to change to start doing any of the above items?

"Do you use source code control" is covered by "Does the team use continuous integration" as it's not just about using source code control, it's about a process that can't function properly without source code control.

And, for what it's worth, this list doesn't tell you whether you should work on a team or not; it just tells you the type of work you will be doing. It's up to you to dig deeper and decide whether you unrealistically want to limit your work to a specific or a small set of roles. I would only use the last question as a acid test of whether I would join the team or not. If they are not willing to improve, there's not much I'm going to be able to do for them.

What do you look for in a team/project?