Are you really ready to work agile with a digital agency?

By now, everyone has heard of the benefits of working agile, primarily delivering value faster. You may have already started using agile or a variation of it. Whether you have or haven’t, this article will help you learn what to expect when working agile with a digital agency and ultimately help you decide if working agile with an agency is the right choice for you.

Agency Agile

As introduced in 2001’s Agile Manifesto, agile is a process of short iterative cycles of product development by a dedicated in-house team. While you may consider a digital agency to be an extension of your company, you’re engaging one specifically for the expertise, perspective, and scalability you don’t have in-house. Although not in-house, digital agencies can still provide many of the benefits of agile. While each agency endeavors to differentiate themselves with their unique approach most follow a process of iterative design and development cycles (a.k.a., sprints) from strategy to deployment, closely collaborating with you throughout.

Collaborating

The key to working agile with an agency is team collaboration. The agile team involves you, the agency, and possibly your in-house team or other vendors with which you work. You and the agency should clearly identify the collaboration model for everyone involved, cross-functional integration responsibilities, and how both will be managed. To succeed, everyone must agree on the model.

The agency will assign a dedicated team (called the scrum team) consisting of strategists, analysts, creatives, developers, testers, or other pertinent roles. Agile works best when a team knows how to work harmoniously and communicate seamlessly, so look for an agency scrum team that has previously worked together. This is also a reason to maintain ongoing engagements with the same team over multiple projects.

Instead of a producer a scrum master will be part of the team. Their chief roles are to remove impediments that arise and to facilitate meetings and communications with you.

From your company, you’ll need to assign a product owner who has decision-making authority and the support and trust of other project stakeholders. The product owner will be part of, not outside, the scrum team. They will make requirement changes, prioritize requirements, provide feedback, answer questions timely, and participate in sprint meetings. If the product owner hasn’t had a chance to work on an agile project before, expect the scrum master to ease them into the role.

Since close daily collaboration is key to agile, when you work agile you’re really asking to work closely with your agency, particularly if you plan to provide content or have your inhouse team perform back-end integration. In agile, the scrum team is usually co-located in the same location. Often this isn’t possible for agency agile. In addition to the product owner and the agency residing in different companies, team members often reside in different locations and time zones. Agency agile can still be successful if as much of the team as possible can be located together (e.g., your back-end developer onsite at the agency or vice versa) and by using video conferencing with screen sharing and online agile products to stimulate and support close collaboration between remote teams.

Planning

Although a plan that sets a scope, timeline, and cost is needed between you and the agency before the project begins, this is exactly when everyone knows the least about the project. The truth about carefully formulated, highly detailed plans is that they are never followed. Detailed requirements never cover everything unless they’ve been drawn up in time-consuming exhaustive specifications. Since your customers’ needs aren’t static and can change quickly, these specifications are usually outdated by the time they are done. Furthermore, once a project starts priorities shift, directions change, functionality scope creeps, and tools’ subscriptions change unexpectedly.

Agile is designed to account for change. The plan should specify high-level requirements by general level of effort (e.g., small, medium, high) and fix a dedicated scrum team’s allocation (e.g., full-time, half-time) with the number of sprints expected to meet the effort and each sprint’s duration (e.g., two weeks).

With the scrum team, high-level requirements, and sprints defined, determining the project cost remains. Agency agile typically uses a blended rate rather than experience-based rates. While you may worry a blended rate will result in the agency delegating work to less experienced staff, agile’s collaborative continuous improvement nature ensures staff with the right experience completes work. A blended rate with a set number of sprints results in a fixed project fee. You’ll know your budget without worrying about change orders, and the agency can plan staffing accordingly; a win-win for everyone involved.

Starting

Finally, it’s time to start the project. It’s often called Sprint 0. The team focuses on acclimation and, working together, identifying and targeting audience(s) against the high-level requirements to populate and prioritize the “backlog”. The backlog is part of an online tracking tool that is the single place where everyone, at any time, can view requirement details, priorities, status, and changes. When prioritizing, focus on delivering value to your customers in the near term and be certain to consider the effort needed to support the completed requirement. For example, don’t prioritize including video transcripts if staff aren’t available to provide transcripts on an ongoing basis.

Sprinting

Once the backlog is populated the team holds the initial sprint planning meeting. A sprint goal is set and requirements meeting the goal are broken into steps with expected effort and any risks. Cross-discipline discussion ensures everyone has the same clear understanding of each requirement and the effort involved; including non-typical situations. The backlog is expected to be dynamic and evolve over sprints. Since agency agile projects plan for a set number of sprints, each planning meeting should take into account the number of outstanding sprints and plan realistically for completing the project within them.

Getting realistic consensus on the effort needed to complete requirements is essential to sprint planning. Anonymously, team members “vote” by estimating each requirement relative to other requirements, using a numbered list. The larger the number, the more effort involved. Once everyone has voted, estimates are revealed and discussed to ensure agreement on the final estimate. This voting consensus is called “agile poker”.

Using priorities with final estimates the team selects the work that can be completed in the sprint. The selected work is moved from the backlog to the active sprint board and the sprint begins. Once started, requirements are fixed for the sprint’s duration. This ensures productivity isn’t derailed since the team would need to break from the active sprint work to return to the planning process to address requirement changes mid-sprint. If a new or changed requirement must be immediately addressed, the sprint is closed. The active sprint’s work is returned to the backlog since it is considered to be partially completed until reviewed and accepted by the product owner. A new sprint will start with a planning meeting that includes the new/changed requirement(s).

As the scrum team completes the sprint’s work the active sprint board is continuously updated so everyone knows the work’s status. Each sprint workday the team holds a scrum meeting to set the context for the coming day’s work. The meeting is limited to 15 minutes to keep the discussion brisk but relevant. Everyone states what they did yesterday, what they will do today, and any impediments. The focus is on commitments and resolving productivity blocks. The product owner isn’t required to attend scrum meetings; however, they’ll be informally involved by reviewing work in progress throughout the sprint. These informal reviews boost quality and the team’s engagement.

Reviewing

Each sprint ends with a review meeting in which the scrum team presents the sprint’s accomplishments to the product owner, and often times, project stakeholders. Typically the scrum team will demonstrate a working version of the features completed during the sprint. Key decisions made during the sprint are discussed. Accomplishments are assessed against the sprint’s goal and consensus reached on whether each requirement is done. While consensus feedback during the review is optimal, it can also come later. Work not done or pending feedback is returned to the backlog and reconsidered in future sprint planning meetings.

Depending on the engagement, completed work is provided for formal acceptance testing and once approved, launched live upon the agreed schedule. Sprints continue until high value requirements are done and live. As requirements change the number of sprints needed to complete the project are continuously reviewed. As necessary, the agency will work with you to adjust the number of sprints to complete the prioritized requirements.

Summary

Agency agile’s iterative planning and feedback in design and development sprints will focus you on quickly delivering the highest value features to your customers first, but before committing be certain you understand the agency’s version of agile, that it meets your expectations, and you’re ready for collaborative commitment.