TL;DR

Does running an agile squad means all squad members can do any work or work should be divided based on skill set?

You are creating a false dichotomy. People are not cogs in a machine. They are not interchangeable parts. The goal is to create a cross-functional team with T-shaped people rather than populating a group of random individuals with I-shaped skills.

Analysis and Recommendations

Analysis

You currently have a group of assorted people who are I-shaped. They are each so specialized in their skills that they cannot really be expected to:

1. Fill the role of [product] Developers on the Scrum Team.

   Scrum has no team hierarchies or other roles besides Scrum Master, Product Owner, and Developer. Your team seems to have a surfeit of people, but they were not selected to collectively be "Developers" in the Scrum sense.

2. Take collective ownership of the product development because they lack the cross-functional skills to collaborate on a single Sprint Goal at a time.

   Scrum requires that each Sprint has a singular, unifying Sprint Goal. The whole Scrum Team is collectively responsible for delivering it. Two or three of your Developers are unlikely to see their role as collaborative or take ownership of a common product increment; I-shaped people usually function best in organizations where people "toss work over the wall" at each other, or work on independent and unrelated activities. There is absolutely no downstream work within a Scrum Team, but you've hand-selected a team that most likely expects to work sequentially and then pass their work downstream to the lone programmer and then the unfortunate single tester. That is in no way "agile," much less Scrum.

3. T-shaped people aren't interchangeable. They're simply sufficiently cross-trained to collaborate on the same work increment rather than forced to work indepdently of one another.

   In Scrum, the idea of assigning work to people in sequential or parallel silos is antithetical to the process. The Scrum Team may have many different skills required to deliver each Increment, but they are expected to self-organize and self-manage the work needed to reach each Sprint Goal. If you have "designers" and "architects" who can't program or don't understand test-driven development, how can they work as equals with your programmer and tester to deliver each Sprint Goal?

   The short answer is that they can't. You will have people estimating only their own personal contributions, rather than the level of effort for the team for each vertical slice of value. They will also we working on a narrow piece of what each person knows how to do rather than swarming over the singular objective for each Sprint.

Recommendations

You have a very unbalanced team. If you can, refactor the Developers on the Scrum Team so that you have:

1. Developers with programming skills and at least some TDD/BDD skills.
2. Developers with design skills who understand how to work incrementally, and can iteratively collaborate with the rest of the team on just-enough and just-in-time design to meet the unifying Sprint Goal each Sprint while understanding the level-of-effort involved for the whole team to meet the Definition of Done.
3. Developers who understand that agile architecture is about emergent design, and know enough about testing, programming, and UX/UI to delay architectural decisions until the last responsible moment and create just-enough architectural runway to support the current unified Sprint Goal and its associated Definition of Done.

In other words, you have to rethink whether this is a team or a collection of specialists. What you have now is not agile. You can either refactor your team's composition from the beginning, or expend time and effort—yes, this will carry a cost to the project whether you acknowledge it in your project plan or not—by putting cross-training and whole-team agility training as evergreen Product Backlog and Sprint Backlog items until your team is actually able to function as an a Scrum Team with T-shaped Developers.

• If you use the team you have now, you need to apply a fudge factor to any estimates to account for the whole team of Developers lacking cohesion and to give them the time and opportunity to learn enough of each other's jobs to estimate per-Sprint outputs (rather than just their own) and to collaborate effectively on a single, coherent objective each Sprint.
• If you replace the team you have with more cross-functional people, then your Scrum Master can instead support them in finding their own collaboration patterns with the foreknowledge that they can assist one another and work together on a common set of deliverables that form a single overarching Sprint Goal. Each Sprint Goal is an incremental or iterative step towards a single Product Goal, and if the team can't do this collaboratively then they can't be collectively responsible for delivering the product Increments that collectively define each Sprint Goal.

If you can't fix your team, or restructure your project to actually be agile, then you have an organizational problem that you need to address.

Fix Your Organizational Processes

Scrum Teams are intended to be long-lived teams that work on multiple projects over time. This allows them to be a team and not a collection of individuals.

If you are trying to adopt Scrum ab initio, you often get "teams" like the one you're describing. This is basically putting lipstick on a pig and doing traditional waterfall development but slapping a hip new agile label on it. Real agile adoptions require changes to the way teams are composed, work together, and get managed by line management and senior leadership.

You can't undo years of hiring for I-shaped people, but you can make the costs of using I-shaped people or building teams without cross-functional skills visible to stakeholders. Scrum doesn't promise you will do anything faster; it just promises to make the cost of work, change, and process visible and transparent so that the organization can continuously improve.

Without executive support for the values and principles of agility, and without their support for switching from utilization- to outcome-based metrics, the project will not produce the desired results. This will ultimately be blamed on the members of the Scrum—deservedly so if they don't take ownership of their own team composition or raise process issues like team resources and the (lack of) availability of framework training or cross-functional skill development—while management often things Scrum is a technical thing and refuse to change how they leverage the framework, interact with the Scrum Team, or meausure the progress of the project.

Senior Leadership is Always Responsible

In the end, executive management is always 100% responsible for the success or failure of a project. Tone at the top is essential to agile adoptions, and real agile transformation requires changes in leadership style as well as spooning around new names for existing roles.

In short, Scrum is a framework with room for both the Scrum Team and the parent organization to continuously inspect-and-adapt. Unless that happens, the process will break. If executive leadership breaks the process, then they get to keep both halves. Q.E.D.

Do your best to support this transformation, but if you need help get buy-in and support from your leadership team. If your organization is struggling to adopt Scrum, hire an agile coach or make routine framework seminars, lunch-and-learns, or other ongoing training part of your routine cadence. In many cases, poorly-implemented Scrum will actual be less effective than poorly-implemented waterfall. Don't set your team up for failure this way; sweeping obvious problems like this under the rug is why more than 68% of IT projects fail. Don't be a statistic!