
Why I No Longer Want to Write Software for Companies That I Don't Own - externalreality
I&#x27;ll start by saying &quot;Agile Project Management Is Farce and does more harm than good&quot;. I&#x27;ve been researching tech turnover for a bit now, with a focus on programmer turnover, and with no reservations I can say that so-called Agile project management is a leading cause.<p>The goal of Agile project management is to make software development a more customer-centric and more iterative. This is a noble goal. Agile however, whether intentionally or unintentionally, has had a secondary effect of robbing developers of job satisfaction.<p>Here let me give you an example. About 10 years ago I worked with somewhat of an influential in the Ruby community. We both worked at an &quot;Agile&quot; software consultancy. After finishing a task on our project work board I remember watching as that developer went back to claim the task the followed logically from what he just finished. He was shocked when he saw that the task&#x27;s card has been claimed by another. He then said, right there in the office, quite loudly and openly &quot;I am not getting the satisfaction of completing a thing when working like this.&quot;<p>So Agile robs developers of sense of satisfaction of ownership and completion. Well if the developer is being robbed of this satisfaction then to whom is this satisfaction being transferred? Well, project managers. Who get rewarded for the &quot;velocity&quot; of the team, which is more of a product of the hard work and less of a product of task management.<p>So developers have three things making them want out:<p>1) No ownership satisfaction
2) No completion satisfaction
3) Someone else taking credit for their work<p>Ok, this are not the only reasons for developer turn over but this is a big one. There are others like toxic environments, Title VII discrimination, and so on.<p>It can be denied that 1.5 - 2.0 year developer turnover at tech companies is pretty woeful. We are dropping the ball somewhere and its hurting business bottom lines and developer careers.
======
SamWhited
I completely agree; it also has the effect of making software worse, as far as
I can tell. At the last few mid-to-large sized tech companies I've worked for
I've watched project and engineering managers push hard for more velocity
trying to get their bonus. Eventually they start telling people to take
shortcuts, or rewarding the developer who gets things done faster but, as an
example, doesn't write any tests. They then get mad at the other devs who
won't approve their patches during code review or end up spending their time
fixing the bugs in prod created by the developer being rewarded for "moving
fast". The pressure on the managers trickles down and the software ends up
being broken.

~~~
im_down_w_otp
The problem I witness when the general goal laid out is improving "velocity"
tends to be a fundamental misunderstanding of what velocity is.

Namely, velocity is speed plus a direction, and most of the activities that
would normally help codify a sane and deliberate direction (i.e. rigorous
requirements, rigorous design, rigorous validation, etc.) are all primed to be
sacrificed at the Agile altar. What you end up with is just "speed" as a
priority.

When organizations have KPIs & OKRs which set "velocity" as a prime directive
what that usually means is just "speed". As long as your development cycles
are shorter and shorter, then you're rewarded. In these kinds of organizations
the incentives align with flailing around spastically, so long as you're doing
it 1x a month, 10x a month, then 100x a month. Taking the time to be exactly
right 1x a quarter, and then building on that, isn't seen as desirable.

As one would expect, there aren't an enormous number of people who are
actually satisfied by doing random crap for a random cause as fast as
possible. In fact, that's what machines are for, not people.

------
ngngngng
I will not work at Agile/Scrum shops for similar reasons. Although my primary
reason is different. Estimations break the whole process. Most of engineering
is discovery work and discovery work can't be estimated, leading devs to
estimate 10 times what tasks actually take so that they don't get in trouble
for not finishing tasks on time.

I work for a smaller dev team currently and I take a project and finish it A
to Z. It is extremely satisfying to have complete individual ownership over a
task and we've achieved greater development velocity than I ever thought
possible.

~~~
cyphar
And the follow-up problem is that most Agile proponents say that "estimations
aren't to be taken as timelines". But that doesn't address the fundamental
issue that management always uses the engineering estimations as a method of
managing their timelines.

Not to mention that "velocity" and burn down charts actually reinforce the
idea that estimations _are_ ways of tracking how much work will get done in
Agile. Otherwise, tracking those metrics would be completely pointless.

------
cassianoleal
I have been working in some form of agile methodology or another for years and
wouldn't have it any other way.

It sounds like you've been working: \- with toxic people; or \- in toxic
organisations; or \- in immature agile organisations

If your ways of working are taking away your job satisfaction, you definitely
need to raise that up with the team you work in (like in a standup, retro or
just during the day). If it doesn't get addressed because the team disagrees,
you're in the wrong team. If it doesn't happen because management disagrees,
you're in the wrong team.

When I say you're in the wrong team, I don't necessary mean you're wrong or
the team is wrong - only that you two are not a good fit for each other.

------
HeyZuess
> He was shocked when he saw that the task's card has been claimed by another.

If this is project management, then where is the planning ? This really has
nothing to do with Agile, it has to do with planning which is not absent from
Agile.

> "I am not getting the satisfaction of completing a thing when working like
> this."

This is a people issue, it's very attitude based. Oh someone took my ticket,
my work life is horrible. How about 1) talk to the person who took it, 2) talk
to someone and explain the reason this should be done a different way
(communication something agile highly promotes), 3) go with the flow and move
onto something else. Don't be a snowflake.

> 1) No ownership satisfaction 2) No completion satisfaction

I work in a small agile house, and I have much more ownership and involvement
in project completion that I have had anywhere else. In fact that is a premise
of such methodologies as scrum which time box, and reduce the scope and
objectives to things like sprints.

> 3) Someone else taking credit for their work

I am not sure about this one, but this is consistent of many work
environments. Heck I've worked in offices where some egos would take credit
for anything.

~~~
haydn3
The fact people _can_ take tickets and you have to _fight and have an argument
about it_ really shows that there's a discourse inevitable in systems like
Agile.

Who gets the 'tickets', why are 'tickets' always ruling people, when will
'tickets' be more like working for your own company?

The fact is the tickets themselves are acting like a virtual currency of which
only one person gets, exclusively.

If more than one person could work on a ticket this would solve the problem,
but the fact that people are locked out and it's exclusive makes them an
argumentative point and causes greed/habits to form.

Fix the tickets, not the people. All the credit and satisfaction comes from
this one point.

~~~
UK-AL
Fighting over a ticket isn't an agile issue. In fact this the opposite of
agile.

The developer at standup/meeting/story kickoff should of explained the
situation and asked to work on the ticket himself or pair on it. Problem
solved.

------
jay_kyburz
If you have some ticket system where programmers can just take work, your team
is breaking the first rule of Agile.

    
    
        Individuals and interactions over processes and tools.
    

A ticket system is a process. Individuals and interactions come first.
Programmers talking to one another and being happy is more important than your
task database in agile.

~~~
dsirola
Why does it break the first rule of agile software development?

 _" That is, while there is value in the items on the right, we value the
items on the left more."_

------
codesushi42
What is agile development? Is it anything more than a buzzword?

I have worked in several environments that embraced "agile". And they were all
different, for the most part.

The only things they had in common was bad management and negligence of tech
debt.

~~~
jay_kyburz
The Agile Manifesto

    
    
        Individuals and interactions over processes and tools
        Working software over comprehensive documentation
        Customer collaboration over contract negotiation
        Responding to change over following a plan
    

There are many variations built on top of these, but without these it's not
Agile.

[https://agilemanifesto.org/](https://agilemanifesto.org/)

None of these things makes management easier, you still need a good manager to
make a project work.

Nothing in the manifesto says you should ignore technical debt, that is simply
a choice your manager has decided to make. Its not the fault of Agile.

------
TheChaplain
I disagree. To me, Agile is a successful way to work, and I prefer it.

Completing a task is where I get my satisfaction, even if it is a part of a
larger piece. Also when I see the client try out the new functionality and
giving me feedback (positive or negative) on a completed task.

Another good point with agile is that I can pick any task I see fit and have
the capabilities to complete. I'm not stuck with a certain part forever, that
is awesome and I love it because I get to learn new things.

In your anecdote, it seems to me that the person complaining is not really
interested in the agile concept and prefers to work the old-fashioned way.
That is fine, but unless the workplace have projects that adhere to the
waterfall-model that he could work on, maybe he's just in the wrong place?

------
KrumpetPirate
I joined a new project recently after working in a mostly relaxed agile
environment for most of my career. I would describe my current project as
"Agile at all costs". No testing, no requirements, just go. Just do. I have to
say it's created an environment where almost every developer is super unhappy
and ultimately producing a sub-par product.

I want to go back to just doing good work. Obviously focusing on what the
customer needs and wants, but where the engineers have a choice to do
something the right way instead of just the fast way.

~~~
jay_kyburz
Whoever said agile means no testing and no requirements is doing it wrong.

------
mr-ron
If the engineer is only getting satisfaction from claiming a closed ticket,
and then not getting tickets claimed when they owned the work, then the team
is putting values and metrics in the wrong places.

Either have multiple people claim a ticket, or change the definition of
success from an individual releasing a ticket, to a team releasing a
successful ticket.

Agile done properly should reward success on the team level. Tickets are
rarely one-person affairs. If reward is happening on the individual level, one
per ticket, then the usage of Agile is incorrect.

------
nscalf
So while I totally agree with this, I have some questions:

First off, do you think Agile is better than Waterfall? I personally think
that it delivers a product faster, but I'm not sure if it actually has a macro
improvement on the job process. I think waterfall probably addresses your
developer-centric issue of satisfaction better than Agile does. I think we may
have thrown away too much with the anti-waterfall hatred our field has
adopted.

Second, what alternative do you propose? I think Agile is a problem, and
ultimately a pretty bad process for organizing. The overhead is so expensive.
The most effective and efficient my team has ever been was when we just quit
Agile and wrote what we had going on up on the white board. And you know what?
I've seen this work better than Agile in a wide range of settings. "Self
organizing" really seems to be the key, but regardless of the self-
proclamations that Agile is self organizing, it really seems to shoot itself
in the foot with extra mandatory process.

Finally, it seems like all of the good solutions don't scale. Do you think
this is a problem of trying to scale problem solving? I don't think I accept
the argument that this is just the cost of working at larger scale, but I
haven't thought of a good way to keep a team organized and still get work done
without an extreme amount of organization and process (Agile) or a really
involved team lead/product owner---who will slow everyone down by needing a
lot of touch points.

~~~
externalreality
The first problem with agile is that false dichotomy - "It's either agile or
waterfall". Sorry but that dichotomy doesn't exist. Waterfall vs Agile is just
a good-bad binary. Surely you want to iterate quickly and stay in constant
contact with customers, if that is all agile is then I am all in. However, I
can't subscribe to robbing developers of ownership of a domain. I would even
do microservice arch if it meant dividing things up into domains and assigning
developers microservices that they own. I want to keep developers and giving
them responsibility and ownership is a good way to do it.

Its funny because, in Agile you hear "You don't want one developer leaving
with all the knowledge" now instead we have all the developers leaving with
all the knowledge.

~~~
jay_kyburz
Nothing in the Agile Manifesto says anything about robbing developers of
ownership of a domain. The first line of the manifesto is "Individuals and
interactions over processes and tools", which suggested to me that individual
work satisfaction is right there at the top.

Whoever is running your team is doing it wrong.

~~~
externalreality
I wouldn't hang on every word of the agile manifesto. For example you don't
have to google too much before you find people having debates over unit
testing vs acceptance testing in the name of being "Agile" not giving to much
attention to the "over processes and tools" part of the manifesto.

~~~
jay_kyburz
If we are going to critique Agile I think we should first agree what Agile is.
Agile is the manifesto, not what some random dudes on the internet say it is.

~~~
externalreality
Agile is not the manifesto, I has really never been. Agile does not have a
real definition.

------
oceanghost
The problem with agile (in my mind) is it codifies some very bad practices.

One, working your developers to death. In every agile environment I've worked
in, nobody ever took a day or two to plan, do retrospectives after a sprint.
It was always, always, "Get back to work." I had one job that did weekly
sprints every week.

Two, it transfers the risk of bad management from management to the team.
"Look! Anything can be built by planning in two-week stretches! We can change
direction anytime!"

------
sparrish
Turnover, IMHO, is due to market demand, not satisfaction issues.

After 1.5 - 2.0 years, a dev has more skills that are in demand and will
gladly jump ship for a better position and/or pay elsewhere.

~~~
greenyoda
To be more precise, the problem is that employees' raises are not keeping up
with the job market, so the only way to get what you're worth is to change
jobs frequently.

If companies would make more of an effort to keep their employees happy
(financially, work satisfaction, etc.), they'd spend much less time recruiting
and training new employees, and productivity and profitability would probably
increase.

Hiring a new employee at the same level of competence is going to cost at
least as much as retaining an existing employee, so I wonder why companies get
into this cycle of constant turnover. The only way they'd save money is by
constantly hiring inexperienced employees to replace the slightly more
experienced ones who left, but what they'd gain in cost would be quickly
eroded by lower productivity, loss of collective knowledge of the product,
etc.

~~~
externalreality
Both jumping ship for raises and other things are also true according to
multiple sources. Job satisfaction is another leading cause. The tech industry
has to fix the issue of turnover, its costing too much money and careers are
being diluted.

------
macando
This just came out:

"WEB-BOOK LAUNCH: The deepest dive into our unique way of working. No post-
its, no backlogs, no sprints, no stand-ups, no velocity tracking, no agile, no
scrum, no roadmaps, none of that. We’ve gone a different way, and now you can
too. Read up, Shape Up:"

[https://basecamp.com/shapeup](https://basecamp.com/shapeup)

------
deedubaya
Developers are highly paid because their knowledge is highly leveraged.
Someone else is benefiting from your application of knowledge by an order of
magnitude of what they're paying you. Why be the cow when you could be the
dairyman?

~~~
phonebanshee
Because dairy farms go under all the time. These days, the well fed happy cows
just stroll over to the next field, where there are massages on tap if the
stress of eating grass in the sunshine gets to be too much.

To put that in non-cow terms, the rewards of just getting straightforward
compensation these days are really good. So good it's not obvious that
starting your own thing is worth it monetarily.

~~~
deedubaya
Of course there is risk in starting your own venture. It’s not a guarantee of
success, but the upside is exponentially greater.

Chasing (relative) peanuts is still a better call for most.

~~~
badpun
> but the upside is exponentially greater.

See, I don't think most people care if they are millionaires or billionaires.
And you can become a millionaire on a software dev salary.

------
PdV
IMHO - agile seems to be easy to learn but hard to master. I think we have
tons of advanced beginners engaged in a global cargo cult.

Its such wide-spread phenomenon, such that we have an "even more agile" dark
manifesto, pointing out the pitfalls in which the agile has fallen (eg.
processes & tools) -
[http://darkagilemanifesto.org/](http://darkagilemanifesto.org/) ...and the
golden [http://programming-motherfucker.com/](http://programming-
motherfucker.com/) that urges us to just cut out the cancer.

------
vicnov
1\. Would you work for a company that doesn't use agile? 2\. Will you hire
other engineers? 3\. How will you address those issues in your company? 4\.
Are there companies that successfully addresses these issues?

------
sethammons
Satisfaction on our team is by releasing code. The book keeping in ancillary.
We operate as a team, and one person (or a pair) might write it, another tests
it, and anyone might deploy it.

As for capital A Agile leading to turn over, I'd be interested in seeing the
data. Most of what I've read says that employees leave managers.

------
thecupisblue
Agile, Waterfall, Shmagile Shmoterfall I say.

All these "practices" are just ideas like "hey work in small sprints and
deliver on the go" that have been shaped into ideologies and standards we "all
need to work within" by the law of averages. If you have a 100 average
developers working for your average corp developing software, they need a
structure - oh look, here's agile - let's pay money to people to teach us how
to agile (??!? i'm still confused by this, like are people seriously that
dumb?) then force the strict set of guidelines and rules onto everything
because thinking outside of the box or working outside the guidelines confuses
the averages and introduces chaos. Keeping team small, agile and keeping
agile/waterfall/whatever-silver-bullet bureaucracy out of their way is the
solution.

We are dropping the ball because we focus on using "standard processes" for
the sake of using "standard processes". The stricter you need to implement the
rules and guidelines, the larger the chance something smells in your companies
culture.

------
nerdbaggy
Those are some of the reasons why I don’t think I would like developing at a
large company. Where I work it’s just me and 2 other developers. I don’t own
the company but it’s sure satisfying

------
skybrian
You tell a story about how one developer at one company was disappointed, but
it doesn't follow that other people will feel the same way.

------
jim_and_derrick
I've had some good 'agile' experiences and some bad. We havent always done
agile "to a T", we usually shape and mold it to work for us. However some
companies it is very apparent how shit this thing is. We do our company wide
sprint review thing with each squad (yeah we copied spotify squad thing). When
a PM gets up and says "our squad complete 12/12 points" everyone goes fricking
nuts like it's the best thing ever. What did the squad accomplish? They added
some images on a page in our app...

I guess overall what i've learned, and this probably applies to a lot of
things in life not just software. "Important" (C level, managers etc) act just
like my 8 month old daughter. They see things that are new and shiny and they
want it, badly. Tech companies see that other tech companies do AGILE, JIRA,
all this shit. Those manager types then decide we need to do this ourselves.
So you are forced to implement some managerial system that nobody understands.
It's all crap i tell ya.

------
davismwfl
While I agree overall that Agile is not what it is sold as by many, I am
troubled some by the way you presented your argument, but not your argument
itself I don't think.

As a CTO/Executive, I read from what you wrote: I have a few unhappy engineers
but my project is moving faster and more successful. So I'd say ok, I'll work
on managing the edge cases.

As an engineer who's worked in waterfall cycles and almost every iterative
cycle you can name, and have designed a few; I think what you meant to
highlight was that project managers are claiming work as being more complete
then in reality (higher velocity) so they get a pat on the back in the short
term but wind up with longer term product problems like maintainability and
accountability. Ironically, the two things that engineers like and that help
bring job satisfaction.

To that I would agree, there has to be a process that is designed around the
cadence of the business and the team. And the process must not be fixed or
rigid and grow and change as the team does. This is how you keep people around
longer. And PM's are there to facilitate not dictate or take credit away from
engineers. But PMs also deserve credit where credit is due and shouldn't be
looked upon as the enemy in the engineering cycle, which has always kinda
existed but seems to be getting worse at many companies.

