Agile Website Redesign for Agencies: Is it Possible?

Before we dive into the interview, a little background.

Emily Theis: I’m a producer at Upstatement. On the Harvard Gazette redesign, I helped oversee the process, coordinate communication across teams, and protect the project vision while adhering to our overall timeline. I also maintained team morale by posting frequent pictures of my dog, Noodle.

Mike Petroff: I’m the director of content strategy at Harvard University. For the Gazette redesign, I was the main client contact (henceforth “Product Owner”), which means that I helped develop the project vision and carried the torch for all the different stakeholders at Harvard Public Affairs & Communications—our editorial team, media team, and senior leadership.

Over the course of about four months, Harvard worked with a dedicated Upstatement team: Two engineers, a designer, a creative director, and a producer (Emily!).

The project had two major phases:

• Research & Strategy where we developed a shared vision for the new Gazette through interviews, workshops, technical analysis, analytics research, and more.
• Production Sprints where we designed and built the site in five two-week production sprints. This phase ends with a Transition Sprint where we freeze all features and conduct final QA.

To hear more about the design and engineering effort, check out our Gazette case study. If you’re a process nerd and want to get deep into the mechanics of how we practice Scrum, we wrote a big blog post about it here.

Now, onto the conversation with Mike.

Start with Strategy

Emily: Hey Mike! 👋 Thanks for chatting with me today. Let’s jump right in! I know that you’ve worked with lots of agencies throughout your career. How would you describe the experience of working with Upstatement?

Mike: Upstatement brought not only a strong creative and technical vision for the site, but also shared their deep knowledge of editorial process. I really valued your exploration of not only what we wanted the site to look like, but also how we’d create and manage content moving forward long after the redesign launch. We were building something that was changing both the look and feel of the website, but more importantly, we were changing how we thought about producing content.

Emily: Ah, that’s so great to hear! We definitely don’t want to be drive-by designers and leave our clients with something that is pretty but unmaintainable.

Mike: The project felt like a true team effort.

Transparency as a Tool

Emily: Clients are often nervous that such a high level of transparency will turn into a firehose of information. Can you talk a little about the cadence of communication and the visibility in our project? In fact, let’s Goldilocks this one—was it too much, not enough, or just right?

Mike: For me, it was just right. I knew I had to produce a result that our team was happy with, so I didn’t want anything surfaced as an idea, bug, or issue to go unresolved. The fact that I could see where we were in the process, where resources were dedicated, and could jump in with comments or re-prioritize was incredibly helpful.

I feel that during the project, each team learned more about the other and we were able to adapt, too. There were times where we had to have more visibility on things-in-process, and other times we could wait for prototypes and provide feedback. You were great with finding the right balance with the Upstatement designers and developers to achieve that.

Emily: Thanks! It’s amazing how many variables can be swirling around in a project, and there’s a really careful balance of how much you expose and don’t. We err on the side of keeping the windows wide open, and occasionally pulling the shades for a bit when we have a focused task and just need to crank out some code.

How do you think that windows-open policy, and your close involvement in every detail, affected the end product?

Mike: It allowed me to keep our own teams updated with progress updates. We met weekly internally, outside the Upstatement check-ins, to prioritize work in the Trello board so the team could alert me to any red flags.

Personally, I live and breathe this kind of work. I also have a close relationship with the Gazette editorial team, so I felt like their advocate throughout the process. There were times where priorities shifted internally, or we learned information from Upstatement that changed our thoughts about a site feature, so transparency gave us a chance to adjust mid-sprint.

The Product Owner Role

Upstatement puts a lot of responsibility on the Product Owner role to help determine the success of the project. We ask them to be in daily communication with us, set priorities, and make decisions throughout the project.

Emily: How did you view your role as a Product Owner? What did you expect, and how was the reality of it different?

Mike: As Product Owner, I wanted my team to have a very strong awareness of the large goals of the project. We may have shared different viewpoints about designs, features, or priorities, but my job was to maintain the general direction of the project and evaluate risk vs. reward on a day-to-day level.

Emily: Bingo! ⭐️ Perfect definition.

Mike: The toughest part of being a Product Owner was knowing that some ideas would never [be executed] due to prioritization. I’m a creative at heart, so I love ideation. But, you have to keep in mind the greater goal and not burn hours on low priority items.

Emily: That is really tricky, and you were the master of recognizing that reality while doing your best to keep the dream alive.

Letting Go of the Big Reveal

During a redesign, many clients expect to see a big reveal, like Don Draper delivering the Kodak carousel pitch. But in an agile redesign, there aren’t any velvet curtains or pixel perfect design comps. We establish the overall design direction with mood boards and representative pages, but move quickly to deploy functional, coded prototypes.

Everything starts as simple as possible with an MVP and iterates through every sprint. We ask clients to dive in and start using the site right away so they can give us constructive feedback while actually using the site and entering content in the CMS. But we recognize that it can be tricky to manage client stakeholders who expect to see things the “old way,” the Mad Men way.

Emily: How did seeing and working with the in-progress site affect you, and others on your team?

Mike: Not having pixel-perfect design comps was something we had to adjust to internally. For senior leaders not involved in every sprint meeting, it’s hard to make decisions quickly without a design roadmap. Sometimes seeing an MVP would require lots of context. There were times where I had to prioritize seeing a more developed comp just to get over an internal hurdle. It was a balance, but we learned to adjust and ultimately there were some great ideas that saw the light of day because we didn’t have a rigid path.

Emily: Totally. And we know that no process is perfect. How did you prepare yourself for working in such a different way?

Mike: You suggested (and subsidized) official Scrum training. That was incredibly helpful (and somewhat life-changing) and brought us up to speed.

Emily: What advice would you give to someone else starting the process?

Mike: The five sprints went VERY quickly. If you have to find runway to get up to speed, you’ll lose valuable time. Get up to speed before you kick off the first sprint. Educate your team on what to expect before they experience their first sprint review. 🎓

Agile-ish

There’s agile, Scrum, Waterfall, and Scrummerfall, and everything in between. Our process is based on the Scrum approach (an agile software development methodology) but is adapted based on our circumstances and years of experience. We follow some core principles and go totally off-script elsewhere—we wrote in more detail about that over on Medium. But part of why we love this method is because it bakes in adaptation, and we can learn as we go.

Emily: Did you find it difficult to adapt your “official” Scrum training to the Upstatement way?

Mike: Since we were new to the process, we were still very much in adaptation mode. The one process suggestion our team made was more regular calls between me, the Product Owner, and you, the producer.

We didn’t need the full team to join, but you and I used that time to check in and look a little further down the road. I took that information back to our team so we could plan accordingly.

Emily: Totally. I thought those calls were helpful too, and it’s one thing I love about a flexible process—there’s always room to adapt to a particular project’s needs.

So, what’s the catch?

No process is perfect. It’s easy to get stuck in a sprint mentality and lose the big picture of a project. Sometimes tasks are harder than the team anticipates (although that’s not just an agile problem; it can be even worse with waterfall). You don’t have the security blanket of a detailed requirements spec and a perfect Gantt chart.

We’ve found ways to mitigate these problems. In our Research & Strategy phase, we develop strategic mantras to carry into our sprints and a shared vision for where we’re going. Our producers keep an eye on the high-level progress of the project while the team is focused on the details of the sprint at hand. And we’ve found that adapting our priorities leaves room for cool ideas that would never have appeared in a requirements spec.

Emily: All right, let’s get real. For your team, what was hard about this process?

Mike: At times, we would pull in several cards that ultimately wouldn’t be completed at the end of a Sprint, causing our team to adjust future sprint planning and move those cards into later sprints. If I were to change one thing, I would have loved to see better estimation from the team so that we could complete all items by the end of each sprint, and if time allowed, we’d pull in more from the product backlog.

Emily: I completely get that. We don’t feel great when all the cards don’t get done either, but it’s definitely a gotcha of the process of making things, in any method. Sometimes work balloons and your estimation is just off. We do our best to be honest and expedient when things shift.

Mike: Totally.

Process as a Product

We think the Upstatement process can be as valuable as the product we make. You don’t just get a website, you learn a new way to work. We build a creative project through a collaborative, iterative, and repeatable process.

Emily: You’ve mentioned to me that working with Upstatement changed the way you work together at the Gazette. What specific parts of our process did you end up adopting?

Mike: We continue to use the agile model for collecting user stories and adding enhancements to the site in sprints. We’re using Trello and prioritize with the Gazette editors then build features based on their feedback. Seems to be working!

Emily: Nice! I love that. Well, that’s all I’ve got. Thanks so much for chatting with me, Mike. 🙏 Want to wrap it up with your main takeaways from the project?

Mike: First of all, a special shout-out to our senior stakeholders, project manager, and the editorial and creative teams that helped launch our new Harvard Gazette site.

Finally, I’d just emphasize that Upstatement didn’t start with “Here’s a new look and feel for your brand”—they started with “What do you want to accomplish with your website?” That focus on strategy ultimately gave us not only a beautiful site, but also site features and workflows that all users now use. It wasn’t just about look and feel. It was about goals and strategy.