Introducing Agile to our growth marketing team was a revelation of productivity and process. I found it well-suited to managing the tight turnarounds of marketing campaigns and setting and reflecting on performance goals.
But the biggest challenge of working with creative colleagues in a scrum environment was how to allow them the space to be, well, creative. Maybe this is a dilemma as old as time, where account managers need assets yesterday, and production can only be rushed so much — however, we quickly found there was much our team could learn about structuring creative work in an Agile setting.
At an AIGA Austin roundtable event in March 2021, Jon Racinskas, Sangfroid!’s creative director, and I spoke with design professionals around Austin to try to answer the question, “What is the ideal pace and structure of creative work?” And furthermore, when can Agile be a tool versus a burden, especially for creative work?
The value of answering these questions is to better organize work for the given project, for the given team, allowing your creatives to produce high quality stuff, but on a frequency that is meaningful in a business context.
If you missed our panel conversation with AIGA, don’t fret! Here are my key takeaways from our session with designers from Google, IBM, and Capital Metro.
Beyond the buzzword: What is Agile anyway?
If you’re not familiar with Agile, allow me to demystify some of the lingo, starting with capital-A-Agile.
Agile is a form of project management that first started in software development. The basic idea of Agile is to have a focused team led by a primary owner that ships little bits of software frequently. So instead of working on a giant release project, the team breaks up the backlog of features to add to the product into little short intervals. This is generally considered superior because it lets you work iteratively to meet the needs of your customers.
Consider for example Microsoft Windows transitioning from coming in very large releases like XP and Vista to the idea of Windows 10 as a service, wherein updates come over the web very frequently.
Another term you might hear is Scrum, which is just a specific flavor of Agile with rules and roles set out. It comes from the tight Rugby formation, and has a fixed interval for delivering software.
A Sprint is what we call that interval, often of 2–3 weeks. It’s just a unit of measurement for organizing work in scrum.
Even if you don’t use these terms, it doesn’t mean you aren’t already using these principles. Lots of tools are built on these ideas, so if you are setting clear owners and deadlines for your projects, having a daily standup, and reflecting on your progress at the end of a project, that’s Agile.
Over the years these principles have been adopted by many teams outside of software development, including marketing, design, consulting and more.
Scrum is right for some teams
In our conversations with fellow creatives working in a mix of project management styles, from Scrum to traditional Gantt project management, a theme emerged — Scrum is right for some teams, and not at all for others. But for most organizations, the best approach is to think about all of these strategies as different tools in your toolkit, to deploy when the project or team calls for it.
Instead of living or dying by 2- or 3-week sprints and trying to establish the holy grail of Agile, managers should evaluate the needs of the project and the strengths of your team, and adjust timelines accordingly. Like Joe DiGioia, a panelist we spoke to from IBM, said, “Design got done before Agile.”
In the same vein, Paula Le, a UX designer, described how her team at Google uses “Soft Agile.” They rely on a sprint structure when executing a plan, but for research or ideation use a much more open structure.
Like Paula’s team, some projects will run well on a Scrum style of back-to-back 2-week sprints, but if that is restrictive for your work, consider a mix of a long, open period for exploration, and then running the play in tight sprints.
Perhaps your organization runs very large projects on very large time scales, but could benefit from occasionally injecting a focused 1-week Design Sprint to solve a vexing problem. Bring all the stakeholders together for just one week to rapidly design new solutions. Or perhaps, just borrow small Agile concepts, like the Retrospective, to reflect with your colleagues on how you might be able to grow as a team.
Or maybe you’ll find, as we did at our agency, that a scrum team can coexist peacefully with a more open and flexible format for other roles, both working on the same team.
It’s actually a marathon
Many of our conversations emphasized that just as empathy is important in design thinking, it’s important in the workplace. Paul Del Bosque of Cap Metro told the panel that the secret to iterating his design projects wasn’t Agile, or even the Monday.com project tool he uses to manage them. It all goes back to relationships with your team, stakeholders and users, and understanding their needs and work deeply.
I think the idea that no amount of Scrum mastery can replace relationships with your teammates is as good as any code to live by.
