On (Agency) Agile™
In the same way that smashed avocado on toast is Australia’s biggest innovation in the last decade, the biggest “innovation” in digital agencies in that the same time period has been stealing and bastardizing Agile, mashing it’s incompatible principles into the old school agency model. Like the quote from Tyler Durden in Fight Club, “Sticking feathers up your butt, does not make you a chicken.” or, in other words, “Running waterfall projects with standups does not make you Agile”.
While Agile itself isn’t new, the way agencies typically discover and implement it is analogous to other industries attempting decade long “digital transformation” projects without really knowing what they’re talking about or why they’re doing it.
First contact (2011)
My very first exposure to the existence of Agile was back in 2011, when I started receiving spam emails at work, which offered 3 day courses to learn about something called “Scrum”, that would apparently solve every problem known to man. I recall this because my co-workers received the same emails, and we would joke about who would fall for this nonsense.
Fast forward about a year, and one of those co-workers who was formerly a backend developer, who literally transitioned overnight to be a project manager. Their first order of business as the newly appointed project manager was to implement Agile/Scrum into the agency (the entire company consisted of less than 6 people at the time, including the owner and myself).
I thought it was a joke, so I asked:
“Is this a joke?”
To which they replied:
“No, it’s not a joke. I read some articles online about it last night and this is what we’re going to be doing now.”
I’ve since come to learn that it still doesn’t take much more than this level of research or training to proclaim that you’re some kind of Scrum master, or project manager who knows “Agile”.
This began to plant the seeds of what I would personally see to evolve into one of the most destructive and misguided trends that the agency landscape has adopted since it tried (and failed, miserably) to “do SEO”.
The messy middle (2014)
After the somewhat harmless attempts I saw at my first agency, I finally joined my first real Agile project team in 2014, while working as a frontend developer on the rebuild of a large website for a well known brand. Unlike my previous exposure to Agile, this was a sizeable team of supposed expert consultants who would work on-site with us every day for 4 months. We had: 1 project manager, 2 scrum masters, 2 full-time producers, 3 account mangers and half a dozen backend developers (also consultants).
On the flip side, to handle the entire design and front end: it was just 2 frontend developers (including myself), 1 tech lead and 1 designer!
This project was a fixed cost, fixed scope with a fixed deadline - and not one of those “fake deadlines” - if we didn’t launch this new site in 4 months, the current live site was going to be taken offline by the previous agency, due to their contract and hosting ending.
We worked in 2 week sprints, did all the typical “ceremonies”, and had 360 degrees of our project room covered in a post-it note kanban matrix, which for some reason needed to physically mirror what we already had in 2 different web based project management tools (JIRA and Asana). I guess that’s why we needed 2 scrum masters, one to continually keep the physical post-it notes in sync with digital ones in JIRA and Asana.
However, it wasn’t long before I started to see some major red flags; namely, that any failure in meeting the amount of work the developers on the project were meant to finish was received with positivity and an “Okay, no worries, we’ll just push that over into the next sprint”.
When it came time for the retrospective at the end of every fortnight, we brought up all the issues we faced. Ever time it was the same issues, with zero change observed or implemented by anyone leading the team. It got to the point when we started filling the “What worked?” column of the retro whiteboard with post-it notes simply saying: “Literally nothing.” and under the “What didn’t work?” column saying: “Literally everything.” The entire thing really felt like a twisted inside joke, except for the fact that clearly nobody running the show was actually in on it.
This trend continued for months into the project, until it got to the point where we had pushed so much out into future sprints and had been so forgivingly slow, that the (fixed) deadline of getting the site live was now a couple of weeks away and the entire project was nowhere near being completed.
The project manager’s answer to this, in the few remaining weeks of the project was getting all the developers to just work late every night, typically until around midnight, but sometimes until 5:00am. I personally slept at the office a few times in this period. We were brought energy drinks, candy and other trash to fuel us through this trek into the the failed Agile abyss. When this still wasn’t getting us far enough, all of us coming in and working on the remaining weekends was when we really hit rock bottom.
At this point, anything related to “Agile” had long since deserted us and now we were truly in the thick of it. When the scrum masters and project managers finally just got out of the way, and literally stopped coming in (allowing the people actually doing the work to figure it out), we were able to do more work in the final 3 weeks than we did in the first 3 months.
We ended up getting the site live by the skin of our teeth, but the development team or the site was certainly not in the best shape after that final ordeal, and because it had to be rushed, the next 3 years were spent cleaning up the mess that was caused in that initial 3 months of carnage.
In Scrum, no one can hear you scream…
Today (2020)
Since then, I have been involved in many, many other Agile projects/teams and talked to countless developer/designer friends and acquaintances at other agencies and companies that also try to use “Agile” as the magic bullet for their projects.
Without fail, every single story I have seen and heard about these projects has resulted in a disaster; to the point where I will accurately guess exactly how a new story ends before they’ve even finished telling it.
In agencies specifically, it’s often a predictable and totally preventable recipe for disaster.
The reality is that agency projects tend to have 3 immutable properties:
- A fixed deadline
- (which results in) a fixed scope
- (which results in) a fixed budget
Yet, in practice, because they decide to subscribe to Agile propaganda without giving it more than 3 seconds of critical thought, they end up running the project in a way that is totally incompatible with the 3 truths above.
There seems to be a conscious delusion to ignore some things, and still adopt Agile principles. For example, “welcome changing requirements, even late in development” is incompatible with every single one of the truths above. If you were to do this, it means that the original fixed deadline now needs to be flexible and extended, the fixed scope now needs to change and increase, and the fixed budget will not magically cover the additional time required to implement and test all these changes.
This seems so obvious at face value, yet the narrative I see and hear over and over again says otherwise. Typically, changing requirements (even late in development) will be welcomed, but none of the truths above are changed. This results in that perfect storm, where before you know it, the project has either reached its deadline, budget (or both) and the scope, which has gradually become much bigger in that fantastic place known as the “backlog” can not be fulfilled.
The people who came up with it don’t like it
In his 2014 article, Agile is Dead (Long Live Agility), Dave Thomas wrote an article about how off-track the initial idea had become.
The word “agile” has been subverted to the point where it is effectively meaningless, and what passes for an agile community seems to be largely an arena for consultants and vendors to hawk services and products.
He gave basic instructions to do something in an “agile fashion”:
- Find out where you are
- Take a small step towards your goal
- Adjust your understanding based on what you learned
- Repeat
Also including a single line on “how to do it”:
“When faced with two or more alternatives that deliver roughly the same value, take the path that makes future change easier.”
And that’s it. Those four lines and one practice encompass everything there is to know about effective software development.
Likewise, Martin Fowler wrote an article called The State of Agile Software in 2018, where he also called out the sad truth that while people think they’re “Agile”, it’s actually a cartoon version of it that actually goes against the original values and principles.
On the surface, the world of agile software development is bright, since it is now mainstream. But the reality is troubling, because much of what is done is faux-agile, disregarding agile’s values and principles.
Others involved in coming up with “The Manifesto for Agile Software Development” (the original title, which was subverted to “The Agile Manifesto” and shoehorned this approach for developing software into doing everything) have also come out to disapprove of what it has become.
The people doing the work don’t like it
There are some principles of Agile that I think do make sense; one of them being “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”. Ironically, this is the first principle to get thrown out the window when an agency Agile project begins, when the project managers dictate exactly how things are going to go down, and do not trust anyone to do anything without them setting up how it’s to be done.
For some reason “Agile” automatically invokes “Scrum”; in other words, if you’re going to be “Agile”, your team is definitely going to adopt “Scrum” as the way to implement the principles of Agile - this happens so reliably that I truly believe most people (those running the projects and those actually doing the work) don’t even understand the difference between these two terms, because they have become one and the same, when in reality, they are mutually exclusive.
There is simply no quicker way to de-motivate and kill the soul of an already great project team (ie. designers, developers, creatives) than trying and impose top-down micromanagement garbage like “one-size-fits-all” approaches to implementing Agile principles with a pre-defined framework like Scrum.
The best people are self-managing, they don’t need or want their tasks broken down into epics, stories, tasks, sub-tasks. That’s not how the creative process operates, and by thinking it is, you’re removing the magic of actually doing the work.
When I observe that my co-workers are spending more than 50% of their time in meetings or Agile ceremonies instead of actually doing their work, that’s a huge red flag.
The “Spotify Model” trap
After the initial Agile fever dream started to wear off, it was interesting to see a bunch of agencies start talking about adopting “The Spotify Model”, which is essentially an overly complex approach of structuring team that was tried at Spotify. The ironic part is that it didn’t work at Spotify; something they’ve tried to tell the world multiple times since then, but it was too late. Everyone hears about “The Spotify Model” and probably know it’s something vaguely related to “tribes”, and if Spotify is doing it, then it must be the answer to all their problems, too.
Unfortunately, this doesn’t work. Even if the “The Spotify Model” worked amazingly for Spotify (which it did not in reality), the chances of being able to copy that 1:1 into an agency environment (which is fundamentally different from a company like Spotify in terms of size, function and customer base) are so low, that it’s not worth upending everything to do so.
What’s “the answer”, then?
“The answer” implies that there’s a single way of structuring teams or working together that will fix all your problems overnight; that is the promise of these crazy Agile/Scrum bootcamps that will make you an “expert” on this over a weekend retreat, and be able to force a foreign predefined set of rules into a local team, and just assume the patient won’t reject the transplant.
Yes, I’ve been railing on Agile like there’s no tomorrow, so what’s the alternative? I would say it’s probably thinking for yourself instead of looking around at what everyone else is doing is the “boring” but more true approach to answering this question.
Companies like Basecamp have come up with their own ways of working internally (which they released as the free book called Shape Up). They reject things like the 2 week sprint in favour of a 6 week development cycle, punctuated with a 2 week period at the end of that cycle to do whatever you want. Again, this is not going to work 100% for a digital agency, for example; but you could cherry pick one or more of the ideas they have that would make sense to try out.
The “South Park model” works, but you shouldn’t copy it
On the other end of the scale; if you look at the production process that goes into creating an episode of South Park; where they go from having a blank piece of paper, to airing an episode in 6 days… do you think they’re using “Agile” or “Scrum”? 2 week sprints? No, of course not. They don’t even have enough time for a single 2 week sprint when the entire episode needs to be written, animated, voiced and shipped in 6 days straight.
Just because it works for Matt and Trey and their small-ish team, does not mean that this will automatically translate over to software development. Again, there are lessons you could cherry pick from their approach (eg. “done is better than perfect”), but adopting a “6 days to production” for your web projects is going to have some fairly predictable downsides.
Death to Agile™
Every developer (and now that they’ve been roped in; designer) I know is waiting patiently for everyone else to realise that trying to blindly force Agile™ into an agency environment doesn’t work, and how much they hate it.
I believe that on a long enough timeline, the wake of destruction that has come out the other end of large Agile projects will eventually render blindly subscribing to the cult of Agile unsustainable; in terms of financial losses, trust from clients, morale or teams and the predictable track record of failed projects.
Most of these failures never see the light of day in the public eye, usually restricted to private conversations with fellow designers/developers in the agency world where “war stories” are shared; however, I’ll leave you with a recent public failure, where an Agile website project that cost tens of millions of dollars went so sideways that the agency responsible for delivering the site is now being sued by their client. These stories happen all the time, but don’t get made public, for obvious reasons.
So, before adopting “Agile” or predefined methodoligies like Scrum or the “The [insert X company here] method”, it’s worth being a bit more introspective and actually look at your own team/company and figure out what will work best for you (not another company you’re trying to emulate).
