As another responder, Trevor, has said, it would be ideal to get consulting from someone experienced in Scrum to lead your graphic design office in taking up the most useful aspects of the methodology.
That said, I recognize that not all companies and organizations have the resources, and smart people CAN learn from books and from others. So to that end, some thoughts towards answering your questions:
Why would you apply this to a design organization?
The heart of Scrum lies in the constant inspection and iteration. The reason for this is to combat the problems that arise when a large software project is planned at once and executed subsequently, and then at the end when the users finally use the software they realize the planning was misguided. It is far better to inspect the product regularly and adjust the plan along the way. If you have the following issues, I imagine Scrum could help with your design work:
- Do you have issues that arise when you make an early design plan, apply it to a large amount of deliverables, and then discover the client doesn't like the design in the first place?
- Is designer productivity regularly hampered by frequent incoming requests and changes from the client? Do all designers suffer equally from hazarding these requests?
- Is there a lack of communication that misses opportunities for all designers in your organization to learn from each other?
- When there are roadblocks to getting something done, do designers have an efficient method to get past them?
Think about those questions first, and depending on the numbers of "Yes" answers you give, decide whether it makes sense to continue investigating the application of Scrum to your design group.
Now, let's say you still want to. Let's also assume for now that for various reasons you must work with the team you have and are not able to add and remove members to fulfill the different roles in Scrum. What next?
How would you apply the constant inspection principle to a design group?
You probably would want to pick a small deliverable that would give a sense of the design style chosen, deliver that to the client before engaging resources in the follow-up deliverables, and then adjust your plan according to the client input. In your example of folder, stationery, identity, website, etc., you may start with one of those that can be completed in a deliverable format in one sprint, and then iterate after you get feedback on that first one.
Who should be the Product Owner?
For it to make sense for your organization to model the Scrum behavior, you would want someone on your team who can represent the needs of the clients. This person would then be doing the vast majority of the client interaction, from gathering requirements to sharing mockups to delivering products. Is there currently a person in your organization who does this, or do you all share this responsibility? If you all share it or it doesn't make sense for one person to be this point of contact, then this part of SCRUM may not make sense for you.
Who should be the Scrum Master?
For this part to make sense for your design organization, you would want to make use of someone's skills in organizing, planning, and communicating. In a software project a major part of the Scrum Master's role is to be the gateway to the dev team, increasing their efficiencies by reducing interruptions and keeping them focused. If that will be beneficial to your design process, then you should have one of the designers take the lead in triaging incoming requests from the PO and in facilitating the execution of tasks.