Involve graphic designer in daily Scrum meetings

Question

As I explained in a previous question, our company is willing to introduce some elements of the Scrum method in our working process.

We have a in-house graphic designer, who is attached to the marketing part of the company, but feels more related to the technical team, as he also creates stuff and works with us in the production of the features of our online application.

Do you think it's a good idea to involve our graphic designer in our daily Scrum meeting? Have you seen it before? With which results?

Answer 1

Based on your statement "feels more related to the technical team, as he also creates stuff and works with us in the production of the features of our online application" I fully encourage him to join the daily stand-up.

The more important question is if he's going to join the team or not... there could be a great advantage to your designer being a full member of the team, sharing the responsibility for the team commitment, etc. My general recommendation is "yes, he should", but there are legitimate reasons why it wouldn't make sense. Please note there are MANY excuses why it wouldn't work as well, and as @Pawel recommends, you ought to experiment with it for 2-3 sprints and see if it's better for communication, or if it happens to hurt communication with the rest of the company.

Answer 2

First of all, everyone is welcome on Scrum meetings. You can even have CEO on meetings too. The only rule is that as long as someone isn't directly involved in a project they don't speak - they just listen.

However, from what you write your graphic designer works for your projects so he could perfectly suit daily meetings as a regular member. Of course it means that sometime he would have little to add, as he would be working on some marketing stuff but that's also important information for the project team. It means "Now I'm doing some other stuff so you should take it into consideration in your plans as I won't be able to do work for the team at the moment."

There's another thing as well -- if the graphic designer wants to join just take him to the meetings and treat is as an experiment. If it works for him and for the team -- just keep it going. If it doesn't think whether you want to change it or skip it completely.

It's always a question of time invested by an individual to attend the meeting and value he, and the rest of the team, gets. Personally I'd say that chances are good the net result in this case would be positive so I'd definitely give it a try.

Answer 3

The only challenge that I see in including other people in the scrum meetings is dedication. In this case, I'm assuming the developers who are part of this scrum team are all dedicated resources on your project. This means that 95+% of their time and energy is dedicated to the advancement of your project.

The question I have is whether or not your designer is a full time member of your project. Does this designer have other conflicting responsibilities. If so, then adding this person to the team may not be very helpful as you may be subject to sharing this person's time with other departments. In cases like this, design may take a back seat for your project.

Thus, the questions you would want to first answer are:

• How will you handle situations where the designer misses the meeting.
• How will you handle scenarios where a designer can't get the work done on time, not because of scope, but because the marketing manager wants this person to work on something else this week?
• How will the team dynamics be affected by someone whose contributions and dedication to the project appear to fluctuate from period to period?

If the designer is actually dedicated to working on your project, then I would strongly suggest including this person in the meetings as none of these challenges will apply. If not, just be prepared to handle those situations.

Answer 4

This is a great question about how to tailor scrum when you have external dependencies on other teams. In big enterprise projects (and in small ones), the best approach I've seen is to include a team representative if you have a dependency on an external team -- like work from the graphic-design team.

This can be the person doing the work themselves, but it's usually more useful to have the team lead, because they give bigger-picture stuff (eg. team member is spending x% of time on your work because of A, B, C other priorities).

Answer 5

I think too often the graphic design and UI elements of software projects is considered a non-developer task. I've found that renaming those team members (who do design and often generate html or CSS as a result) as front-end developers helps give them a defined role in software development.

If you have front-end devs who are enthusiastic I think you should definitely invite them to the daily stand-ups - whether they should be there will become quickly obvious.

Answer 6

Assuming that "he is enthusiastic" (as you said above), the real question here is what are the cons of involving him into regular meetings. I see the following:

• risk of overcrowding (especially if he is an active talker)
• security breach (if you have different "clearance levels")
• loss of focus (team members may start thinking about graphic design more than they should)

Answer 7

I'm in favour of this; a common complaint from 'development teams' is that come release time, they meet resistance from QA, DBAs, network admins, support staff, and anyone else affected by roll-out. IMHO, all these people should be represented in the 'product development team', not just the coders.

Bringing people into the daily scrum meetings saves the amount of time lost due to re-designs needed to address other teams concerns, and roll-out delays when other teams need to be brought up to speed - sadly their 'due diligence' can be seen as obstruction.

Bringing this into the context of the graphics designer, graphics designs are influenced by the ideas they represent (as ideally is marketing artwork), so the daily heads-up of what is changing in the logic helps them keep pace with changes, and avoid delays later on. Similarly, the other product developers will gain from input on what works from a artwork/marketing point of view, saving on redesigns.