Breaking All the Rules in a Digital Agency, to Fix One Company Value
It was almost four years ago I left my position at an international brand. I learned a thing or two about working with agencies worldwide. I felt attracted to switch sides, broaden my horizons, and pursue my passion for Scrum. I met with the owners of a Digital Agency, about to embark on one of their biggest projects so far, a digital platform for one of the fastest-growing Dutch enterprises.
A short tour of the agency:
“In the building next doors we keep the Marketing Macaws. Upstairs the Management Lions. The room over there, with the loud music, the UX Giraffes and Design Penguins. And, all the way over there we keep the Code Monkeys, distributed over three teams, each overseen by the Project Manager in the glass box. Oh and in the basement we keep the server guys as well as some juniors and trainees: our first line support, issue and maintenance team.”
Upon joining the agency, in my first encounter with a client, I witnessed outrage. A client arrived that morning unannounced and demanded to see a demo of a specific item (#1965) from the Project Manager. Neither the Project Manager, nor any of the developers present, could produce any information about the item, save that it was marked as “done” by a Back-end Developer, who was enjoying his second week of vacation camping with his family.
“Everything is late! And that which is supposedly done, isn’t!”, the client raged.
Overrun budgets, missed deadlines, conflict over scope, miscommunication between other parties over integrations, conflict over poorly specified time entries…
The angry client and Project Manager seemed to find common ground in naming and shaming certain developers. What surprised me most was, after the ‘meeting’ was over, everyone went back to work like business-as-usual. SNAFU.
“Now you know why you are here”, the Project Manager smiled, nudging his elbow at me. I froze, already deeply regretting the choices I’d made.
I had a conversation that same day with an executive manager, about how they were keeping track of customer satisfaction.
“We’ll know the customers are satisfied when they pay their invoices on time”.
I laughed, but the executive wasn’t joking.
I stayed until the office closed, inspecting every account diligently, wondering why the invoices were paid months past due and some not at all. The executive cryptically told me none of the customers were satisfied.
Driving home I pondered the choices I had made.
“How was your first day, dear?”, my wife welcomed me home.
I felt defeated before I even started.
Digital Agencies tend to overrun on both budget and time. Money in return for effort, which in turn delivers value by a certain time, may sound like a fair deal. Fix ‘scope’ and chaos ensues. A budget restraint iron contract (‘fixed time, scope & materials’) is still one of the most common understandings between a Digital Agency (as the vendor), and a brand (as the client).
“What will I get, how much will it cost, and when will it be ready?”
In this dynamic, the client will naturally desire maximum value for a minimum amount of time, effort and materials spent. Fair enough, right?!
It’s quite common, in the digital services industry, for brands to demand pitches and assignments to be performed for free on spec (#saynotospec). The partnership is sometimes ‘rewarded’ with a demand for ever-increasing fee reductions in return for the brand’s promise to not look elsewhere for similar services.
In turn, some agencies will add ‘early exit-clauses’ to dissuade clients from ducking out early. Or, for example with Scrum: a Money for Nothing and Your Change for Free model. Often the brand only pays the invoice when the work is deemed satisfied at one’s discretion, often months past delivery. Sometimes payment is held hostage during scope-disputes.
“I’m not paying for X until Y is done!”
Primary drivers to pursue operational excellence generally are:
- increase productivity
- increase market adaptability
- maximize value
But this is jumping the gun. Making more money faster at less cost is not a value proposition. Understand first which values are paramount when servicing clients. Any operational improvement that follows has to stem from those values.
Any organization pursuing meaningful change should start by learning what the company truly values. This starts with the Executive/Founder/Owner. This requires an ability to sense the differences between what leadership preaches and how leadership behaves.
With resource efficiency as the main driver, project work will be valued over training and improvement.
“We lack qualified and talented personnel! Look at how much crap goes out the door!”, the executive remarked.
“Well”, I argued, “they rarely get to work on personal or team development”. Retrospectives and improvement plans were a thing yet unheard of. Post-mortems on the other hand…
“They’re hardly billable!”, the executive continued, “They should work harder first!”. He slammed his fist on the table. “Training! they should do it on their own time! Pizza-sessions… late night Pizza-sessions; I don’t mind paying for those…”
There is a difference between having principles and living your principles.
Truth is, qualified personnel is the biggest challenge for most Digital Agencies (33,3% — 42,1%). They also value profitability (28,6% — 38,9%) over adaptability to market (5,6% — 8,7%)*.
Operational Managers and Project Managers often receive targets and bonuses for increasing billability. After all, that’s “The Goal” of a digital agency, right?
Billability drives the need for resource efficiency, which causes the agency’s culture to value ‘reaping’ over ‘sowing’. Another catch-22 for them, as the latter activities aren’t directly billable.
Agencies that value reaping over sowing will reap less.
When driving resource efficiency it’s all about increasing productivity, productivity, and you guessed it: productivity. The drive for resource efficiency drives the agency’s habit to engage in a ‘Deliver and Forget’ mindset, turning them into ‘feature-factories’. Output, output, and output!
“It should have gone without saying that X should have been part of Y! It’s completely unuseable without it!” the Product Owner argued at a developer. To which the Developer replied: “I know X should obviously be part of Y, but it wasn’t specified. And if I’d added it, it would have taken more time…”
Even though the developer knew something essential was missing, it was never raised, neither as a concern nor a suggestion. It’s sh*t like this caused by practice and habits that stem from the wrong value.
When agencies truly value servicing the customer first and foremost, they value discovering customer needs (which requires creativity), validating hypotheses quickly (requires transparency and inspections), pro-actively suggesting improvements, self-organization and adapting to learnings quickly (requires flexibility). Outcomes, outcomes, and outcomes.
Let’s dive into the primary operational practice, which stems from resource efficiency, which is enforced by nearly all Digital Agencies:
The agency strives to maximize the time and effort it can spend on a client, to drive billable time, as this is what drives the agency’s main source of revenue (on avg. 76%**).
This is the percentage of hours a specialist is billable in relation to its capacity (hours at work). In short, the goal is busy agenda’s with project work finished timely.
“Don’t you have a planning event with the team?”, I asked the Project Manager. “No”, he replied, “There is no need. I manage their agendas for them”.
The Project Managers were playing Tetris with agendas. Every bit of work was pre-schedule when it should take place, what should take place, and how long the team member had to complete it. Team members had to press a toggle on their desktop when they started an activity and when they finished it.
Now, when the agency’s specialists discover more efficient ways to work, one would argue, it would enable them to deliver more value in less time. This would give them an edge in the market, as they can promise more value to brands for smaller budgets. However, the type of efficiency agencies strive for, is resource efficiency… (maximizing billability), not flow efficiency (minimizing lead time, whilst maximizing value-adding time for the client).
Time-tracking, needed for determining what to bill clients, has some additional toxic side-effects. To be able to assess investment, the client will need time-estimates. Time-estimates, in turn, will be treated like time-boxes. Shit, I even witnessed stopwatches being set for developers to complete a task within.
Brands, for all their faults in engaging agencies, are (or should be) righteously concerned over ‘scope creep’, ‘over-servicing’ and ‘creative time-reports’. The agency, after all, has full control over how it administers and communicates the time and effort spent. Brands may naturally demand visibility over how well the time is spent to assess if it was valuable time spent. After all, Graham’s Law tells us:
“If they know nothing of what you are doing, they suspect you are doing nothing.” — Graham’s Law.
Furthermore, an agency might even bet on exploiting the client through the following law:
“There are two states to any large project: Too early to tell and too late to stop.” — Fitzgerald’s Law.
This law applies primarily in Waterfall as the outcomes are only delivered at the very end when the budget is spent, and all the time has expired.
Agencies know fully well when a project reaches its ‘too late to stop’ phase and can destructively exploit the Sunk Cost fallacy. After when a client is heavily invested, it won’t pull out. At the mid-stage project, when everything seemed to be going so well, this is the moment where the agency decides its time to talk about all that scope-creep the agency so flexibly and pro-actively worked on along the way. This happens, consciously or not.
Scope creep poses a serious challenge with iron contracts; this is why the iron contract is the nemesis of agility. What’s more, work hardly ever finishes ahead of the estimated time. Regardless of all the built-in time-buffers. With up-front estimation, Parkinson’s Law applies:
“Work expands to fill the time available.” — Parkinson’s Law
And even when work is finished ahead of its estimated time, what would be the incentive for the agency to report it? If the work is finished in half of the estimated time, why deliver full value for half the pay? A specialist might proudly report his or her’s achievement, but they quickly learn not to, as they now need to deliver twice within the same time, just to remain equally billable. It’s only ever valuable when playing catch-up, or if the customer is charged for estimates, not actuals. So although Scrum’s mantra of ‘twice the work in half the time’ sounds appealing to the brand, to most agencies, however, it may sound like “twice the work for half the pay”.
What’s more, there will be discussions between the brand and agency on what types of work are billable. Are discussions between specialists billable? Are pre-work and re-work billable? What if the quality that was delivered was below par? should the client pay for effort spent on optimization, fixes, unknown complexities, and resolving impediments? what about feedback rounds?
And this is how we arrived at:
“It should have gone without saying X should have been part of Y”
When work expands beyond the estimated time, the Project Manager isn’t looking forward to motivating the reason for it to the client. Nor is the developer looking forward to having to motivate it to the Project Manager, but it will end up in the books and it will end up delaying the project.
Some might argue that this dynamic creates a natural almost healthy tension between the client and vendor, the specialists and the project manager. But it can turn mechanical and toxic real quick.
Back to values. If servicing customers is valued first, the company will value tracking outcomes over tracking time.
“Track outcomes, not time!”
Moving to Scrum …
Digital Agencies in the Netherlands are revolutionizing to Scrum. Where it was 26% in 2013 it more than doubled to 59% by 2017**. This should be taken with a grain of salt, however. Agencies that say they Scrum, rarely really Scrum. Many creatively tailor it to their own ‘special, not special’ needs and ‘sorry, not sorry’ adaptations to, de-facto, dance around real changes and effort involved with enhancing agility. A harsh judgment, I know, but a real problem.
I joined the first agency, still operating Waterfall, as a Scrum Master. After the first two weeks, I had my first personal review.
“Nyland, take a seat. We just wanted to let you know you are doing an outstanding job as a Scrum Master. Thanks to you we have a far better picture of what Scrum is about.”
Wow. I was in dire need of a motivational pat on the back. I relaxed, sat back and breathed a sigh of relief.
“However”, the executive continued, “All this stuff about empiricism, self-organization, and cross-functionality, that’s just not really realistic at the moment.”
I shot straight back up.
“See, clients need to know upfront what to expect in terms of time and cost or they won’t sign any contract. The specialists are totally not mature enough to self-organize their work, and really, designers and developers just don’t get along in the same room together.”
I tried to resist the urge to face-palm. “But isn’t this why I am here?”
“Well, yes! and, we think it’s best to broaden our view with ‘Agile’. We really want to become ‘Agile’. What we really need right now, is not just a Scrum Master, but an Agile Coach!”.
They persuaded 💰 me to pivot to an Agile Coach instead. I naïvely agreed. After all, Agile Coach is a far cooler title…right? 🤑
Although the title changed. I didn’t. The rebel. Not one bit. Scrum on!
Rather than passing work from silo to silo, I pressed on. The teams were self-organized to cross-functional teams.
“Even the designers?!”
Yes… even the designers.
The teams started self-organizing their work and forecasts by making it visible on a shared physical board, during regular Sprint Planning, which they updated daily.
And as for the contract conundrum. What does “Customer collaboration over contract negotiation” actually mean when put in practice? We explored this question together with our clients.
Together they learned to manage scope in a dynamic backlog, rather than a fixed contract or requirements document. Rather than the Project Manager, it was now the client-side Product Owner who’d monitor and control the scope and manage the budget.
Having further enabled flexibility in scope thanks to dynamic backlogs, they also started moving away from fixed time, thanks to Probabilistic Forecasting. This dynamic forecast often spanned multiple Sprints.
Although we’d started using physical boards as a means of providing visibility, it didn’t last long.
“Physical boards? we’re a DIGITAL agency!”
I tried to explain the value of allowing teams to self-organize their tools. It was too much too soon. There was simply no way to keep a solid administration with post-its and magnet-cards they argued. They just had to keep using Jira. Jira had a next-gen Scrum version after all…
I suffered a lot of ridiculous setups where teams would sit impatiently and inattentively around a table, with JIRA on screen, watching one person follow instructions, typing Stories, correcting spelling errors whilst updating the board…
Through Jira Next-Gen, they were introduced to Story Points. Rather than just tracking effort, they were now also tracking Velocity.
“Velocity is a measure of the amount of work a Team can tackle during a single Sprint and is the key metric in Scrum. Velocity is calculated at the end of the Sprint by totaling the Points for all fully completed User Stories.” — Scrum Inc, source
But here we arrived at yet another conundrum. The whole purpose of Scrum is to minimize complexity whilst maximizing value. Story Points are a unit of a relative estimation of complexity provided by the Development Team. Ergo, Velocity should serve mainly as a tool for the Development Team to empirically be able to predict reliably how much it can take on in a Sprint. But guess what… we encounter yet another law:
“When a measure becomes a target, it ceases to be a good measure.” -Goodhart’s law
Ironically, rather than just being motivated to being fully billable, agencies will have a measurable incentive to maximize the amount of complexity (Story Points) resolved each Sprint. Story Points will become a measurement of Scope and, there you have it, the agency will want to deliver, at the very least, an amount of Story Points each Sprint relative to the number of hours (capacity) a team spends on resolving them. This is why Digital Agencies hardly ever seem to break away from the anti-pattern of equating Story Points to Hours Worked.
“How many hours is a Story Point?”
Most Dutch Digital Agency’s struggle with staying focussed**. They operate in a fast-paced, complex market. They service numerous clients, who have an irregular pattern in demand.
The drive for maximum resource utilization (keeping people busy) has yet another downside. Working for a broad portfolio of clients they can rarely focus on one client at a time. Sometimes they run various projects with shared specialists at the same time, whilst also processing lots of smaller tactical requests streaming in from other accounts.
The agency didn’t have clients with budgets to provide for the upkeep of a cross-functional team over an extended period. This is where, again, we departed from Scrum. Instead of focussing on a single product, teams worked on numerous ones at the same time. They organized their Sprints and forecasts with work pulled in from numerous backlogs. This naturally resulted in a loss of focus, context switching, large WIP, and an increase in total lead times. Ugh. But hey, this enabled specialists to be properly busy and highly billable, whilst keeping up a façade of progress for numerous clients on an ongoing basis.
But to an agency’s client, this picture doesn’t look so pretty. An item that only took 20 minutes of actual work, could have had a total lead time of two weeks.
“Jen, I am ready with my part for Story #1422, can you pick it up?” Danny said to Jen. “Sure, Dan, but I’m busy. Can you do me a favor and forecast it for the next Sprint?”
Swarming seriously reduces total lead time, but the stubborn conviction that prevailed was that, although this would be good for the client, this would decrease resource efficiency.
So how could we force a breakthrough? Would clients be willing to pay more for an outcome if we’d deliver faster in terms of total lead time? If the answer to this would be “yes”, we would finally have the commercial motivation to value flow-efficiency over resource-efficiency.
“No”, the Product Owner argued, “why should I pay more for something that takes less time? Why can’t they deliver it faster and cheaper in the first place?”.
When a Sprint consists of work from numerous clients with various Product Owners and lots and lots of Stakeholders… how the hell does one organize effective Sprint Reviews?!
Breaking the status quo!
At this point, any solution would likely be deemed too revolutionary or out of the world to be acceptable at all. The amount of explaining and convincing I would have to do to reach a consensus over a new solution became a problem in itself.
The average billability of Dutch Digital Agencies in 2018 was 62%. Ironically perhaps I learned it was the time/effort-based approach that was holding the company back. But I felt like I was trying to solve a problem that no-one desired a solution for.
But I wasn’t ready to give in. As Niklas Modig put it in his Ted Talk on the Flow Efficiency Paradox, “We want to reach the star!”. So did I. Increase both resource utilization and flow efficiency, where both players win.
Reality is subjective sometimes. I felt trapped in the paradox outlined by Niklas. I wasn’t ready to give in just yet. And it appeared I wasn’t the only one. Perhaps I could learn a thing or two from other industries.
This book provided for an epiphany. Everything the agency was doing, stemmed from the wrong values. If we ever wanted to change anything for the better, we’d better truly put the customer first.
I lured a team into a room, locked the door and wrote down a Sprint Goal on the flipchart:
I expanded by explaining… if we truly want to maximize value-adding-time, decreasing the total-lead-times, how should we go about it?
Something magical happened. In two weeks:
- They finally created transparency over what “done” actually meant!
- They got to “done” together, before calling it a day. This meant leaving little to no work-in-progress at the end of the day.
- They adopted the mantra “stop starting, start finishing”!
- They Limited work-in-progress, ending the progress façade. 5 slots max at a time (their average WIP was 18). They made them visible on a physical board in the workspace. When one goal was done, it made room for another.
- They stopped pairing and swarming as if it were a luxury. It became mandatory.
- They invented a ‘hot-potato strategy’ to minimize hand-over and change-over times between members.
- They visualized (the steps of) work on the board beneath the goal.
- They visualized impediments on the same board.
- They ruthlessly removed impediments (shoot the donkey style).
- They introduced the Jidoka, ‘stop the line’ mindset and applied it right away to create automated tests and deployment pipelines.
- They again stopped the line to attack Technical Debt by updating all current project’s back-ends to the latest versions.
- They pro-actively involved stakeholders and organized instant reviews for even faster feedback.
- They refined everything the very day it came in.
- They developed a fast ‘disagree and commit’ system in order to keep work flowing.
- They convinced Product Owners for an experiment to abandon time-tracking in favor of value-tracking.
It was amazing. It was brilliant. And…
… velocity plummeted into a pool of despair.
“Multiple people working on the same thing at the same time? insane! And what?! stopping all of the work in order to fix an issue in the pipeline?! What?! they did it twice?! just to update composer everywhere? and… no…you…gotta…be…. no one…. NO ONE entered their time-reports for two weeks! NUTS!
Knowing I was probably done for anyhow, again I stopped the line. We had to resolve this. We entered each outcome in Jira and marked them “done” (“done done” this time). Thanks to a spontaneous ingenuity by two developers, applying some API wizardry, these made their way to the invoice system automatically for its pre-arranged value the Product Owner had agreed on. Us rebels.
“There is something wrong. This can’t be right. What?! you let a developer mess around with the invoice system?! This time, you really crossed the line!”
I promised I’d fix it and it would all turn out okay. But truth was, I had little faith it would. I explained to them not to worry about billability. But we still had no clue how to bill the clients properly without the time-reports.
Over these two weeks, at an unprecedented, ever-increasing pace, the lead-times decreased. Flow efficiency surged from less than 2% to over 20%. At least something was moving in the direction we wanted it to.
The end of the calendar month arrived. D-Day. The invoicing process, which used to take two full days, now finished in a heartbeat. After all, no more time-tracking inspections and approval processes were needed anymore. No more frustrating back-and-forths with developers for clarification on-time reports were needed anymore. The invoices nicely displayed an overview of all the “done” outcomes at their pre-agreed fees, which could be submitted instantly. Woosh.
Half an hour later the financial director approached me. Out of breath.
“How’s this possible?! You’ve billed the clients way too much! there is something wrong with the API. It’s even over a 110% billability, which is impossible — Nyland, fix it now!”
I despaired. The developers who built the API panicked. We expected a much lower value compared to the normal billability of ±43%, not an impossibly high one.
We’d never run the numbers over all the work we’d completed. We weren’t seeing the big picture. Although we focussed on achieving valuable outcomes for customers, we were not paying any attention to contracts, scope specifications or even velocity in the last two weeks. We were truly in a flow.
I checked the invoices while the developers checked the API. Half an hour later, we were confident. We didn’t break the invoice system. We fixed the company.
We celebrated. The team earned an ironic title: ‘Team Billability’. But unfortunately, we celebrated way too soon.
Like how a bowstring shoots back faster than all the time and effort it takes to draw, so did our value delivery.
Why?! What happened?!
Well, as it turned out, value delivery indeed sped up at first. Quite dramatically in fact. But remember the part about reaping, not sowing?
- New demand didn’t ramp up, yet delivery did!
- The client’s budgets exhausted much faster!
New demand itself became Herbie, the bottleneck, the constraint; the speed of value in, now dictated the speed of value out. What’s more, it caused people to be even less busy. They began riding the wave, waiting almost desperately, for valuable work to stream in.
But how did management interpret this? their old nature kicked right back in.
Hmm let’s see:
1. value delivery is slowing down … and 2. people are not busy…
Ergo, it must be decreasing because people are not busy, right…. RIGHT?! Therefore resource efficiency must increase. Flow efficiency must be abolished. And as for the cherry on top… I received word my contract was not going to be extended.
Although I had my fair share of the agency and its management, I wasn’t ready to throw in the towel just yet.
I know that the company’s focus on value delivery meant little to no focus on value discovery. And although outcomes were achieved, a thing or two could be said about the quality at which they were!
To battle these final conundrums, at last, but not least, a great deal of my last effort was to be spent with Team Billability on sowing. Meaning everyone on the team spent time advising clients, suggesting improvements, exploring commercial opportunities, discovering ways to increase quality.
We applied Service Design Methods as a Scrum Team, co-creatively, together with Product Owners and stakeholders. And what-do-you-know, they loved it, valued it greatly! and even began paying for it. The agency even reaped for its sowing.
As for quality, the strain on delivering outcomes fast, getting increments out the door and validating hypotheses quickly through Lean UX, counter to our expectation, it did not intrinsically motivate developers, nor did it result in all that much excitement from customers. MVP wasn’t very sexy, excitable nor loveable.
Team Billability was still a feature-factory.
The team adapted by realizing not all outcomes had to be functional. They had to transcend from feature factories to value maximizers. All the way up the pyramid.
As an example, a question from a client “Can we have our phone number in the footer”, was followed up by a co-creative workshop on “How can we help the client become more accessible to its customers?”, through which far more valuable (and meaningful) ways were discovered and ultimately realized.
Ultimately Team Billiability transcended to becoming “The Maximizers”. Right in time for me to move on.
So there you have it, an account on moving from resource to flow efficiency, billability to customer-centricity, output to outcomes, feature factory to value maximizers. A Herculean endeavor of which this account is just the tip of the iceberg.
We broke a lot of things and a lot more rules. We broke the iron triangle, we broke silos, we broke time-tracking, we broke the feature factory, we broke productivity and broke resource efficiency… to fix one value.
So if you are feeling inspired and not daunted by it, you at least have the right level of naïvity required to embark on a similar journey too, feel free to reach out.
Although it is not my intention to step on any toes, I realize I might have. So please respect that this story is (in part) dramatized and fictionalized to interest readers and provoke thoughtful debate. Hopefully, this note will help me stay clear of trouble ;) #courage 🙏
*>2O employees vs <20; source Dutch Digital Agencies 2018, by Conclusr.
** source IPSOS DDA 2018