Enfoque Scrum para la oficina de Diseño Gráfico

Estoy un poco confundido en cuanto a por qué se le ha pedido que enseñe un método sobre el que solo ha leído, de un campo en el que tiene experiencia limitada. Nada personal contra ti en particular, pero eso suele ser una receta para el fracaso. Es una de las razones por las que tantos 'métodos' tienen un ojo morado: alguien con experiencia limitada intenta implementarlo y no funciona porque no sabía cómo hacerlo correctamente, entonces dice 'probamos Scrum'. Agile/Lean y no funciona".

Dada la forma en que lo describió, me olvidaría del nombre "Scrum" y, en cambio, me centraría en lo que debe cambiar en su oficina para lograr sus objetivos (independientemente del nombre).

Scrum es principalmente una metodología de desarrollo de software. Desafortunadamente, la idea Agile/Scrum ha sido cooptada y vista como una metodología general de PM. No es. Ciertamente, puede tomar prestados algunos de los conceptos (iteraciones, sprints, etc.), pero creo que lo que está buscando es una mejor manera de administrar y completar sus proyectos. Eso podría incluir herramientas para Scrum, Agile, Waterfall, Lean o cualquier otro concepto de gestión/pm. No se obsesione con un nombre o método. Mire lo que necesita cambiar en su proceso actual para lograr los nuevos objetivos y use todo lo que pueda encontrar.

Habiendo dicho todo eso, si todavía está comprometido con Scrum, le sugiero que busque un entrenador experimentado para que lo enseñe correctamente. Hay demasiados matices que son críticos para el éxito como para pensar que puedes hacerlo. Tengo 20 en el mundo pm y entiendo los procesos de Scrum, pero no intentaría enseñárselo a nadie.

Como dijo otro respondedor, Trevor, sería ideal obtener la asesoría de alguien con experiencia en Scrum para guiar a su oficina de diseño gráfico en la adopción de los aspectos más útiles de la metodología.

Dicho esto, reconozco que no todas las empresas y organizaciones tienen los recursos, y las personas inteligentes PUEDEN aprender de los libros y de los demás. Entonces, con ese fin, algunos pensamientos para responder a sus preguntas:

¿Por qué aplicaría esto a una organización de diseño?

El corazón de Scrum radica en la constante inspección e iteración. La razón de esto es combatir los problemas que surgen cuando un gran proyecto de software se planifica de una vez y se ejecuta posteriormente, y luego, al final, cuando los usuarios finalmente usan el software, se dan cuenta de que la planificación fue incorrecta. Es mucho mejor inspeccionar el producto con regularidad y ajustar el plan sobre la marcha. Si tiene los siguientes problemas, imagino que Scrum podría ayudarlo con su trabajo de diseño:

• ¿Tiene problemas que surgen cuando hace un plan de diseño temprano, lo aplica a una gran cantidad de entregables y luego descubre que al cliente no le gusta el diseño en primer lugar?
• ¿La productividad del diseñador se ve obstaculizada regularmente por las frecuentes solicitudes entrantes y los cambios del cliente? ¿Todos los diseñadores sufren por igual arriesgar estas solicitudes?
• ¿Hay una falta de comunicación que pierde oportunidades para que todos los diseñadores de su organización aprendan unos de otros?
• Cuando hay obstáculos para hacer algo, ¿los diseñadores tienen un método eficiente para superarlos?

Piense primero en esas preguntas y, dependiendo de la cantidad de respuestas afirmativas que dé, decida si tiene sentido continuar investigando la aplicación de Scrum a su grupo de diseño.

Ahora, digamos que todavía quieres. Supongamos también por ahora que, por varias razones, debe trabajar con el equipo que tiene y no puede agregar o eliminar miembros para cumplir con los diferentes roles en Scrum. ¿Qué sigue?

¿Cómo aplicaría el principio de inspección constante a un grupo de diseño?

Probablemente desee elegir un pequeño entregable que dé una idea del estilo de diseño elegido, entregárselo al cliente antes de involucrar recursos en los entregables de seguimiento y luego ajustar su plan de acuerdo con la entrada del cliente. En su ejemplo de carpeta, papelería, identidad, sitio web, etc., puede comenzar con uno de los que se pueden completar en un formato de entrega en un sprint y luego iterar después de recibir comentarios sobre el primero.

¿Quién debe ser el propietario del producto?

Para que tenga sentido que su organización modele el comportamiento de Scrum, querrá a alguien en su equipo que pueda representar las necesidades de los clientes . Esta persona entonces estaría haciendo la gran mayoría de la interacción con el cliente, desde la recopilación de requisitos hasta el intercambio de maquetas y la entrega de productos. ¿Hay actualmente una persona en su organización que hace esto, o todos ustedes comparten esta responsabilidad? Si todos lo comparten o no tiene sentido que una persona sea este punto de contacto, es posible que esta parte de SCRUM no tenga sentido para usted.

¿Quién debería ser el Scrum Master?

Para que esta parte tenga sentido para su organización de diseño, querrá utilizar las habilidades de alguien para organizar, planificar y comunicar . En un proyecto de software, una parte importante del rol del Scrum Master es ser la puerta de entrada al equipo de desarrollo, aumentando su eficiencia al reducir las interrupciones y mantenerlos enfocados. Si eso será beneficioso para su proceso de diseño, entonces debe hacer que uno de los diseñadores lidere la evaluación de las solicitudes entrantes del PO y facilite la ejecución de las tareas.

Me gustaría decir algunas palabras sobre la adopción del trabajo gráfico/creativo y Scrum, porque trabajo en un entorno Scrum como diseñador único de UX.

Para mí no funcionó bien con Scrum. Por varias razones y la principal, supongo, es que, como mencionó Trevor, Scrum es un método de desarrollo de software. No uno para el trabajo creativo . Se trata de tomar una tarea, hacerlo, hecho (que está representado por sus columnas). Así es como codificas.

El diseño se trata principalmente de hacer algo, olvídalo y míralo con nuevos ojos, para obtener un gusto más objetivo. (Por cierto, esa es mi forma de trabajar, otros pueden diferir) Eso no está representado en Scrum. Puede hacer este tipo de iteraciones, pero se supone que debe hacerse el próximo sprint, que es dentro de 2 o 4 semanas. Y no un día o dos.

En realidad, mis tareas de diseño se quedaron en la columna de progreso, porque faltaba un día. Era ridículo y no era un buen estilo Scrum, pero no tengo idea de cómo resolver este problema. Incluso el Lean UX mencionado a menudo no ayuda, ya que se trata de hacer menos papel, pero no de hacer UX en el tablero de Scrum. Tener muchas conversaciones con mi líder de equipo (que es Dev) tampoco pudo ayudar.

De todos modos, encontré un enfoque ágil interesante, que está más cerca del trabajo de diseño y se llama Kanban. Viniendo de fabricación (Toyota), cubre análisis, diseño en bruto y diseño fino también, porque puede agregar tantas columnas como desee;) No pude implementarlo en el trabajo hasta ahora, así que no tengo idea si es tan prometedor como Estoy diciendo.

Consulte algunos de estos hilos y los enlaces internos para obtener más información sobre Kanban: ¿Qué es Kanban? , libros Kanban e hilos Kanban