The sunk cost fallacy suggests that sometimes is better for you if you should just accept existing losses, accept you've already sunk those costs and won't get them back, and move on. I don't know what their contract looked like with the agency, but an 80% of a logo design sounds like a perfect deliverable that you can safely fire the existing team and take the 80% deliverable to a new designer, not start from scratch, and ask them to do a final polish step. I would have cut losses there, but of course it is much easier to armchair quarterback from hindsight and different perspectives than if you are in the middle of it fighting that gut feeling that you've already invested so much and can't "afford" to cut losses.
Those lottery phone scams out of Jamaica which target the elderly in the US are almost the exact same scam as what was described here.
Promise something, get them to send money, don’t deliver, tell them you need more time/more money. Keep repeating until the mark walks away.
They started work on and subsequently billed for something that was explicitly out of scope.
My guess is that the founder of the agency knew early on that he could push this client around to extract $.
An analogy here would be forcing the agency designers to completely delete any speculative redesign work, without any backups, to force them to focus on the logo, and send a strong signal that I don't care about the redesign, and won't be paying that work.
I think you're attributing malice to what was more than likely routine mismanagement.
I wouldn't call it mismanagement. Many agencies thrive despite regularly delivering these types of experiences. It's a conscious choice they can easily rationalize because of the money.
This agency turned a one off $7k job into $46k by smooth talking and scope creeping an actual developer. I'm sure they're absolutely killing it doing the same to non-technical folks.
TinyPilot is clearly successful and growing. Any smart agency would nurture that relationship, deliver a great product, and secure an ongoing relationship.
By contrast, there's a huge amount of reputational risk in allowing things to spiral. They've walked away with more today but imagine for a moment the damage that would have been done were they named in this article. It doesn't take much for a brand to turn toxic and things to implode.
There’s a big legal risk involved in doing so and no upside that I can see.
I would hope he could get some satisfaction in knowing that he might be able to stop them from taking advantage of clients in the future.
Management threw it out to the floor and the floor ran with it like every other job. Feedback went to management but the people doing the work didn't really understand that this client was not like their other projects.
I've been on the other side of this where one bigger client changed the game and we didn't adapt as we were used to things at a different scale. We didn't clean up the mess we inherited fast enough. We didn't put enough resources on the projects and we failed to live up to expectations. We were used to smaller tasks with more limited scope.
The same thing if you are going to a concert and lost your tickets, do you want to pay $200 to go to the concert (not taking into account that you've already lost $100, you could have lost that $100 on whatever) eg. you are paying 200, not 200+100.
Keeps me honest. And will keep me from working with architecture astronauts don’t really deliver anything but hot air and build ultra-extensible structures that are actually impossible to extend beyond the fantasy world of their maker. Or the equivalent for designers.
Agile is not a guarantee of deliverables you care about. There is a lot of useless stuff you can deliver.
That's pretty much untrue; had this project been a waterfall project then:
a) The devs would not have gotten paid until they hit particular milestones,
b) The deliverables would have been scoped upfront,
c) The agency would have eaten the cost of developing useless things, not the customer.
Because this was obviously an agile/Agile project:
a) The payment milestones were not specified upfront,
b) The devliverables remained unscoped until feedback was needed (which was well into the development phase),
c) The client eats the cost of developers time, whether or not milestones are hit.
They probably said the word "agile" a lot and then continued doing something else, that seems to be the usual pattern.
> Agile is not a guarantee of deliverables you care about. There is a lot of useless stuff you can deliver.
Which is why it's the product owner's responsibility to prioritise.
The company didn't seem to have issues prioritizing the authors tasks into no mans land. So they seem to have that part down great already. However I find the consistent two week deliveries early on a bit disturbing, in my experience two weeks is exactly one sprint and fixing deliverables to that time window means that you can't really do any agile planing with it, your team just has to accept that this work has to be done and can't give random work that seems to pop up every now and then the attention it deserves. To be really agile and allow your sprint planing to reflect that you shouldn't promise anything in time spans less than two months.
Probably not. Larger relatively successful design / marketing agencies are - based on my experience - poorly run, poorly managed, and poorly led. This gets exasperated by high turn-over (read: good people leave, dead weight stays behind).
Training, etc.? Not a priority. Revenue, it's all about revenue. They're "creatives", not business problem-solver types and presume mess and excessive friction are unavoidable.
Of course it would be much better if the agency were honest, but if for seven months the deliverables were only "promises", then it's definitely not agile...
The older I get, the more I come to understand that the problem with projects is people, not methodology. 30% of IT projects still fail, despite “agile” now being widespread.
The first value of the agile manifesto is “Individuals and interactions over processes and tools”. Unfortunately, most implementations throw this one out first.
The thing is that as far as I can tell, “success” is measured post-hoc, so all sorts of shenanigans might have taken place in order to determine that a project was “successful”. Having worked with my fair share of corporate project leaders, I’m quite certain that the actual number of failed projects would be much higher if measured by the original criteria used to justify the project in the first place.
If we look at the original requirements every single project is a failure. If we look at the strategic goals and keep track of all trade offs maybe 30% is a fair guesstimate.
That's a very optimistic statistic, unless "fail" is defined to be something other than "the opposite of success".
IOW, a fail is any project that goes over time, over budget or delivers under scope.
If you're defining success as "well, we delivered eventually, and we delivered 80% of the requirements, and it only went over budget by 20%", then, sure, only 30% of IT projects "fail".
Not only should we be asking if a project has achieved its original goals once it’s finished, we should be continually assessing progress against those goals throughout the life of the project - yet few projects I’ve worked on actually do this, even when I’ve explicitly requested it.
Most clients know exactly what their goal is ("To increase market recognition", "to increase conversion rate", etc). The scope creep can only happen in a requirements phase[1]. Once a client has signed off on exactly what will be delivered, and what the payments milestones are there's no wiggle room for the agency to continue experimenting.
If you're skipping the requirements phase because "agile"[1], then the work will be over budget, over time and under the scope.
There's very few projects that actually require the exploratory-driven process that agile uses. If you have one of those projects then farming the management of it out to an agency is exactly the wrong thing to do.
[1] There may be multiple requirements phases. For example a large "need to revamp our website" project can be split into multiple serial projects, each with their own requirements phase.
[2] I.e. We'll figure out what is acceptable to the client with constant feedback.
It's a very abstract term. To put in simpler terms you will always have some outcome mismatch and generally your goal should be to reduce it. But if you do not have outcome mismatch, then you should push the line so that you can look ahead and understand future areas for improvement. Or you can just stay content if "market" is not chasing you.
But you are 100% right about the problem being people. The problems I see with agile are always because people try to find escape hatches in the process. Designers want to prepare every single detail before developers start working and hate iterating because fear of the "original vision" being a mistake, product owners don't want partial stuff in the beta channel so everything has to be in its final state, product owners don't know or don't want to reduce scope so developers end up with impossible sprints, developers want a perfect definition finished before starting work, so zero chance to iterate...
I also agree with people throwing out individual/interactions and picking a heavy-handed process instead :(
If you trust your developers (whether in-house or contractors) to do the job you can pretty much let them manage themselves with whatever kanban-ish system that works for them. If you don't, you have a ready methodology that gives you meetings upon meetings and two week deliverables and every little thing broken down to the smallest unit under the guise of "empowerment".
And you probably know that there's a BIG portion of developers who aren't as self-organized or disciplined. You mentioned the shiny things distractions, I think that was a factor in the original post. The other being mismanagement on the agency's side, where they allowed their designers to go out of scope. And I'm not even convinced it's mismanagement, because they turned a $7K project into a $46K project, a 6.5x increase in their revenue off of some small side project.
And it is actually more useful when things are flipped, and the team doesn't really trust the client/customer/manager. Which is often what happens more frequently.
But you're totally right that Scrum can get kinda heavy on the meetings side. Which tends to be the rule, not the exception. The only times I had this exception it was when we had a technical person working on the requirements, though. No designer or product owner making nebulous Jira tickets.
Sounds like that's exactly what he got, tbh.
They typically are employed by businesses who are looking for a very specific result: a good website that works well.
Their team wasn't setup to, and didn't know how to just deliver a simple logo.
The correct answer would have been for WebAgency's CEO to say, "We'd love to work with you, but we're not really setup for this type of project. If you'd like to have us take on your whole website, here's what that would look like. Otherwise, I don't think we're a good fit."
That said, clients can also be problematic; I recall one where the client paid a fixed amount per two-week sprint, but then really started to stretch out how much work was done within that sprint by basically not signing off on tasks and reporting new features to be added as bugs. It's another case I think of a party not being firm enough about scope.