Graphic with title of The Agile Designer Series — the Stand-up.

The agile designer series — daily stand up

Matthew Cunningham
8 min readOct 21, 2017

When instituting Agile within my Design teams, the first question I got was “where do we start”?

Prologue: The following article is targeted at Product Designers wanting to understand Agile and how to apply Agile methodologies into their work process. Although many of the recommendations can be applied to other design industries and disciplines.

What is Agile?

Agile isn’t a new word nor is it a new concept, especially within the Software industry. In fact, Agile can be found not only in the software industry but also in personal growth and non-technical industries like Healthcare and Sales. But I often find it’s not clear what Agile really means to people. It’s simple really, Agile is like Yoga. Yoga is a philosophy and there are many types of Yoga practices like Hatha, Ashtanga, and Bikram to name a few. When you say “I practice Yoga” people who know say “Oh, what kind?”

Saying you practice “Yoga” only speaks to the philosophy, not the practice. True practitioners understand the difference between philosophy and practice. It’s important to understand Agile has many types of practices and it’s those practices that define Agile. Be sure to understand the difference between philosophy and practice.

Why is Agile important?

This article doesn’t go into why agile is important instead this article focuses on getting started with Agile Scrum. To learn more about why Agile is important and understanding its benefits, read this article.

Implementing Agile for Designers, a.k.a. Agile UX, is really important because it keeps us from going down the rabbit hole too far or spending too much time on designs without knowing if we’re really solving problems or not. Agile UX teaches us how to break problems down, focus our work efforts, and prioritize what needs to get done so we can design better products and services.

Graphic showing traditional ux timelines
Traditional UX model

At first, Agile is hard for most Designer and Design organizations to understand because we tend to work on visionary concepts first or build a Journey Map or lots of upfront user research. In fact, with Agile, Designers have to balance the vision work with the tactical work. Learning how to break concepts, problems, or ideas down into small, medium, and large chunks is one of the hardest skills to learn.

Once you’ve learned how to break things down, the work then becomes more focused and ultimately gives Designers the ability to pivot and change as needed. Agile also allows Designers to “focus” on specific problems and when implemented right (Agile UX), it gives Designers the time needed to fully understand the problems they’re trying to solve.

Graphic showing peaks and valleys representing how to work in short sprint cycels.
Agile UX model

Where do I start?

When instituting Agile within my Design teams, the first question I got was “where do we start”? Starting an Agile practice is akin to starting Yoga. When start a new Yoga practice you won’t be able to do all the poses and that’s fine. Just stat with one. So I start with something simple, the daily stand-up.

Whether you practice Scrum, Kanban, or any other type of Agile methodology, the daily stand-up (oftentimes called Daily Scrum) proves time and time again to be one of the most valued parts of implementing an Agile practice. Stand-ups are quick and easy to set up, they don’t take a lot of effort to do and they’re highly effective. They are a great way to introduce a team to Agile.

Picture of designers standing in front of a monitor during a video call
Typical design standup. Notice the “remote” designer with video feed

The Setup

By focusing on what each person accomplished yesterday and will accomplish today, the team gains an excellent understanding of what work has been done and what work remains. The daily scrum meeting is not a status update meeting in which a boss is collecting information about who is behind schedule. Rather, it is a meeting in which team members make commitments to each other.

To run an effective stand up there are a few key concepts to understand. To start, someone needs to “lead” the meeting to ensure it’s run correctly and efficiently. This person is sometimes known as a “Scrum Master” but try to avoid this type of nomenclature as it leads to single responsibility and detracts from the self-regulated spirit of Agile. Start out by assigning one person per week to lead the meeting. They will be in charge of keeping things moving and ensure any blockers are addressed. Switch out the lead responsibility to each member of the team on a weekly basis. This helps distribute responsibility across the team and helps gain experience running a stand-up.

Next, it’s very important to define an agenda and be clear about its purpose. When sending out the calendar invite be sure to list specifically what the rules and goals are. And finally, make sure it’s at the right time. Having them too early or too late in the day can result in either low attendance or missed opportunities to resolve issues.

When implementing a stand up follow these simple rules:

  • Keep it to 15 minutes or less
  • Be clear about the agenda
  • Don‘t solve problems, just inform
  • Keep it short and simple
  • Designate someone a different person each week to lead the meeting

The Rules

To run an effective stand-up, some rules need to be clearly established early. Start with a daily fifteen-minute meeting first thing in the morning or at a time that best fits your structure. At first, this may seem excessive or even feel like it’s adding more meetings to your daily routine, but done right will be one of the most effective meetings you have all day. When setting up the meeting be sure to clearly set expectations and define the Agenda. During the meeting each person will say the following three things:

  • What I did yesterday
  • What I’m doing today
  • Am I blocked?
  • Fun statement (optional)

It’s that simple. Any discussions outside of the above topics need to be taken “offline”. The point of this meeting is to identify issues or “blockers” before they impede progress. This meeting is not to get into discussions around problems.

The Scrum Master

Every week someone needs to lead the meeting. This person is known as the Scrum Master. Scrum Masters are in charge of running the meeting, ensuring the sprint board is up to date, and follows up on post-meeting actions should there be any. They also ensure everyone shows up on time. The Scrum Master has other duties besides running the stand-up, but for now, just focus on running the stand-up.

And at the end of the week, the acting Scrum Master gets to choose a new Scrum Master to run the meetings.

Tip: Stand-Ups don’t have to be all cut and dry. When beginning these meetings try adding a fun statement at the end of the update. A fun statement is set by that week’s Scrum Master. Adding these in helps keep people engaged with the process and it’s fun!

Some “fun” topics to consider:

  • What was the last thing you listened to?
  • Recommend UX/UI websites
  • Recommend podcasts
  • Worst “Dad” joke

Example emails and calendar invites

Here is an example email introduction introducing the stand up:

Team, As we move towards practicing Agile I’m taking a first step by implementing a daily stand-up. This meeting will ensure everyone is aware of what others are doing and no one is blocked or cannot move forward with their work. Any conversations related to an update can be followed up after the meeting or “offline”.

Here is an example calendar invite for the stand up:

I’d like to meet once a day to discuss progress being made by the team. This meeting will last only 15 minutes and focus only on updates. Please come prepared to discuss the following:

  • What you did yesterday
  • What you did today
  • Are you blocked
  • What’s your best dad joke

The Participants

Who should join your stand-up? This depends on how your design team is set up, but all team members are required to attend the stand-up. Anyone else (for example, a departmental VP, a Salesperson, or a product owner from another project) is allowed but is there only to listen.

If your team is part of an existing multi-discipline team then everyone on that team is required to attend. Most likely your development team is already doing some kind of stand-up. If you aren’t attending them, start! Be sure to communicate your interest in participating before attending. It’s important to understand the structure of the meeting so you can be seen as a value not a hindrance.

If you don’t have access to an existing stand-up (scrum meeting), start having a stand-up within your own team. Practice having the meeting, go overwork, and simply getting used to the process. It’s also a good idea to include your Product owner and development leads (if available) is optional.

Picture people standing together in a semi-circle.
Stand Up should include Design, Development and Product Owners

Things to Consider

As I mentioned earlier, stand-ups are a great way to dip your toe into practicing Agile. The key to any successful agile practice is being open to what works and what doesn’t. I encourage you to experiment and always get feedback.

When dealing with remote teams, I strongly encourage including a video chat as the video tends to help keep remote individuals engaged.

I often get asked if my team physically “stand up”. Yes, we really stand up. I’ve found standing helps to keeps individuals focused. Furthermore, this is a closed laptop meeting. That means no computers are allowed other than the one showing the video feed or showing the product backlog.

If you’re using a process management tool like Trello or Jira be sure to have it up on a screen when individuals are going talking. Walking through your product backlog increases tracking and managing work better. Some teams find it helpful to talk through their product backlog before moving on to the next update.

Tip: During the meeting make sure everyone gets in the habit of writing their update down on paper. This makes people come prepared and helps move the meeting along quickly.

What’s Next?

I’d love to hear from you on any experiences you have with implementing or practicing Agile methodologies within your design team or organization.

Remember to be patient but persistent — being patient is key. Make sure to be patient with your team as they “figure” things out, but also be persistent. Be there to answer questions and to provide support when things go awry!

--

--

Matthew Cunningham

I’m a design-led product owner focusing on creating innovative products and services. Opinions are my own.