.svg)
.svg)
Have you wondered if Scrum can be used on creative teams made up of illustrators, videographers or motion designers?
Three years ago I had the same question. And I found the answer.
In 2020, as the pandemic was beginning, I was asked to guide the creative department of a global nonprofit through the adoption of Scum across three newly-distributed teams.
The approach I recommend here is born from that experience. If you want to hear the story of that whole journey, signup for when my creative scrum guide launches in 2023.
We took an iterative approach to design a new system because everything was changing so fast in the spring of 2020. Eventually, our implementation of Scrum stabilized as we clarified these four elements.
- Teaming
- Workflow
- Tools
- Stakeholders
Let’s walk through each one.
Teaming.
Ideally, you would have a cross-functional team with all the skills needed for creative production and focused on a singular project. For many organizations, that’s neither the current setup nor an available option.
Finding an organizing criteria.
Because the organization I was working with had a myriad of products they offered, we needed another organizing factor besides the product. Requests were coming in from all across the organization for various assets to be used in various ways.
We considered a couple of organizing factors
- Which departments do the requests come from?
- The nature of the assets and deliverables being created.
- The user story of the audience we were designing for.
We created a quick prototype of each option by drafting who would be on which team and what projects that team would have received in the previous year. This activity allowed leadership to imagine each approach to teaming.
Eventually, we landed on oriented around the common user stories. Which I would recommend for other organizations because it structurally supports a user-centered design.
Defining the roles.
For the most part, we used the traditional Scrum roles of
We made two adjustments, one minor and one a little more significant. The minor change was just to call the development team a creative team. The more material change was to shift the product owner role to what we called a project owner.
Because the organization lacked clearly defined products we could orient around, the project owner took responsibility for specific projects. We aligned the project owner with major departments that were requesting creative work.
You can see from the graphic that the relationships reflect some of the complexity of the organization. But the following teaming dynamics were still maintained:
- Each stakeholder has a specific, consistent project owner to connect with.
- Each project had a clear, empowered project owner.
- Work for a project was done within a single Creative Team.
- Each team has a consistent Scrum Master.
The previous workflow allowed anyone at any level in the organization to submit a request for creative work. Then based on a general understanding of what people were working on, it was assigned to one person to work on until completion or, as often happened, until it stalled. The process didn’t allow much space for prioritization or allocating people's focus over time.
Workflow
When establishing those teams, I made initial adjustments in three areas of our workflow:
- Intake process
- Sorting to backlogs
- Cadence of work
These same areas will be critical as you run Creative Scrum
Intake process
The team was previously receiving a new project request every working day of the year. They would come in with all the details written out by the requesting stakeholder. The pace was unsustainable, and the process created a lot of confusion. It needed to change.
It was clear we would get too much pushback if we shut down the request form completely. So we made two simultaneous moves.
First, the work request form was converted to a conversation request form. In the original request, a stakeholder could check boxes for all the kinds of design work they might want, such as video, print, web, branding, etc. People would often request things they didn’t need, not provide the necessary information, and have unrealistic expectations about how long it would take.
Now they enter their contact info, the problem they are trying to address and what they would like to discuss in our conversation.
This change was driven by the agile value of individuals and interactions over processes and tools and customer collaboration over contract negotiation.
The original form burdened identifying a design solution on the person making the request. With the new form, we could enter the process with a different posture of trying to help create a solution rather than crank out some deliverables that may not actually solve the problem.
Second, we identified the critical stakeholders for different areas of the organization and began initiating with them. As the pandemic raged on, we wanted them to understand how we were changing and how we could better serve them.
We asked about their priorities and reviewed work requests from the previous year to forecast their needs for this year. We could identify what content or decisions we need from them for that work and schedule it ahead of time.
Suddenly we could see not only what the department was currently focused on but what was coming in the future. I compared it to the role of an air traffic controller in the tower, knowing that planes had left Tokyo, New York and Chicago all headed this way. Before, we were like someone standing on the runway with batons trying to direct the planes, only knowing what was visible in the sky above.
Sorting to backlogs.
As we identified projects through conversation requests or stakeholder meetings, we defined them with user stories. These user stories allowed us to sort them into the backlogs of our newly formed creative teams.
Now each team has visibility of both current and future work.
Initiating a cadence of work.
Implementing Scrum itself significantly impacted the rhythm of how we assigned work by organizing everything into three-week sprints.
We also implemented a four-month cadence with our stakeholders to identify priorities and projects. We called these trimesters because they divided the year into three parts. This rhythm aligned with the cadence of spring, summer, and fall, that’s normal in an education-related non-profit.
We would meet with the stakeholder at the beginning of the trimester and work on forecasting and defining the next two trimesters. So our horizon was always about eight months into the future.
Stakeholders could still reach out to us as needed, and we still received some conversation requests, but the bulk of our work came through these meetings. Working proactively allowed our team to roadmap the projects and identify and resolve dependencies, bottlenecks and other issues before they were a crisis.
Related Guides
.webp)
Tools
The team used an array of tools to accomplish the following tasks.
1. Task tracking
2. Timesheets tracking
3. Workload balancing
We hoped to find a solution that better met our new needs and reduced the number of tools creatives needed to engage with regularly.
The teams had been using Trello to keep track of who projects were assigned to. As we began outlining our workflow, repeatedly the question came up, “can you do that in Trello?” Trello is a great simple tool in its free version. There are a ton of power-ups you can use to add more specialized features, but you’re only limited to one in the free version.
We realized this would not cut it for running scrum across multiple teams. So now we had more questions to answer, “What will be our criteria for selecting a tool to manage the Scrum process?” and “How will we pay for it?
Criteria
To identify the needs for a system that wasn’t up and running yet, we had to envision our workflow fully implemented. Thankfully, many tools have free trials, so we did a proof of concept in multiple tools to evaluate the tools and identify the needs for implementing Scrum within the constraints of our context.
Here are the criteria we used to evaluate tools.
- Visually appealing.
- Allows for collaboration with other teams in the organization.
- A clear view of what a given Scrum team is working on.
- A clear view of what individuals are working on.
- A Clear view of what all the teams are working on.
- Ability to maintain a hierarchy from project to Epic to user story to task.
- Ability to forecast capacity and schedule work in the future.
- Ability to distribute some projects across teams and easily integrate their work into final deliverables.
“Visually appealing” may seem out of place at the top of the list, but I quickly discovered how important it is when I gave a demo of Jira to the team. “It looks like it was made by programmers for programmers!” 😂😂😂 It was a fair critique.
For the creative department, the reality was if they didn’t enjoy looking at it, they would disengage before experiencing the benefits. We found Asana met our criteria for both visuals and needed features.
Did you know Scrum applies to more than just developing code?
When you understand the essentials of Scrum and the nuance of how to apply it, you can use it to level up aspects of everyday life.
Stakeholders
A major adjustment we needed to make to the traditional Scrum framework related to the role of product owners. This was because our organization doesn’t have product owners. In fact, the term and even concept of products can feel weird sometimes to those inside a non-profit.
This created issues, even without implementing Scrum, because there were literally hundreds of products spread throughout the organization, without priority or architecture to make sense of them, nor an owner or roadmap to guide them. It was quite a challenge and provided our team an opportunity to lead up in the organization.
What’s a stakeholder?
This term was already familiar, and we had built decent clarity around it through other projects in the past few years. We further clarified the definition to mean someone with decision-making authority to commission a project. We also identified collaborators, who would contribute to the project, and consultants, who could give directional help.
Related Guides
Running Creative Scrum
There’s a lot more backstory and context to my creative Scrum journey and it was a joy to see Scrum help these teams to thrive and deliver quality work at a high volume.
Action Plan
If you want more of the stories and the details of how to run Creative Scrum, you can find them in my upcoming Creative Scrum Guide.
- Backstory context
- Doing research
- Defining the outcomes
- Selling the idea
- Tunnel of chaos
- Building the system: people + workflow
- Building the system: tools
- Relating to stakeholders
- Syncing with the organization
- Backing off the ideal
- Making the jump
- Getting out of the way
Frequently Asked Questions
What is Scrum?
What is the definition of scrum?
Scrum is founded on three essential pillars leading teams to ask the following questions:
- How does this make things more visible? (Transparency)
- Where does this create space to evaluate? (Inspection)
- When does this encourage growth? (Adaptation)
Further explore the definition of scrum. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
Is Scrum hard to learn?
This is because Scrum’s simplicity makes learning easy, but Scrum truly changes how you work, and that adjustment can be difficult. It changes power dynamics and expectations within the team and between the team and the rest of the organization.
You can explore further is Scrum hard to learn, along with the pros and cons of Scrum. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
When did Scrum start?
Scrum was initially used as a term related to project management in 1986 by Hirotaka Takeuchi and Ikujiro Nonaka in their paper “New New Product Development Game” In the Harvard Business Review. The first recorded Scrum project came a little later in 1993 from Jeff Sutherland.
You can learn more about Scrum’s backstory. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
What do all the scrum words mean?
Learning Scrum for the first time can be overwhelming. There are a lot of new terms and concepts in Scrum. I’ve listed the most common terms in a Scrum glossary.
Learning to apply Scrum
How to choose between Scrum and Kanban?
Important factors include your team size and the type of work you do. Kanban is very process-oriented, so you should consider how defined, static, or long your process is?
You can explore Scrum and other agile approaches. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
How does scrum help an organization?
Scrum forces clarity and prioritization, which are critical to organizational effectiveness. It provides a competitive edge by allowing teams to adapt as the market or priorities change. Teams operate more effectively because Scrum combines empowerment of the team members with alignment to top priorities.
Learn more about scrum’s impact on organizational culture. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
Is scrum a methodology or a framework?
Scrum is more of a framework than a methodology, and it helps teams adhere to Agile principles and get stuff done. Scrum provides basic rules but doesn’t prescribe how to do the work. It provides principles, values, rules, and some core structure but still leaves a lot undefined.
Learn more about scrum as a framework. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
What’s the difference between scrum and agile?
When people say “agile,” they usually refer to it as a mindset. Scrum is a framework for how to organize people and work in an agile way. If you’re practicing Scrum, you’re working in an Agile way.
Learn more about the relationship between scrum and agile. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
How to use Scrum
Why use Scrum?
It forces clarity and prioritization, which provides the focus necessary for teams to be effective. Scrum embraces complexity and change by keeping many things simple and iteratively evaluating and adapting.
You can learn more about why to use Scrum and three challenges Scrum solves. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
When does Scrum not work well?
Scrum isn’t always the best option for teams. Scrum can fail when there is a substantial mismatch between organizational culture and the Scrum values. It also depends on the nature of the work you do. If you work if very linear, predictable and tightly defined, you may not experience many benefits Scrum provides.
Find out more about aligning your organizational values with Scrum or how Scrum might fit in your context. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
How do I know when to use Scrum?
Scrum functions at its best when you have a dedicated team focused on developing a singular product. Its agility shines when there are time constraints combined with uncertainty.
Explore the pros and cons of Scrum along with expectations vs. realities with Scrum. Then browse the most common terms in a Scrum glossary and learn what is Scrum.
