Short, TLDR Answer: Only if you value transparency and flexibility in the agencies you work with, and are willing to collaborate to have those things.
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 while it's true that we're poorly prescient in the long run, on a shorter time scale and with smaller tasks with which we have some expertise we are much better predictors of how difficult it will be and how long it will take to complete those tasks. The various Agile methodologies attempt to take advantage of this short-sightedness by focusing on deliverables that are small, packaged into time boxes that are themselves small, which by its very nature allows less opportunity for those unforeseen gremlins to creep in and start running amok.
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:
- Communication is more important than SOPs
- Be open to change
- Collaborate more with clients
- Focus on delivering workable product instead of discussions or documentation of product
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.
Those four Agile principles, along with our core values, define why we have moved into being an Agile Agency. But even though we do elevate people over process, the process itself in the Agile Methodology is still vitally important. It's important for several reasons, but when I distill it down into its essence I can state it like this:
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 takes place over a relatively short period of time
- The work we take into a Sprint should be looked at as an agreement between us and the client as to what we will get done for them during the Sprint.
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.
Bringing tasks into a Sprint is based on a point system wherein each task is assigned points based on its anticipated difficulty to complete, which is in lieu of a time estimation for the task in any but a general sense. We would assign one point to a relatively simple task, for instance; we don't know whether that task will take an hour or two hours or three hours to complete, but we do that it's relatively simple. All tasks in the Sprint that have that same relative difficulty will likewise be assigned one point. Tasks that are seen as being slightly more complicated to complete than the set of one-point tasks will be given two points, and tasks more difficult than that might be assigned 3, 5, 8, 13 or 21, all depending on their relative complexity to complete.
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.