by externalreality on 7/12/19, 3:06 AM with 47 comments
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.
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 "Agile" 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's card has been claimed by another. He then said, right there in the office, quite loudly and openly "I am not getting the satisfaction of completing a thing when working like this."
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 "velocity" of the team, which is more of a product of the hard work and less of a product of task management.
So developers have three things making them want out:
1) No ownership satisfaction 2) No completion satisfaction 3) Someone else taking credit for their work
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.
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.
by SamWhited on 7/12/19, 3:20 AM
by ngngngng on 7/12/19, 3:28 AM
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.
by cassianoleal on 7/12/19, 9:29 AM
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.
by HeyZuess on 7/12/19, 4:44 AM
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.
by jay_kyburz on 7/12/19, 6:36 AM
Individuals and interactions over processes and tools.
by KrumpetPirate on 7/12/19, 3:31 AM
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.
by TheChaplain on 7/12/19, 7:00 AM
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?
by mr-ron on 7/12/19, 3:30 AM
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.
by nscalf on 7/12/19, 3:43 AM
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.
by sparrish on 7/12/19, 3:30 AM
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.
by oceanghost on 7/12/19, 1:59 PM
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!"
by macando on 7/12/19, 8:18 AM
"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:"
by deedubaya on 7/12/19, 3:38 AM
by PdV on 7/12/19, 9:28 AM
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/ ...and the golden http://programming-motherfucker.com/ that urges us to just cut out the cancer.
by vicnov on 7/12/19, 3:23 AM
by sethammons on 7/12/19, 1:25 PM
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.
by thecupisblue on 7/12/19, 9:03 AM
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.
by nerdbaggy on 7/12/19, 3:23 AM
by skybrian on 7/12/19, 3:28 AM
by codesushi42 on 7/12/19, 3:25 AM
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.
by jim_and_derrick on 7/12/19, 3:30 AM
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.
by davismwfl on 7/12/19, 12:25 PM
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.