If you're interested in a longer-form answer, you're in luck -- read on.
As humans, we are notoriously poor at predicting the future. It's certainly true that in environments where variables and inputs are constrained, we can do decently at prediction and plan accordingly. But as we tell new hires when we do our Agile Agency training, life is fuzzy -- and the further out one tries to plan, the fuzzier it gets. Equipment breaks. People get sick. Personnel change. Your network gets hacked -- the list of unforeseen challenges that can cause long-term projects to overrun both time and budget is endless, and these unforseseen challenges are a large part of why long-term project-planning methodologies such as Waterfall almost always lead to results that come in later than planned and cost more than anticipated. To make matters worse, because we know that long-range project planning is difficult, project managers and planners attempt to get around it by attempting to create requirements documents that define every last feature, process and capability, and then scheduling the steps of the project based on those requirements. When the requirements shift suddenly in the middle of the project? Another unforeseen change that can alter the entire remainder of the project. The result? Wasted time and wasted money.
But perhaps that's getting ahead of the story slightly. In order to replace the old, cumbersome, error-prone processes, it's necessary to have a new process. This is where Agile takes an interesting approach, in that it acknowledges that while its process is important -- vital, even -- it's actually people that are of paramount importance. Let me say that again, in the way that we say it at ThreeTwelve: Elevate People over Process.
Elevate People over Process. It's an important value to hold, and it's also a promise. Agile aims to fulfill that promise by putting forth four key, guiding principles to which it asks practitioners to adhere. These principles, as we define them here at ThreeTwelve, are this:
I think it's easy to see how adherence to these principles helps to elevate people over process. Elevating people over process is baked into our agency DNA -- when we do customer interviews with our clients, over and over again they call out the collaborative nature of the way we work with them, and the quality and value that it allows us to deliver. Having those kinds of relationships has always been one of the values of ThreeTwelve -- and so, when we first considered adapting Agile practices to create a true Agile Agency environment, it made sense to us and felt like a natural extension of who we already were.
Without process, it's hard to get work done efficiently. Of course, we're a business, and the more efficiently we can operate the better. But one of the things I always keep in mind is that our clients are also businesses and people both -- and if we're truly interested in delivering value, and we're truly interested in elevating people over process, then safeguarding the interests of our clients should also be of paramount importance to us. Therefore, the process should by its very nature lend itself to subordination. It should, by its very nature, let us elevate the client over the processes we use to get their work done. The Agile Agency process that we've adapted from more traditional Agile practitioners (I'm looking at you now, Scrum) allows us to do that.
The heart of our Agile process is the Sprint, for which there are a couple of important rules:
The Sprint timeframe is up to the team that implements it; in our case, our Sprints are always two weeks / 10 business days long. Having shorter Sprint durations allows us to focus on the Agile principle that we should be creating deliverables instead of documentation. In the software development world, this means that the team focuses on delivering a minimum viable product (MVP) that then gets iteratatively improved in subsequent Sprints. The concept of an MVP is most applicable to our agency work when we are doing things like building microsites, but it does bear relevance, too, in other areas.
For example, we are sometimes tasked with writing a script for a client before the client themselves fully know what they want. Instead of waiting for perfect clarity from the client before we begin scriptwriting, we will take the client's initial brief and focus on delivering them something viable. Sometimes the script will be approved with few or even no changes, because once the client reads it they could see that it aligned with their needs. Sometimes, after reading the script the client will come back with substantial revisions or even decide to change tack completely; but in either case, having that MVP version of the script allows them, in large or small ways, to clarify their thinking and iterate until the end product is exactly what they need.
The second of our Sprint rules, that the work taken into a given Sprint represents an agreement between us and the client, is a key principle in the Sprint process. Every two weeks, we meet with the client in a Sprint planning meeting and talk about what tasks they need us to work on in the coming Sprint as well as the order in which they should be prioritized. This collaborative process gives us greater insight into the work we need to get done over the course of the upcoming Sprint, and it also gives the client a very clear idea of everything they can expect to have by the end of the Sprint.
You might have noticed that instead of a linear range of point values that we might assign to a task, the possible point values from which we choose are in fact a Fibonacci sequence, and the difference in possible points we estimate gets increasingly larger as the task becomes more complex. This is a direct acknowledgment of our difficulties in being accurate time predictors in the longer-term, and relatively good at prediction in the short term. We can say, with pretty good accuracy, whether a simple task should get one or two points, but beyond that it gets progressively harder to divine -- and so the possible points we can assign reflect that.
The number of points we bring into a Sprint for a client are based on the point capacity of our team that's handling that client's work. That capacity is a known quantity, and so at the Sprint planning meeting with the client we bring in tasks for the Sprint until the sum of points for those tasks is equal to the team's capacity to get the work done. It's a balancing act of capacity and the needs and priorities of the client, and it's a prime reason why the desire and ability to collaborate amongst all parties is so important to this process.
Another key component of the Agile methodoloy that we're committed to honoring as an Agile Agency is that the Sprint process should be transparent to all involved. That means that our clients can, at any time, check in on the Sprint and see the current standing of all the tasks. To accomplish this, we're currently using third-party software to create a Sprint board that's accessible by invitation to the client. The Sprint board shows all tasks, which are grouped as either Current Sprint, Working On, or Done. The Sprint begins with all tasks that have been agreed to in the Current Sprint group; as team members take a task to work on, they put their name on it and move it to the Working On group, and when they complete that task they move it to the Done group and then go get the next Sprint task to be worked from the Current Sprint group, and the process repeats.
Because the Sprint board is online and accessible to the client, the level of transparency this affords to all involved is phenomenal. On the agency side everyone from partners down through team leads to individuals, and on the client side anyone they think should have visibility, can see at a glance what tasks are to be done in the current Sprint, what's currently underway, and what's been completed. This is in stark contrast to the kind of relationship that many businesses have with their agencies, which traditionally functions more as a kind of black box: The client provides the inputs and the agency will ultimately output work for approval, but what happens in between and where the agency is in the process remains in large part a mystery to the client.
Hopefully this guide to the way that we as an agency have implemented Agile will help you answer questions you might have as to whether working with an Agile Agency is right for your business. It does require commitment to work in the Agile process, but it's a commitment that leads to collaboration, transparency, and results. It's also a work-in-progress, and we're always working to make it better -- and that kind of rapid, iterative improvement is
If you'd like to see the SlideShare we use to train new hires and onboard new clients, it's embedded at the bottom of this page.
If you'd like to talk more about what it's like to work with an Agile Agency, feel free to use the form below to get ahold of us.
Interested in a high-level overview of internet marketing best practices? We have that covered for you, too: