How We Do Agile @ Scout
by Julie Tennett (Design Director, Scout)
At Scout, we adapt a modified Agile/Scrum methodology in our approach to client projects. For a lot of students in the organization, Scout is the first time they ever hear about these concepts so we want to shed a little light on our process for anyone curious about how Scout and tons of other studios and agencies design and develop their products!
What isn’t Agile?
I find that it’s helpful for those who aren’t familiar with formal studio processes to start learning Agile by first understanding another popular methodology: waterfall.
Waterfall is a design and development methodology in which all steps of the process happen in distinctly separate phases, often over a period of months. It tends to be a more instinctive and natural process: one team completes all of the design and passes it on to another team that does all of the development; then they pass it on to a team that carries out the user testing and verification. Bugs are fixed and improvements are made based on user feedback. In the end, the complete and final product is handed over for launch!
For some projects and companies, this process works great, which is why it’s super popular! For others, they want a more dynamic and flexible process, and that’s where Agile comes in.
So what is Agile?
Unlike waterfall, where you aim to deliver everything at the end of the project’s timeline, Agile is the incremental design and development of a product in line with an evolving list of prioritized items. Design and development are done in tandem, rather than completing all of the design and then handing it off to developers. Feedback is given each step of the way and user testing is carried out throughout the process, which allows for rapid iteration and improvement, rather than saving all of that for the end of the project and risking having to redo major parts of the work that was already done.
Agile Sprints
A sprint is a period of time during which specific work has to be completed and reviewed. During each sprint, the team works on different parts of the product depending on what has been prioritized with the client. Everything done in agile is constantly being built upon, so each sprint iterates on previous work! For Scout, sprints last one week and end in a face-to-face client meeting where all of the deliverables from that sprint are reviewed, teams get feedback for how to improve on those deliverables, and any questions are addressed.
The image below does a nice job of visualizing these sprints as an iterative cycle! Sprints are what drive agile’s flexibility and constant feedback loop, because you’re designing, building, testing, and getting feedback on everything you create as soon as you create it! In other methods, you may run into instances where you don’t realize something doesn’t work until the very end, setting the project way back! For example, that might happen if your design team spends a ton of time creating some awesome wireframes, and then those wireframes get handed off to development only to realize that those designs can’t be successfully implemented. The design team would then have to spend double the amount of time redoing those wires! Or worse, they end up being developed, it’s put in front of the user for the first time as a final product and it turns out the users have no idea how to navigate it. With agile, you’re checking in on all of these things constantly, so when things go wrong it’s usually not as hard or nearly as time consuming to redo them.
Prioritizing for the MVP
One of the main drivers of the Agile process is working to design and build a minimal viable product, or an MVP. The MVP is the bare minimum that needs to be in place for the product to actually be the product, and this is where prioritization becomes super important!
Let’s look at a theoretical example to wrap everyone’s mind around this concept! If you were building an online database of articles, where would you start? It’s not unusual to be inclined to start with the home page, considering it’s the first page you’d see when you open the site. In an agile process, however, you would want to start with the most important unit of the site that needs to exist for it to be what it is: a database of articles! So what do you start with? The pages those articles live on.
Once you’ve got those nailed down, you would want to think about what the next most important part of the website might be for the user. What else does it absolutely need? Probably a way to see all the articles at once so you know what the database holds. At this point you might want to start designing that home page, and add links to all of those articles!
Once you’ve got those things down, the site is really starting to look like a database, and you’ve achieved an MVP in both steps. You’d continue with this process, prioritizing what the next most important thing to design and build is, maybe focusing on giving the user a way to search for specific articles or topics so they don’t have to scan hundreds of articles at once: a search bar! With this agile mindset, you and your team can stay laser focused on what’s important to the product and to the user, and not lose time getting caught up in features or components that are nice to haves (or worse, flashy features not backed by any user needs!)
In the most ideal agile world, when you’re halfway through the project, you should still have a functional and self-contained product to work with (like a website with links to hundreds of article pages!) even if you haven’t built out all the features that’ll really elevate it to the next level (like search, filters, etc) On the contrary, with waterfall, you might find yourself halfway through your timeline with truly half of a website: a homepage that links to nowhere because you don’t have any article pages yet :(
So how does this work at Scout?
At Scout, we adapt the basics of Agile in a way that works for our designers and developers who are full-time students and part-time Scout-ers. Our sprints are modified to take into account that students can only spend up to 10 hours a week on their client projects, and all projects are set to last the full fourth months of the semester (no shorter, no longer!)
We divide our semester into two phases: research & discovery and design & development, starting with a kickoff client meeting and ending in a handoff meeting.
Research & discovery lasts for the first 2–3 weeks of the semester and starts at the client kickoff meeting. Scout teams spend this phase getting familiar with the client and deliverables they’ll be creating for them, compiling a creative brief detailing the goals of the semester, and putting together a product backlog (a list of all things that might be designed or developed within the scope of the project)
After research & discovery ends, we spend the rest of the semester in the design and development phase, burning through sprints and iterating on our product and process each step of the way! This phase ends during the last week of the semester, where teams hold their official handoff meeting with clients and hand over all design and development.
We start with user stories so we can stay focused on what the user needs.
User stories are framed as “As a (user), I want to ____ so that I can _____.” These help guide the project and its prioritization, and help teams stay in the mindset of the user and not get caught up in adding fancy features that add less value to the user in the end.
An example of how a user story might translate into a feature of the product would be “As a student, I want to see the articles that are relevant to my research so that I can find the information I need quickly.” This user story could translate to implementing a search feature on your database!
We use tools like Trello, Slack, and InVision to keep on top of everything.
Trello is a task management tool that we use to keep track of the product backlog, the sprint backlog, what tasks are in progress, and what tasks have been reviewed and approved!
- Slack is an awesome team messaging platform that makes communication at all times of the day super easy and accessible for everyone on the team! It’s a good way for us to feel almost as connected and communicative as if we were sitting in the same office 9 to 5 every day.
- InVision is awesome for prototyping the products we make for both our team and the client’s benefit, so everyone can gain a better understanding of the user experience and product flow in context! It also has a super helpful commenting feature that makes leaving each other feedback super easy.
Teams have a virtual daily standup, weekly in-person internal meetings, client meetings, and sprint planning meetings, and bi-weekly retrospectives
These recurring check-in points allow our teams to stay on the same page, provide lots of feedback to each other as well as get feedback from the client, and monitor the projects progress easily!
Aaaand that’s a wrap!
So that’s a pretty high-level look at how our studio functions on a day to day basis! I bet you didn’t think something agile would be so complex. And that’s only just skimming the surface; there’s so much depth to the agile methodology there’s a actually a manifesto for it!
As students striving to learn, grow, and improve every day, we thrive under the Agile practice and, by extension, so do our clients! For more details on what was covered in this post, this glossary is a great resource for understanding all the terminology I mentioned and more. And if you ever have questions about our studios process, feel free to drop into Scout’s office and chat! 👋🏻
