On a recent evening in Arlington, Va., around forty designers, project managers and consultants chatted over tacos, wondering when they might crack open the big yellow bins of Legos™ on nearby tables. They had gathered for a hands-on workshop to learn the foundations of scrum, a particular flavor of agile development.

“I’m curious about scrum,” said Lilia LaGesse, director of print and digital publications at the Council of Independent Colleges. “As I talk with designers within the design community, more and more of their teams are adopting it — whether agencies or in-house design teams. I’m hoping to get some ideas as to how we can be more collaborative as a team.”

Justin Franks and Lindsey George from Deloitte Digital lead workshops that use Legos™ to familiarize outside clients with agile and scrum methods.

LaGesse wasn’t alone. Workshop participants admitted to having heard of agile without really knowing what it was. Luckily, Justin Franks and Lindsey George of Deloitte Digital were there to guide the participants through their Lego™ City Agile Workshop.

While Deloitte Digital’s external clients manage teams who follow traditional waterfall methods, Franks and George use a playful way to introduce agile methods: Legos™. Learning a new process can be daunting, but it’s hard to feel intimidated when the table is scattered with colorful bricks. But even a hands-on workshop was sure to cover the basics first. Let’s take a quick look at the foundations of agile.

What’s agile, in a nutshell?

Agile methods are based on the idea that teams are self-organizing and collaborative. Teams work with the information available and adapt to new information — such as results from user-testing — over the course of the project. Teams work quickly to develop the product, then continue to make improvements.

The agile manifesto outlines four tenets:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

“Agile is better than waterfall when there’s a high degree of ambiguity,” Franks replied, when a workshop participant asked how to determine which process is more efficient. In other words, when it’s not possible to gather all the requirements at the beginning of a project, or when trying to solve a problem without precedent, agile processes are more flexible and adaptive.

A number of practices comprise agile methods, such as writing user stories, time-boxing tasks, conducting daily standups and holding retrospectives. More on those in a bit.

Is scrum the same as agile?

Sort of. Scrum is a flavor of agile that further defines the scrum team into roles: the product owner, the development team and the scrum master. Briefly summarizing the roles:

Product owner: Similar to a project manager, the product owner sets the project priorities, communicates with stakeholders, and knows everything there is to know about the product’s goals and business objectives.

Development team: This team includes front-end and back-end developers, systems experts, visual and user experience designers.

Scrum master: The scrum master helps the team adhere to agile practices, facilitates collaboration across the team and is an all-around obstacle-clearer.

A scrum team also decides together which tasks they can accomplish in a given period of time, and teams are introspective — they identify how well (or badly) their processes work for them. For these reasons, teams should not be very big; ideally 5 to 11 members. Teams larger than this could find scrum practices unwieldy.

How can my team incorporate elements of agile and scrum?

Workshop participants built structures according to the user story tasks they prioritized in their sprint backlog.

Agile and scrum are certainly a commitment to a new way of working, and it’s hard for a particular project manager or designer to know if it’s appropriate for their team to make the switch.

“I think being able to do baby steps and introduce small things, even to existing clients, has made a huge change to us,” George remarked, when a workshop participant asked about their biggest challenge when encouraging a client to try agile. “I think when we went to clients — guns blazing, that we’re only going to do agile — we met a lot more resistance than we would have if we went in with a slow pace,” she said.

There are some agile and scrum practices that teams can try without going all-in. These may be enough to improve collaboration, or they can be a jumping-off point to a larger organizational change.

1. Write user stories
Goals and features are typically written from the stakeholder’s perspective. This often leads to prescriptive solutions that serve the company better than it serves the audience or user. Try framing features from the user’s perspective, and your team can decide for itself the best solution for that feature.

Try this: A stakeholder may write a feature like so: “Send a push notification to mobile app users when a news story is published.” The stakeholder already declared a solution — a push notification — without input from the team. But does the user really want a push notification every time a news story is published? Probably not. Instead, try writing a user story by framing this feature from the user’s perspective: “As a user, I want to stay up-to-date on the news.” The team can brainstorm a number of solutions that push beyond the alert.

The benefit: With this open-ended framing, teams can move away from prescriptive solutions that may focus too much on business objectives, toward a user-centered solution that’s a better fit for everyone.

2. Time-box tasks
Designers are in a tricky business in that much of design is subjective. I have yet to meet a designer who feels a project is “finished.” Designers (and stakeholders) can always find tweaks and improvements to make, given time. Agile and scrum encourage time-boxing tasks, that is, to adhere to a set amount of time (a sprint) to accomplish tasks, and then move on. Iterations on the design become new tasks in future sprints.

Try this: Let’s say you work in-house and scope creep is a common problem. Collaborate with your stakeholders to set a sprint duration, such as two weeks. Work together to determine the tasks that can be accomplished during that time. Once the sprint is over and the work has been reviewed, stakeholders can request changes or variations, but should understand that changes will be tasked separately for the coming sprint.

The benefit: This will help the team and stakeholders focus on meaningful changes in the shortest amount of time, rather than endless noodling.

3. Conduct daily standups
Standups earned their name from their brevity and efficiency (standing meetings = short meetings). Consider a team gathering in an informal space each morning that lasts no longer than 15 minutes. Each team member reports their progress and anything that might stand in their way.

Try this: Format each progress report as, “Here’s what I did yesterday; Here’s what I’ll do today; Here are my blockers.” Anything that needs more attention can be saved for the “parking lot,” a few minutes at the end of the meeting open for further discussion.

The benefit: This helps team members plan what they’re doing for the day, and exposes problems that stall work. One team member may be working on a task that another member has experience with. Perhaps most importantly, regular communication and transparency build trust among the team.

4. Hold retrospectives
One of the best ways to learn how a team works together is to reflect together. How is the collaboration going? Are there things the team would change? Were there things that went exceptionally well, or went down in flames? The “retro” does not evaluate the work, rather, it evaluates the process.

Try this: Call a team meeting at the end of each sprint to discuss, “What went well? What didn’t go well? What should we do next time?” Document these answers, and change some processes for the coming sprint. For the things that went well? Keep doing them — and more of them. And don’t skimp on praise. Thank team members for little victories. During the next sprint, be sure to refer back to the retro notes to keep those action items in action.

The benefit: While it may sound like teams are meeting to criticize one another, retros are more likely to reveal hiccups in process, not people. Identifying these hiccups and changing how they’re handled makes the next sprint easier. It’s even better to identify what was successful, and to recognize which processes to keep.

Can such a formalized process be creative?

Agile and scrum offer more flexibility than it may seem. Teams can decide to tweak practices here and there to better fit how they collaborate, particularly as scrum facilitates cooperation between experts in design, user experience, development and business.

“It’s really important for me to get immersed in the artistic side of the business, and keep that in the back of my mind as I think about strategy,” explained workshop participant Arsalan Jafree, a senior consultant at Deloitte, and a student whose graduate program incorporates design thinking. Jafree added, “More federal agencies are incorporating design and design techniques into their line of work. I want to be at the intersection of business and design.”

That intersection is a natural place for creatives to experiment with process. Some agile purists believe that teams can’t just adopt the parts of agile they like, and leave the rest by the wayside. However, a full commitment to agile and scrum is a major change for any team. A team who adopts a few scrum practices now can grow enthusiasm and buy-in for a major change down the road. And that change just may allow for the most collaborative freedom.

• • •

Like what you read? Check out more events and blog posts from AIGA DC. Find us on Twitter, Instagram and Facebook.