Most design teams function within a project management structure. Someone is there to keep track of the deadlines, the deliverables needed, the people needed to do the work. There are many positives to this approach, although I feel bad about this job function, it’s thankless. It’s an unfortunate combination of all the responsibility and little authority. At best, there’s cooperation between the goals of the creative work (innovation) and the realities of business (reliability). I have been working for many years and have been in a self-managing team using Scrum. This approach is not unique to me, but it is untraditional and puts the job of managing expectations on the people that control those expectations. This is also called scope, and in many creative projects grows out of sync and causes ruined timelines, relationships, and of course sub-par design experiences. I have a few observations and am grateful to have learned from people that have done it right and have made some small successes and many errors that have also helped me sort out how you create a process where design and development can create outstanding work.
Scrum for UX
The agile framework is being adopted by many digital design and development companies. Agile embraces a more iterative process, it fits well with design thinking and incorporating user feedback. Scrum is a subset of Agile. It is the method to manage the work and manage expectations. I was involved in a complete switch from the waterfall process to Agile/Scrum and learned that many companies pick and choose the parts of Agile/scrum they prefer, and leave other processes in place. In my experience, you have to really embrace the entire process for it to deliver the benefits. Unfortunately, it conflicts with most of the top-down management driven structures that many businesses favor. That being said, UX and design tend to be culturally a bit farther apart from these structures, so it’s not a stretch to adopt a team dynamic in design that fits well with the Scrum process. If you incorporate development it works even better, since this process was invented to reduce documentation and deliver quick results to user and stakeholder feedback, all crucial to user-centered design.
Scrum starts with a cross-functional team and really tries to have little or no need for outside management. Lack of project management may initially seem counterintuitive, but with these ceremonies, the team should be able to set their own goals and manage their own work. This is meant to help bond the team around the problems being solved, and share the success or failure.
To actually use scrum, you really need a coach, known as a scrum master, who helps the business and the teams cope with their new responsibilities. My teacher was Craig Larman but there are many other people that can help you learn scrum like Tony at VitalityChicago. This article is to see if you’re interested in changing your process and to talk about the ceremonies. The one thing that helps a team work together is a shared, regular set of events. Opportunities to put the work down and focus together on different challenges of being a team. So often in design people work alone and only connect in brainstorming, critiques or pitch meetings. These rituals help the team learn how to run a design business, stay focused, and course correct. Here are my notes for how these scrum rituals work for designers.
The 6 and a half ceremonies of a scrum/agile team
The Backlog grooming process ideally takes place constantly as new ideas and suggestions arise. The problem a backlog solves is that focus could change daily, the backlog is a way to store good ideas, but not to the detriment of getting the current priorities done. Don’t spend a lot of time wordsmithing or analyzing backlog items, They should be ideally written on a post-it note. 
They should be in the form of a user story if only to help the product owner, or business owner to group and prioritize them. The team has a short weekly meeting to get items into the backlog for the first MVP (minimal viable product), but in production products, it can easily be automated by using software to gather and vote on user choices.
Now that you have things to do, the next step is getting them ready to sprint. This is held in a meeting once per sprint called product backlog refinement or PBR. This meeting takes a fair amount of time, I usually do 3 hours. The goal is to take the backlog items and have the whole team analyze and dissect how to get them done. The item should be estimated and analyzed by the whole team, we use a rating of difficulty from 1-13. If the item is too complex (rated 13), break it into 2 items and see if you can make it simpler. Try to analyze a bit more total points than you need to fill a sprint, but not too much. This is time-boxed to keep it from getting into one on one discussions it is a way to get everyone on the team familiar with the upcoming ideas, to help ease directly from current work into the future.
Sprint planning is really just taking things from one pile – ready to sprint into a doing it pile.
However, we like to tally the points and difficulty, and also parse out who is working on what. We also like to figure out what kind of velocity the team is achieving. Much like any scorecard, this measurement is only as accurate as how good the team is at estimation (normally not that good). The team gets better, and soon you can show progress, the ability to take on more complex work. The ability to do complex work quicker is one motivation, the other is to find that through the process, the hard work gets easier.
Showcase – at the end of the sprint the team shows off their work. Stakeholders and product owners touch it, comment and approve (or reject) the designs and prototypes. Outside of one-on-one meetings with SME’s or user feedback sessions, the team is isolated from day-to-day business meetings. The backlog review and showcase are really the chance to come out from the team dynamic into the real world of the business, and that isolation is essential to the team bonding and owning the outcome of their efforts.
Daily Stand-up and Retrospective fill out team bonding exercises. While we don’t all work together on the same thing, we do co-own solutions and the stand up is the time to ask for help or advice. Retrospective is what went right- wrong and how to fix it. In the meeting we can also invite the business to express their perspective. We also review previous actions to make sure we are progressing.
Team activity should happen once a month, and often is has lots of options. A lunch and learn is good if one team member presents a topic that interests them. I wish I did that… is a group activity I used at an agency where everyone brought in some kind of work that inspired them and shared why – movie, website, app, article. Breakfast / Drinks are more casual ways to bond with the team, but they are often hit and miss since people can stay in their cliques and comfort zones.
What you get for all the effort
When done well, the team is productive, the work stays consistent, there’s time to make sure the polish and fit-and-finish are high. The feedback helps the team grow and sooner or later you have the A-team. Still, there are pitfalls – cliques can form, productivity can be uneven, there are people that are good at sharing their thoughts and goals, and some are more introspective. This method can suffer if the team is put together by management. It works properly when people can choose their own teammates. This ensures that there are mutual understanding and admiration of what each member brings to the team.
Perhaps the biggest practical matter is how people with different perspective and skills are able to collaborate. For example, the experience designer may develop a storyboard of low-fidelity items to get feedback from users. If a developer is on the team, how do they contribute? Since I like to go quickly from low to high fidelity prototypes, I have them build out the major structures we are presenting, such as navigation, sorting/filtering, and other mechanisms. In this manner, we solidify some of the primitives while we sort out the user journey. Also, it’s just good for people to wear several hats, so chipping into other work and learning new skills is an essential prerequisite for making this technique successful.
The other great challenge, working with a remote team. What happens if the team is in different places? What happens if they are in different time zones? This throws a wrench in many of the carefully laid plans, and honestly, working in the same room with people has a distinct advantage to quick communication and collaboration. I can say with confidence that it is possible to work remotely with similar results as an in-person team. It does take tools, and these tools are the subject of the next post. Stay tuned.