How We've Adopted Agile in our Web Development Process

In early 2015, we began evaluating and testing best practices from the Agile method.

Build Versions, Sprints, and Demos

When we came to Agile, we were already organizing our development into build versions. First, we'd build an Alpha Site, then a Beta Site, then a Final site... then we would launch.

Agile provided tools for refining this process. Agile limits the amount of work that can be done between demos. This makes so much sense, because it requires you to split up your work into small parts, complete those parts quickly, and demo them for the client. Each version of the build is completed in a Sprint, which is a 2-3 week work period, followed by a demo. For us a typical 2-week sprint is 70-100 team hours.

Once we started splitting work into Sprints, we noticed that larger projects needed more Sprints, and often, separate project phases. By chunking and prioiritizing work in Sprints, we learned how to split large projects into digestible pieces and create roadmaps for long-term success.

There's More than One Way to Sprint

As an agency, one of our core challenges is managing small, focused teams across multiple projects. In the strict Agile method, there's any easy solution for this -- every project has a dedicated development team working full-time on a single project.

But when you're working at a digital agency, there are often multiple projects that require attention. At EDUCO, we've modified the Sprint concept to fit our working style. We hold team sprints -- half day blocks during which a team works on one project, and nothing else. We're either sitting in the same room or on the same Google Hangout. If you need to check email, you can, but you must leave the Sprint to do so. Within the Sprint, we are laser focused on the project at hand.

Personally I've found this fun and really fulfilling because it allows for deep, uninterrupted work, plus collaboration. The Sprint is like a "safe zone" where it's OK to work on one thing at a time.

Don't Forget the Standups

At EDUCO, we've been doing a morning standup meeting since 2014. It's a 15-minute meeting at 9:30AM every weekday, where each team member shares the following:

• What I worked on yesterday
• What I'm working on today
• Any barriers

When a barrier is identified, another team member will volunteer to help, and we'll work together to remove the barrier... in a separate meeting, after the standup. For us, the standup is an essential practice for maintaining continuous, open communication among the team.

Write Features as User Stories

User stories were the first Agile tactic we adopted. A user story is a plain English feature description that follows a specific format. Here's how it works.

Let's say one of your key features is a Request a Quote Form. You might describe forms like this:

"One of the goals of our website is to collect user information using forms. We want to generate leads for the sales team. And we want to create new forms easily, on the fly." To turn this request into a user story, we need to ask:

• Who needs it?
• What do they need?
• Why do they need it?

Then, we describe the feature in this format:

As a [type of user] I want [a feature] so that I can [have a benefit, do a thing]

Following this format, we could write the following stories:

• As a marketing manager I want to promote forms so that I can increase form submissions
• As a content manager I want a form template so that I can create forms and track their submissions.
• As a front end user I want an easy form experience so that I can request a quote.

Using this method, we realized that there are three users who interact with forms: the marketing manager, the content manager, and the front end user.

Why write user stories?

We've been getting a lot of benefit from writing our features as user stories. One thing I noticed right away was that we were seeing new dimensions of common feature requests. Forms sound simple -- and in a way, there are -- but there's actually quite a bit of detail that needs to be tweaked and tuned so that all users can have an optimal form experience.

Additionally, there's value in the user story format. By following the format, we tighten up our feature requests and standardize how we ask for features. We frame each request, focused on people and business value, rather than technical specifications.

Break Down Stories into Tasks

Stories need detail. In the Agile Method, there are many ways to add detail to stories and verify their completeness. Each team does it a little differently. At EDUCO, once we've written our user stories, we break stories into tasks. Here's how we do it.

Tasks are technical units of work that can be completed and verified by developers, designers, content managers, and production team members. A good user story can be split into 3-5 tasks.

For example, let's take a common story, the Services Template: As a content manager I want a flexible Services template so that I can add, edit, and categorize our Services.

Here's how we would split this into tasks:

• Content Modeling (structuring and writing example Services content)
• Content Type (creating the Services template in the CMS)
• Taxonomy Vocabulary (creating the Services categories in the CMS)
• Content Entry (adding the approved, complete content in the CMS)

From there each task can be assigned to appropriate team member. In this case tasks must be completed sequentially -- which is typical for setup tasks. Later in the development process, tasks may be more flexible, enabling different team members to work in parallel to complete a user story.

Use Checklists for Acceptance Testing

One of the challenges in managing development tasks is reviewing the work, called Quality Assurance or QA. When a task is completed by one developer, it must be tested by another developer or project manager. The steps to test and verify the task are called the Acceptance Test.

Checklists are a great tool for writing Acceptance Tests. A checklist may be written by the developer or project manager -- usually it is verified by the project manager once a task is complete.

No Task, No Work

Since tasks are the basic unit of work, everyone on the team needs to pay attention to their tasks and take the task deadlines seriously. As a project manager, you can help with this by honoring the need for tasks and making sure that tasks have good acceptance tests.

At EDUCO we take this pretty seriously, so we operate with the rule, "No Task, No Work." If you need something done on a project, it needs a task. Conversation and team chats aren't enough. If you don't provide a task, and something gets missed, you can't complain to the development team about it.