When a startup is at the beginning of its journey and has a core team of just a handful of people, it’s easy to simply work on issues as they come up. However, as the company expands, it quickly becomes clear that the same approach will not be viable moving forward.
It’s at this juncture in a startup’s life that you might find yourself asking: How do we create a workflow that will allow our team to work together more efficiently?
Jonathan Caras, a serial entrepreneur who’s managed over a dozen teams, always focuses on creating a workflow that works for everyone: “What kills a good project is often times the system creates so much friction that the employees end up tuning out, and that's where you're guaranteed to take a good product and turn it into a bad product over time.”
It’s important to approach this process with an open mind, even if you have experience managing sprint cycles for other companies. Systems that work for one team don’t necessarily work for another. Many different factors can contribute to determining what makes the most sense for your team. What type of product you’re building, the company departments, and team size can all make or break a system.
However, if you pay close attention to your team and are open to a little trial and error, you can find the workflow that fits just right.
Agile? Scrum? Waterfall?
There are a lot of different methodologies companies use to manage their workflows, and product managers have strong beliefs about which is best. Each methodology focuses on a different aspect of the process. The two most used methodologies are:
Waterfall - An older process that creates a rigid hierarchical structure that’s easy to track and manage. It makes sure that each team has everything it needs in order to hand off to the next team to start their work.
Scrum - A popular implementation of the Agile methodology. Agile is a manifesto that values interactions, collaboration, and flexibility over planning and detailed specifications. Scrum uses feature-based teams rather than traditional departments in order to build faster. Each team is composed of a product manager, Scrum Master, and the other team members it needs for its purposes.
Both of these approaches have their benefits and shortcomings. Waterfall prioritizes structure over teamwork and can make departments feel like black boxes. Scrum can make it hard to have an overview of the product for members in feature teams (especially UX designers). Ultimately, you know your team best, and you should find what works for them.
Few companies adhere to the exact rules of these workflows. Waterfall-based companies sometimes run stand-up meetings, and agile workflows can include more formal design meetings with multiple stakeholders.
Don’t feel pigeonholed by what is essentially a template created by someone who has never met the people you’re working with. Whether you want to strictly adhere to these workflows or not is entirely your choice.
When you identify what your organization’s objectives are, you can work backwards from there in order to figure out sprint features and length.
“Which methodology you have is less important–at least from what I've found– than having a consistent methodology you can funnel creative thought into,” Caras says.
Whatever you’re leaning towards, these components are commonly used and should be considered for your workflow:
Daily stand-ups (or scrums) –– Holding team, or company wide, stand-up meetings allows everyone to be in sync regarding where the company is holding and feel like they are a part of something bigger. This is also a good opportunity to gauge team members’ progress on their tasks and make sure they’re not being blocked by anything. You’d be surprised at how much people won’t tell you if you don’t prompt them. Just make sure this is a judgement-free, calm space. True to its name, it’s a good idea to have everyone stand up while this meeting is happening to ensure that it’s quick. No one wants to stand–or be at this meeting–for longer than 10 to 15 minutes.
Design sprints –– This is a special type of sprint designed by Google that lives outside of the normal sprint cycle. The design sprint is a five-day process that helps solve large, important challenges your company is facing. Using a cross-department team, you identify issues, prototype, and test your designs, which allows you to make sure you’ve come up with the right solution before you make a big change. It’s a very effective method to quickly solve big problems when used right. Just keep in mind that running a design sprint is resource intensive, and it shouldn’t be a go-to for any design challenge.
Sprint naming –– This might seem a little silly, but giving your sprints names instead of numbers makes them feel more exciting. You can decide on a naming convention–for example, celestial objects–and go through the alphabet. It’s a lot easier to look forward to working on Version Pluto than on v2.3.1. You should still append a number to these, just so it’s easier to keep track.
Feedback loops –– After each sprint (or whatever period of time is relevant), show your team the impact their effort has made, using analytics or user testimonials. Feeling that what they’re doing is actually moving the needle on your company’s goals or changing your user’s lives creates a sense of reward, comradery, and a determination to continue moving forward.
Q and A hour –– If you can, having a company-wide Q and A hour at the end of a sprint will allow you to find and fix bugs faster, with the added benefit of giving everyone a quick breather from what they were working on. Having everyone working together on it is both effective and fun as it brings the whole team together, focused on a common goal.
Design review meetings
Holding different review meetings for features helps refine the specifications and align expectations. You may decide you want to forego certain types of meetings or not have any of them. It depends entirely on what works for you.
That being said, these meetings can be very helpful and, if executed correctly, can save on work time later by avoiding back and forths over small details:
Internal product design meeting –– After wireframes (and possibly mockups) have been drawn up, the UX lead presents the feature to the other UX designers. This allows for the other UX designers to help refine the feature and find any gaps in the design. An additional benefit of this meeting is that it keeps all UX designers up to date on all of the features being built.
Product design review meeting –– Once the specifications have been written out, the UX lead presents the feature to developers. The developers advise on the technical feasibility of the feature and outline ways to approach it differently (for example, using a native element or a library that can achieve the same result). Ideally, if the UX lead takes good notes and makes the relevant changes, a second meeting can be avoided by sending the updated spec to the dev lead.
Technical design review meeting –– The developer, QA, (if relevant, server), and UX lead discuss the technical implementation of the feature. A lot of this might go over a UX designer’s head. Product input is needed sporadically, so it’s really up to you (or management) whether the UX lead needs to be present for the entire meeting or just working close by, so they can be called for feedback when needed.
Sprint cycle length
Figuring out how long your sprints need to be is going to be a balancing act between company goals, user expectations, and development ability.
So how does Caras approach designing sprints?
“I start out with identifying what the company's needs are,” he says. “What are the metrics that need to be changed and what period of time do they need to be changed over?”
Your sprints should always be focused on achieving the company’s goals. When you identify what your organization’s objectives are, you can work backwards from there in order to figure out sprint features and length.
It’s more beneficial to the organization and to its members that you’re able to adapt and improve than be headstrong and inflexible.
It also depends on your users. If the users of the product you’re working on have a very low tolerance for bugs–in a bank website, for example–you’ll probably want to have longer sprints to allow for meticulous testing and bug fixes. Products with lower stakes could have shorter sprints and “fail fast,” as the Silicon Valley saying goes. Having short sprint cycles lets you experiment with changes and iterate on them quickly in order to find the best market fit.
User testing is a critical part of any sprint, though it can be hard to prioritize or budget for. The good news is, you can get feedback on your product for free by letting friends and family play with it, or for cheap by paying people to test in person or online. The first time you hand someone your product, you immediately start to see flaws you had never noticed before, whether they be user experience issues or bugs that QA didn’t think to test for.
Being able to see someone clicking or tapping on the screen and voice their frustrations out loud can completely change your relationship to a feature in your product and help fix major usability issues you didn’t know you had. Gathering that qualitative data will help shape your next sprint.
When first implementing a sprint structure in your company, consider carving out time on the last day for a meeting with your team to review how the sprint went. You may have your own opinions, and this is a good time to voice them, but it’s important to get a broader perspective on how the process is working. It’s possible you’ll find that the sprint is too short, or better communication between teams needs to be facilitated.
Feel out your team and what they would be most receptive to. If you find that these meetings go on for too long, you can take questions or comments ahead of time, address them in front of everyone, and take fewer questions in the meeting. If people don’t like speaking up, this can be a period of 15 minutes you set aside for them to drop what they’re working on and fill out a survey. After a while, if the sprints seem to be running smoothly, you can stop holding these meetings.
Opening the floor to feedback allows the team to be heard, which is always appreciated, and creates an implicit buy-in; if team members don’t speak up, they can’t feel bitter about their thoughts not being addressed. If they do, they are taking part in changing the system, which gives them a sense of ownership.
Find your own rhythm
Any managerial position within a company is going to require balancing the needs of different stakeholders. Not all companies are the same, and an individual company will go through a lot of changes during its lifetime. Even if you have a system that’s working, your team could outgrow it. As someone who’s seen a lot of different companies at various stages, Caras knows this very well.
“If the company needs change, that's an opportunity to improve every part of it to better fit the company's needs.”
Companies don’t need managers who will die on a hill over any one idea. It’s more beneficial to the organization and to its members that you’re able to adapt and improve than be headstrong and inflexible. You don’t have to get everything right on the first try. You just have to keep trying.