Agile in Agency

Tips & Tricks on Using Framework Flexibly

One of the best things about being at Genuine is that we work with diverse projects across a multitude of sectors. Oftentimes, though, it can be difficult to reconcile our remote (and sometimes frenetic!) work environment with an existing development framework like Agile that is tailored primarily to product development. This post will share some of the ways that we have bridged the gaps to bend Agile into something that fosters productivity without letting it become a ball and chain.

Skimping on Scrum

When you are devoting all your time to a single project, a daily scrum is the perfect way for a dev team to quickly catch-up and collaborate. However, if you find team members being pulled into two, three, or even four projects that all maintain a daily scrum, you will find your implementors' productivity being sapped by administrative bloat.

Quick Math: if you have two 15-minute scrums a day, then in a typical 40-hour work week over 6% of your time is spent just in scrum.

This issue can be migrated by leveraging those digital communications tools we are all so accustomed to in a post-COVID world. Instead of holding daily calls, try replacing two or three of your meetings with a written update to the team channel. Each person can spend a couple minutes writing their update and the scrum master or project manager can take the time to go through each post and follow-up accordingly. This method cannot and should not replace team meetings completely, but it can help your team break out of the telecom whirlpool and get back to building stuff.

Working Agilely In a Fixed-Scope Environment

Like many agencies, a good deal of our projects are fixed-fee Statements of Work (SOWs). And while set-in-stone budgets and launch-dates can restrict working in an agile manner, it does not mean that there are no opportunities to iterate and improve what we deliver during the project. Here are a couple tips on how to get the most wiggle-room in these seemingly static situations.

• Start with High-Use Functionality – It can be tempting to put the homepage or a flashy feature in your first sprint, but instead choose to begin with the features that will require the most complex authoring or contain the most ambiguity. This allows you to build and adjust over sprints if change is deemed necessary.

• Know your Client – Some client product owners have a high tolerance for “failing” often and are better at getting in the weeds and providing feedback on in-progress features. Others might create unnecessary noise if they are provided a prototype earlier than they are comfortable with. It's important to get to know your client product owners during discovery so you can create ceremony structures amicable to their disposition. If you are working solely as an implementer without a discovery phase, have a frank discussion with your client product owners about what level of comfort they have getting into the weeds with the product you are building. 

• Work against a Backlog, not a “Final” State – This one may seem obvious for anyone familiar with Agile, but oftentimes the most difficult part of a creative project is maintaining the idea that we are incrementally building a product rather than trying to replicate what clients saw in a final sketch. The challenge in doing so is that the first visual tends to stick in your head as the end state, but because business needs and project demands change, the real finish line may look or function differently. In order to help keep the project flexible, get alignment on delivering work and functionality rather than screens and build in time to adjust how things look accordingly if the need arises.

Prioritizing in 2D

When it comes time to plan and groom your sprints, task priority often is solely viewed through the lens of critical path, that is, “when do we need to start activities to make sure they are done by delivery”?  While that definitely is the most important thing to consider, you can incorporate resiliency into your plan by adding another dimension, “what delivers the most value to our client’s customers?” A straight-forward conversation with the client is usually the best way to make those determinations, but sometimes clients don't have all the facts to confidently provide direction. In those cases, it helps to incorporate project members who are most familiar with the client, like a strategist or analyst to help make evaluations from your client’s point of view.

This mindset helps mitigate issues when a project is in the unenviable position of requiring scope to be cut to hit a drop-dead date. By pre-identifying features that they may need to cut later in the project, you can save effort by not working on those stories until you are certain they can be completed. 

Agile is not a “one-size fits all” framework, so these recommendations may not work for every project or team configuration. If you find a process isn’t working, do some research, brainstorm, and try something new. That’s the most important pillar of Agile.

Want to learn more? Give us a call and let’s find out how we can help you start using these tools.