Comment by doctor_eval | Hacker News Reader

Comment by doctor_eval | Hacker News Reader

Well in addition to the four values there are also 12 principles of the agile manifesto. And agile leaves plenty of room to deal with the issues mentioned.

The actual problem with agile, as I’ve seen first hand, is that teams adopt Scrum as if it’s some Agile Silver Bullet. If you just do what you’re told by the CSM, then projects will go better. This is especially true when there is a power imbalance, developer problems are swept under the carpet, and retros are discouraged or non existent.

It’s nonsense. Like all practices, there are all sorts of problems intrinsic to Scrum that need to be considered carefully and resolved.

How do you manage a large backlog?

How do you deal with unexpected complexity discovered at the very start of a sprint?

Where are the overall project goals documented - and how do we measure against them?

This is not to say that these problems can’t be dealt with in scrum. The Agile Manifesto leaves plenty of room for resolving them, but Scrum is being taught by many as the One True Way, and if you dare suggest changes or deficiencies in the process then you just Don’t Get It.

It’s the rigidity of these practices that has become the problem - the way I’ve seen Scrum implemented in several large projects is effectively waterfall with a scrum veneer.

When you’ve been shipping software for more than the length of your adult life, it gets tiresome to have someone with a dodgy certification in agile project management explain how to ship.

The reason this happens is because most people just want to know what to do next, and not have to fret over higher order problems which A) require deeper expertise and reflection to analyze and B) they may not have the agency and influence to improve anyway. This leaves the door open to the snake oil salesmen ("agile" consultants) who promise the One True Way™.

The reality is that well-tuned processes can reduce cognitive load in day-to-day work, freeing up mental cycles for higher level problems. But process also adds overhead and rigidity, so it needs to be tuned to the environment at hand and reevaluated regularly. This can't be done be done by a drive-by consultant or a detached manager, it requires boots on the ground context and applied expertise to relate the day-to-day reality to the highest order business goals. Anything short of that is MBAs and juniors clinging to an arbitrary process as justification for why they are delivering adequate, but not exceptional results.

Yes, I agree with everything you've written.

The problem is not processes like Scrum, it's the fact that many of the people who are in roles that are ostensibly responsible for "fret[ting] over higher order problems" actually don't care about that.

They get paid regardless of how productive everyone else is, and in my experience they get paid more if they implement "best practices"... which are practices designed by marketing teams to sell CSM courses.

The reason this happens is that management is secretly hoping that using a process will allow them to do get by with junior developers because the software complexity will be magically handled by "The Process"

I honestly don't blame them for trying to industrialise software production, I blame the engineers which is probably the only white collar profession that don't care about being in control of their own field narrative

This was readily apparent at my last shop when we had a range of junior (months out of college) and seniors (20+ years experience), and the expectation was simply that seniors were to clear more tickets/points per sprint.

We didn't allocate more architectural tasks to seniors, or pair them with juniors, or give them long running slices of work across sprints.. we just were like "more points please".

We ended up with under-engaged seniors all leaving, and juniors being given tasks they couldn't accomplish.

This has been a very underappreciated point in all companies I've worked for so far. The difference between an good programmer and a bad one is not (just) that the good one is faster, it's that they can solve problems that the bad one cannot solve at all.

The terms "junior", "senior", etc make it appear as if the latter is just an older version of the former, but the correlation between work experience and actual skill is far from 100% in my experience.

I use senior here also to point out - we had a team composed of people who had literally built a similar/same system elsewhere, and kids who are working for a living for the first time in their lives for a few weeks.

The idea that everyone gets a vote on story points & planning meetings in a conference room for hours&hours, while democratic, is counterproductive.

Further, as it turns out, the dev who has done the thing 2-3 times before knows all the mistakes not to make, and move onto make new & unique mistakes (joking, sometimes) whereas the junior gets to make all the mistakes all over again.

The senior is always going to give a higher effort estimate, but will generally be able to accomplish the task within that estimate more often.

A junior has no ideas what they don't know, and can often be off by orders of magnitude on their estimates. Usually because they consider only what is required for the "happy path" of the code to work as expected when used as expected, with no bad data/etc. Further they will include the time it takes them to get the first cut of the code working on their box, undocumented, uncommented, not in git, not tested, and not ready for release.

programming computers is a blue collar job. like a machinist or a welder. probably half of the work is fixing defects.

I know machinists and welders. Some of them just want a blueprint and will make what you want to that spec. Some of them want to be told "make this part fit on this other part", and they get to make up the bracket that fits. There is a place for both. One is basic and easy to automate - but often it turns out the costs of setting up automation is higher than the cost of paying someone to do the production run. The other is hands on engineering and needs some engineering knowledge.

Can you put programmers in a production line and expect quasi linear improvements?

No.

Because programmer jobs have a knowledge and creativity bottleneck, that is the hard part to scale, and require workers that have autonomy, can take initiative, and can put together a solution from known part in ways that create solutions for one off problems.

Metaphorically speaking they are not tightening the same bolt type over and over again to the same spec every time. Software is not manufactured, it's largely artisanal.

I think those defects often come about because the rest of the process emphasises schedule over quality. It’s a false economy, but many businesses treat quality as a cost rather than a benefit.

It is again one of the problems with scrum. There is pressure to complete a feature in a given sprint - and a sense of failure if you don’t.

Yeah, that's another thing... Because good developers are rare, expensive, and risky, corporations think they can get the equivalent work output of one good developer by lashing together several average developers the way you can get effectively one large reliable disk by RAIDing together several smaller, less reliable ones. This in and of itself is a strong motivator for how agile is done in corpo shops.

Of course, the fact that programmers don't actually work that way is something these corporations' management didn't get the memo on...

It's important to keep one thing in mind: Agile gets corporate buy-in inasmuch as it promises fine-grained executive observability and control over the software development process.

Period.

From a business perspective, Agile means some suits can look at a dashboard and see, with a granularity of one sprint at the coarsest, whether the project is proceeding on schedule, who completed what, which individuals and teams are ahead and which are stragglers. Information they need in order to make budget, risk, and resource (read: hiring and especially firing) decisions. That's how the consultants pitched it because that's what executives want to hear. They read about Agile in CIO magazine, its promise of quick turnaround times, and its need for communication between the developers and business experts, and their takeaway is that it's an efficient micromanagement strategy, a panopticon that will help derisk persnickety programmers by having them under constant observation and forcing them to provide constant feedback.

I don't doubt that you've experienced this, but frankly it sounds like amateur hour. At any significant scale, with competent leadership, executives will not have bandwidth to review sprint boards, and are actually looking for the opposite: reliable coarse-grained control. Of course, this requires a lot of trust, which also depends on a critical mass of competence up and down the chain. There may be times when subordinates are getting things wrong, and leaders have to deep dive to understand and correct things (particularly when competence is lacking in the middle management layers), but that is necessarily the exception not the rule.

Unfortunately even in healthy orgs where leadership concerns itself with results and appropriately delegates process and execution to experts that understand how the sausage is made, you still find a lot of lower level managers or even ICs who embrace the ceremony and rote process of Agile as a substitute for really reflecting on the quality of the team's output at a higher level and over longer spans of time.

Agree whole hearted with you but sadly amateur hour is all too common among supposedly senior execs.

In many companies it seems that people get promoted due to political skill rather than management skill. And micromanagers often appear competent because they can report on exactly why a project failed… leaving out the bit that they strangled it to death while nobody was looking.

Not that I’m bitter or anything.

You don't have time to review every HTTP request as it happens, but if something goes wrong you can examine all of those HTTP requests to find out what. Similarly, IT security at many institutions, including those that handle classified information, seem more concerned with ensuring the culprit can be discovered when a leak happens than with making the information systems more leak-resistant.

It's enough for the executives that the information is gathered and the audit trail established. Honestly, getting an auditable log of the developers' thought process is such a wet dream for management at software shops that companies will use any excuse to become a dystopian hellscape in pursuit of it. One such company used the following rubric: Compliance with the Sarbanes-Oxley act requires full auditability of anything that may affect the company's stock price, including the software's source code and any changes made thereto. Therefore, all developers must make a log in the bug tracker of what they're doing every 15 minutes to ensure an audit trail of developer activity.

Agile just happens to be the excuse that gained traction, because it's easy to dress up as something that's good for developers and it's not as ridiculously onerous as the above.

The backlog helps solve problems above my team not for my team. I tick tok between sprint planning and kickoffs with developers. My superiors need to prioritize and literally rank the stuff they need done. Otherwise everything is a priority and nothing gets done.

Well, as the Manifesto says, "Business people and developers must work together daily throughout the project."

But Scrum's approach to this is overly simplistic (product owners?), backlog reprioritisation is not part of Scrum, and in any case you really ought to have some control over priorities because doing certain stories in the wrong order will reduce productivity.

The problem that I'm pointing out is that Scrum has become synonymous with Agile in many quarters, and yet it is far from a complete solution to software project management. It's not that Scrum is no good, it's that it's not enough (or, in some cases, too much).

When I've been forced to use some BigCo's rigid version of "Scrum", it's always been a nightmare. Of course it was, because rigid is the opposite of agile.

Reply on news.ycombinator.com