I've been recently asked to teach Scrum to a graphic design office. Why? Because they want to turn their services into quick deliverable products, and not lose focus on the current project they're working on. They want discipline, commitment and flexibility. So I thought of Scrum.

I've only read about Scrum so far, I must say. Also, my experience in project management is fairly poor. So I feel a little lost about when and where to apply Scrum procedures to effectively take the best from the framework.

Consider we are 4 graphic designers: Who can be the P.O.? The Master? Should I consider parts of a Branding project (Stationery, Identity, Folder, Website, etc.) as different sprints?

How can scrum be used in a Graphics design office?

  • 1
    Scrum is not an acronym. It's Scrum, not SCRUM. Edited everyone's posts accordingly. Please stop doing that now. – Lunivore May 27 '12 at 10:09

I'm a little confused as to why you've been asked to teach a method you've only read about, from a field you have limited experience in? Nothing personal against you in particular, but that's usually a recipe for failure. It's one of the reasons so many 'methods' get a black eye - someone with limited experience tries to implement it, and it doesn't work because they didn't know how to do it correctly, then they say 'we tried Scrum/Agile/Lean and it doesn't work".

Given how you've described it, I would forget about "Scrum" in name, and instead focus on what in your office needs to change to accomplish their goals (regardless the name).

Scrum is primarily a software dev methodology. Unfortunately the Agile/Scrum idea has been co-opted and seen as a general pm methodology. It's not. Certainly you can borrow some of the concepts (iterations, sprints, etc.) but I think what you're looking for is just a better way to manage and complete your projects. That could include tools for, Scrum, Agile, Waterfall, Lean or any number of other pm/management concepts. Don't get hung up on a name or method. Look at what needs to change in your current process to achieve the new goals, and use whatever you can find.

Having said all of that, if you're still committed to Scrum, then I would suggest finding an experienced coach to teach it correctly. There are too many nuances that are critical to success to think you can do it. I have 20 in the pm world and I understand the Scrum processes, but I wouldn't try to teach it to anyone.


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.


I would like to say some words to adoption of graphic/creative work and Scrum, because I work in a Scrum enviroment as a single UX designer.

For me it didn't work well with Scrum. For several reasons and the major, I guess, is, as mentioned from Trevor, Scrum is a software development method. Not one for creative work. Its about take a task, do it, done (which is represented by its columns). Thats how you code.

Design is mostly about doing something, forget it and look with new eyes on it - for getting a more objective taste. (Btw thats my way of working, others may differ) Thats not represented in Scrum. You can do this sort of iterations, but its supposed to be done next sprint, which is 2 or 4 weeks to go. And not a day or two.

Actually my design tasks were sticking around at in progress column, because it needed a day left. It was ridiculous and not good Scrum style, but I have no idea how to solve this problem. Even that often mentioned Lean UX doesn't help as its about making less paper, but not about doing UX on Scrum board. Having a lot of talks with my teamleader (who is Dev) couldn't help either.

Anyway, I found an interesting agile approach, which is more close to design work and its called Kanban. Coming from manufacturing (Toyota), it covers analysis, raw design and fine design as well, because you can add as many columns as you want ;) I couldn't implement it at work so far, so no idea if its so promising as Im saying.

Check some of these threads and the links inside for more about Kanban: What is Kanban?, Kanban books and Kanban threads

  • Um, software development is creative. It does have some unique constraints, for sure, but it's highly creative. If it was "take a task, done" then Waterfall would work. To illustrate the point, Kanban approaches originally came from a production line - highly predictable and repeatable - and we've had to tailor them massively for software development. Nothing predictable about what we do. – Lunivore May 27 '12 at 10:13
  • @LUNIVORE Sorry for that, I know dev is creative as well. But different, may be rather on the rational side of creativity (aka problem solving). The iteration cycles are larger in Dev, not inside a task like Design - thats what I was refering to "Take task, done". However, ways of working are far different. Kanbans pull logic, what I think, suits better for design work: You can await tasks until work on in production chain. And as you say it - predictable and repeatable are actually most design task (seen from makro perspective) – FrankL May 28 '12 at 6:53
  • Hah, if only our work was rational. We sometimes behave as if it is, but it only leaves all the uncertainty till later. We also get compiler feedback (seconds), unit tests (minutes), system tests (minutes), tester and PO feedback (hours) - little iterations too. We frequently discover new work that needs doing, and use Kanban to make the larger feedback loops visible and stop ourselves from being overwhelmed. You might find this interesting: lizkeogh.com/2012/03/11/cynefin-for-devs - I describe predictability vs. emergence for devs here but it's applicable to lots of stuff. – Lunivore May 28 '12 at 8:19
  • @Lunivore Sure. Still I think there is a difference. May be in the "why". Why are you coding it like this? Because it makes this and that. Why are you making this button glossy? Because it looks better. The purpose for the highlights isn't functional, but emotional. Often you make two slightly different versions for evaluating next day. - Thanks for the link. Good read. I like your article and cynefin framework looks promising. I bet one could break down design work into this quarters as well, but I have to think about it. Needs to rest and digested ;) – FrankL May 28 '12 at 10:33
  • Ah, we have issues of internal design and maintenance which are frequently emotional - and we often get asked to sub for real UI designers. I wish they'd stop that because devs aren't particularly good at it. Upvote for mentioning Kanban, and thanks for the interesting conversation! – Lunivore May 28 '12 at 10:43

Your Answer

