Read on Twitter
Anybody who understands computer programming well enough to connect today's technical decisions with tomorrow's productivity *and* is comfortable in a management role can make "agile" work.
Very few devs ever manage to check both of those boxes in the span of a single career.
Very few devs ever manage to check both of those boxes in the span of a single career.
I have a few guesses for why this is the case:
1. Many programmers are autodidacts who miss obvious things because they're convinced they already know it all.
2. Declines in productivity always precipitate drops in morale, so devs move jobs before learning what worked/didn't
1. Many programmers are autodidacts who miss obvious things because they're convinced they already know it all.
2. Declines in productivity always precipitate drops in morale, so devs move jobs before learning what worked/didn't
3. Software development is generally learned by flooding the brain with terminology and sorting it all out later. This means subtle things like "software design" get learned all wrong, and devs are really good at assembling convincing arguments out of terms they barely understand
4. Devs treat code improvement from the standpoint of aesthetics, rather than tuning their sense of aesthetics towards what is most beneficial for productivity.
5. Devs get the dopamine hit they're looking for when their peers see that they've "gotten it working."
5. Devs get the dopamine hit they're looking for when their peers see that they've "gotten it working."
I could actually go on all day.
There are tons of systemic reasons why software development projects are dysfunctional.
Our projects keep failing because many of us take the parts of the job we like the most, and ignore the parts we don't, and nobody holds us to any standard.
There are tons of systemic reasons why software development projects are dysfunctional.
Our projects keep failing because many of us take the parts of the job we like the most, and ignore the parts we don't, and nobody holds us to any standard.
And I didn't even get in to the second part, which is willingness to manage.
If you want to manage a successful team, you've got to be prepared to hold people accountable. You *have* to take the risk of being disliked. No way around it.
If you want to manage a successful team, you've got to be prepared to hold people accountable. You *have* to take the risk of being disliked. No way around it.
Ultimately, the programming world seems like it prefers to avoid gaining a working understanding of the relationship between technical decisions and their inevitable outcomes, as well as ensure mgmt stays completely hands-off.
Any methodology will fail under these circumstances.
Any methodology will fail under these circumstances.
These two problems are very related
You cannot manage others without being able to see the connection between their mistakes and the consequences.
You cannot develop that understanding without consistent and deep self examination of your own work.
We have (almost) no managers.
You cannot manage others without being able to see the connection between their mistakes and the consequences.
You cannot develop that understanding without consistent and deep self examination of your own work.
We have (almost) no managers.
IME getting even something as crude and mundane as Scrum to "work" is fairly straightforward. Yet most organizations can't even do Scrum.
That doesn't mean Scrum "sucks" (although I'm really, *really* not a fan). It means *we* often suck so much that *we* can't even do Scrum.
That doesn't mean Scrum "sucks" (although I'm really, *really* not a fan). It means *we* often suck so much that *we* can't even do Scrum.
Phew, speaking of self examination, that's a lot of steam to let out on a Thursday afternoon.
Y'all have a good one...
Y'all have a good one...
