Hacker News Reader

Comment by Dave3of5 | Hacker News Reader

Just as a note to the author what you saw the engineers do was SCRUM not agile. Most argue that SCRUM is agile I'm not 100% sure of that.

SCRUM was a framework that one of the original agile proponents built to make money off developers. It gained popularity not from engineers but from project managers and the like which meant suddenly every project started to use SCRUM. The main reason was that they sold a course which gave a certificate and if there something that a project manager like more than micromanaging it's certification.

View on HN

Many developers embraced scrum when it first appeared. It was a lot more developer focused than the pseudo waterfall type practices that existed previously.

Can't code until the architect has written the spec. The deadline estimated from a Gantt chart by the PM. No feedback from stakeholders during development or the ability to alter requirements as they become better understood. So usually delivering code late that doesn't actually meet the customer's needs.

Scrum was better.

I hear it is now horribly abused (I'm out of the game now) and that's a shame.

EDIT: I saw the most resistance to Scrum from project managers themselves, who did not understand a world without Gantt charts, or changing requirements as you went along.

Waterfall is a mostly manufactured pejorative by proponents of new processes. In what form it did exist, its practices were far from ubiquitous and mostly limited to government or very large corporations. Scrum arrived to slay a mythical beast.

It's funny to me that one of the original descriptions of waterfall is actually something we might consider agile: http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970...

It augments the naive waterfall with continual testing and customer feedback among other things that might surprise you.

I agree waterfall did not really exist in most places which is why I called it pseudo waterfall.

But the plan, code, test cycle, largely fixed requirements and PMs running everything from a Gantt chart existed in many places to a large extent.

Yes. This bullshit you describe was real. I remember having managers in 1998 using Microsoft Project and HUGE plotters that were used for nothing but printing out massive Gantt charts. And, of course, having DAILY meeting when we were behind so that our manager could show with great accuracy how behind we were - and complain he needed more people to manage so he could build his fiefdom.

The author points to Microsoft as a typical example of corporate programming in the 1990s.

Yet Microsoft wasn't using a (pseudo)waterfall development model. Quoting Steve McConnell in "Rapid Development (1996) Page 271:

] In addition to providing explicit support for morale, Microsoft gladly trades other factors to keep morale high, sometimes trading theme in ways that would make other companies shudder (Zachary 1994). I've seen then trade methodological purity, programming discipline, control over the product specification, control over the schedule, management visibility -- almost anything to benefit morale.

As I've pointed out before, I've read about software development projects at Apple, Be, Commodore, Data General, id, Infocom, Microsoft, VisiCorp and others. None were using (pseudo)waterfall.

I therefore agree with bdefore that it seems to have been "far from ubiquitous and mostly limited to government or very large corporations", and that the era of waterfall was a mythical beast.

I guess it depends where you worked. I certainly don't claim it was ubiquitous, but I personally saw it at a start up and a small software house. Also government, for sure!

In the late 90s/early 00s I worked at two large tech companies that at the time were household names. Granted one no longer exists and neither are what that phrase would evoke today.

In neither case did we do waterfall as people describe it. If anything it was even less process than agile. Sure the gantt charts existed, and sure at a high level things had been drawn out. But in the boots on the ground teams things were a lot more ad hoc. The biggest difference I see from that experience today was that individual developers were handed larger pieces that'd take weeks or more, and had a lot more freedom of action.

Not sure I'd call it better or worse to common scrum setups, but likely a bit of both.

For me too in the 90s it was a lot more ad hoc, with a higher degree of trust in the developers.

I think many people found software quite mysterious. You had to let the wizards perform their strange magic ;)

I think what agile gives us over that world is better feedback cycles.

I saw it at a local council (serving ~300k people) & a small gas (as in methane delivery) company as well as at a very large telco and in government/defence. It may not have been ubiquitous but it was definitely everywhere I worked.

Yes, "Rapid Development" lists a dozen or more approaches, including iterative prototyping and (modified) waterfall, with pros and cons of each one.

My issue with the standard Agile story repeated here is the lack of any mention of pre-Agile approaches other than waterfall.

Take: "Rather than clearing the way for software developers to build, waterfall gummed up the works with binders of paperwork and endless meetings."

Why is there no mention of any other approach? We can easily point to the Macintosh project, which took 5 years (1979 to 1984). Yet, no waterfall there.

Or, take a closer look at: "Peter Varhol, a technology industry consultant, estimates that in the early 1990s, the average application took three years to develop, from idea to finished product." (That's shorter than the Macintosh project.)

What does that mean? Which industry? What kind of applications? Clearly a lot of "log cabin" PC applications are excluded from that list - just think of all the DB2 and VB applications people wrote in that era. And video games.

Waterfall also consists of those phases. One core idea of agile is instead of a big design up front to iterate those phases as fast as possible because often the requirements are not clear from the beginning and you have to see if your ideas bring value to the stakeholders. The problem is that not all tasks can be done in a short time and sometimes need more planning. Planning is often neglected in agile environments. In some environments you also know the requirements beforehand (because they stem from the law for instance), agile development does not work there.

I completely agree. In my early agile training, the instructor stated it was good for developing where requirements were unclear or responding to small feature requests quickly, due to the fast iterative approach with feedback.

He also said that agile was not a substitute for planning.

I guess those lessons weren't learned by everyone...

Yep, the design phase shouldn't be an exclusive OR between a large-scale design & small-scale designs with iteration. It should be both: plan the large-scale architecture, marking the bits which are unknown, then iteratively design & build to fill out the unknowns & build the rest of the design. It's a recursive process.

solve([problems]) 1. Define car(problems). 2. Plan a solution. 3. Implement the solution. 4. Test the solution. 5. Document the results. Add any problems discovered to the list. 6. solve(cdr(problems))

There was definitely the flavors you speak of. Companies suffered from individual pieces more than others and you rolled the dice when you changed jobs.

What I anecdotally perceive has changed in the last five years or so is that the no good lying tools that arose from Scrum's popularity have become compelling to upper layers and weaponized against engineering.

Burndown charts. Design documents. The bureaucracy that is JIRA (YAGNI IMO). These each chip away at autonomy.

Sounds painful. I remember I did have to field questions from management on why one teams velocity wasn't "as good" as another's. They seemed to think it was some kind of globally objective measure rather than something particular to each team and their estimations.

Your example has always been a common conversation. And a bit like The Neverending September, at some point the training became overwhelming. This misunderstanding about velocity has become prevalent, you could maybe say more common than its intention as a tool.

There was a time when software teams didn't meticulously ticket and estimate everything. Hard for some to fathom, but stuff got done if you worked with honorable craftsman. Just differently. #noestimates feels very long ago.

Sounds like you moved on wisely. Aberrations like these vary of course, but along the rise of large tech giants that demand alignment and are threatened by autonomy, it's become more de facto.

It's sad to see small teams take it as a given for how things are done. I genuinely think it deforms and delays the solutions they're trying to make for their customers.

Sadly, this constant push to measure and control all processes and tasks infects everything, not just development.

Enterprise software is appalling at imposing workflows on everything in sight, and they always have pretty graphs and reports for management.

I feel quite strongly that software should serve humans, rather than the other way around. These tools do not exist to help you get your job done, they make you its servant.

Imagine how much more productive we could be if we had tools designed to actually help us. Management could still get nice reports, but some manager might have to knock up a spreadsheet. I can dream...

Please dream out loud. :) What would those tools look like?

I can think of some qualities those tools would have. Ease of use, focused simplicity. Interactions should be voluntary, not enforced by a workflow system. Usage metrics shouldn't be exposed outside its users, giving them flexibility to use it however makes sense for them.

I suspect with your comments you've been out the game a while. Most devs that I interact with hate SCRUM. Your Gantt chart is still there btw it's just not shown to devs but product are still creating all that but overlaying SCRUM over it.

Your 6 month project now has to be finished every 2 weeks now working shipped bug free in 2 whole weeks. The scope has been reduced for sure but now everything you do has to be in 2-3days at tops.

Yep, I stopped developing professionally around 10 years ago. Even back then I heard rumbles of dissatisfaction with scrum, although it was a good experience for me in the places I worked.

We embraced the agility, gave a lot of autonomy to the developers and had good product owners. We used scrum, also a bit of kanban and mashed them up in whatever way worked for us.

The product owners shielded us from the business if they tried to interfere too much, and built trust with all the stakeholders that we were delivering. The sprint reviews were really popular events.

Scrum can work well, as can many other things. It's not so much the methodology itself that causes problems. It's when everyone misses what the actual point of Agile really is.

And I think the process lends itself to more changes as it focuses so much on the short term as opposed to forming a crystallized vision of the overall targets. This in turn hinders productivity.

Does this quote from the article:

> They were all working hard, that was clear, but there was a fatal flaw: no one really knew what the project was ultimately supposed to look like, or exactly what purpose it was supposed to serve.

sound like scrum though? No product owner, who would have a vision for what the product's purpose was or what it was supposed to eventually look like. No product backlog outlining a path to get to the vision. No sprint reviews with the product owner and stakeholders to inspect whether the product is on the right track. At least not that I saw in the article while quickly skimming through.

What she is describing is some techniques picked from some agile methodologies; but lacking the proper spirit of the game.

no true scotsperson?

Yep, pretty simple really. If it works then only it can be called agile. E.g. we sacrifice goat everytime story is complete and human when an epic is completed successfully. It has worked so well for us. So I am gonna call it Right™ way of doing agile.

I am happy with that so long as you : a) do not try and make other people kill goats, and b) do not insist on stopping the other team that likes to shave its hair after every show & tell because that works for them.

It's cool if some people prefer to shave their hair, while others say that this goats business is silly anyway and better be skipped; but then they shouldn't claim that they are the followers of Right(tm). It's only fair. Whereas you can hear people claim that they are doing scrum, or even develop a strong dislike to scrum without actually doing what's in the scrum guide.

Well b) is excellent point. Instead of stopping it should be promoted everywhere.

actually just wet myself a little bit when I read this.

This is agile: https://agilemanifesto.org/

If the result isn’t “working software” created with “customer collaboration”, while “responding to change”, then it’s not agile.

There are also twelve principles (https://agilemanifesto.org/principles.html). My favorite is: (7) Working software is the primary measure of progress.

Indeed, but in the industry, I've seen no company that embraced "agile" without embracing some predefined framework (scrum, kanban, xp) to "apply it".

I've yet to find a growing/grown company that still embrace chaos as a start to find and nurture their own agile working methods.

It's very much like how companies implement "innovation strategies", being oblivious to the fact that innovation starts with rebellion against the very structure in which it appears.

Uncertainty is not something people embrace easily.

Honestly SCRUM is an abomination, a tentative to adapt a mass-production technique (Toyoda Kanban for mechanical industry of the '900) to R&D/intellectual activities.

The abomination is refusing to understand that creative activities can't be done well in constrained setups, while mass-production work very well with a certain rigidity. Toyoda NEVER tried to make Toyota R&D a kanban activity, just the factory part was kanban. Modern neoliberal managers have decided that the same technique they like can scale, while it can't. As a result we see a kind of quality-rise in listing terms, while the final outcome is crapwares monsters no one can understand not master, witch a big batch of side techniques to keep them artificially alive to a certain extent.

Classic sw development have flaws, Agile manifesto was a tentative to mitigate them, but have not much to do with SCRUM nor with what we call agile today.

I agree that SCRUM is a framework built on top of agile, but I think it's a valuable handhold to start off with, because agile itself is too free and open to interpretation. I don't like the huge agile training, certification and consultancy market though, even though I've met some really well-versed project management people that operate in that market.

One thing I've noticed is POs are almost always from the Product Management side. It makes sense, they both have Product in their name. I think this is part of the problem and that at the scrum team level the PO should be an engineer.

The issue is that the granularity of a system that should have product management is often larger than the granularity of a single scrum team. You can have several teams working together on a cohesive product. Yet often each team will have it's own product manager acting as PO. This leads to a lot of unnecessary horse trading and suboptimal results.

Scrum is collectivised micromanagement.

It feels like they could have just called Agile "The True Scotsman" to short circuit both sides of this endless repetitive and predictable argument.

Why do you think that is?

I think the Agile Manifesto is an exercise in subversively asking management for a very reasonable-sounding thing that is completely impossible: autonomy. Every line poses a threat to a well-known corporate best practice, and the natural reaction is to co-opt the message and bring the items in the left column back into the right column.

In the case of Scrum, it's that "individuals and interactions over tools and processes" line. Scrum did start out as a popular Agile methodology among developers, but because it was the most prescriptive and process-oriented of the methodologies, it got adopted and twisted by management and turned into a tool to reassert authority. Now it reasserts that tools and processes are, in fact, more important than individuals and interactions, but this time with the "Agile" label.

I'd love to try working on a Scrum project that doesn't rely on JIRA. Just notes on a corkboard with a quick "need anything?" conversation in the morning.

> I'd love to try working on a Scrum project that doesn't rely on JIRA. Just notes on a corkboard with a quick "need anything?" conversation in the morning.

Don't you find value in keeping the digital record of the work? For example, if you want to keep track of dependencies that a given task has; or want to get back to the description of a given piece of product that was captured in a ticket (a user story, links to designs, references to other documents, etc.) after some time has passed? Notes on a corkboard are transient; tickets in the Jira are permanent. Isn't there value in that?

BTW, why do people dislike Jira so much? Apart from it being slow or not allowing assignment of tickets to more than one person?

>Apart from it being slow

That's exactly why. Bad JIRA implementations can easily incur 5-10 seconds of wait time just loading the page alone. JIRA as a tool allows everything under the sun for management to configure, which makes management do exactly that, configure everything under the sun.

It's not unheard of having to tick 15-25 fields + checkboxes + dropdowns (most of which could've been autofilled or cut and made lean) because management likes it that way. I hope I don't have to explain why a crowd largely composed of "I hate doing the same manual work more than once" collectively sighs at this notion.

Then you add onto that a workflow which requires one to open JIRA multiple times, multiple stages etc. and these people end up spending a lot of time on something they feel is incredibly inefficient. Great way to tank morale.

"But that's a problem with the use of the tool, not the tool itself!"

And we've seen this story a thousand times. If tools allow for weird things, weird things happen. Beyond that, I don't really see why people prefer the Atlassian stack which shows similar issues all-over and is a hassle to cobble together, when GitHub and GitLab do these things out of the box. The common complaint is "well GH/GL don't have X and we really need X", when the organization has never tried doing things without X.

There's value in keeping records for projects that last.

But there's a slight difference between keeping records for accountability (just do the bare minimum to show that work happened as requested/regulated) and keeping records for documentation/action/archival.

The difference shows in the care you take to design and operate those records.

As for Jira: 1/ it IS slow 2/ it IS bloated (visually and functionally) 3/ it does work for a very specific limited number of ways to do things - but never yours 4/ when you start to look at the APIs and data model, you start to understand that it's been designed/built by people not having a clue what it was going to be used for, and by who - and it definitely shows.

Bugzilla is old, clunky; Trac is... extremely focused; GitHub issues are limited. But I would more happily go back working with any of these and plug into additional tooling rather than with Jira.

Granted, none of these allow for a clear understanding of a ticket lifecycle, or a whole project. But that's because this belongs in a narrative, not in a dashboard. And a lot of people don't like to write or value written docs.

> Granted, none of these allow for a clear understanding of a ticket lifecycle, or a whole project. But that's because this belongs in a narrative, not in a dashboard. And a lot of people don't like to write or value written docs.

Maybe there is a market for "literate programming merged with project/task management" where the narrative is maintained as a source of truth and individual items can be queried (or compiled) out of it. The narrative could based on some of the ideas in this article even: https://www.joelonsoftware.com/2000/10/02/painless-functiona...

We had that at Symbian in 2006. It was great. As a scrum master I did later use Jira to manage a backlog along with the product owner, but it was just for the two of us: all the stories were written on cards when they were ready to be worked on by the devs. Epics were also written on cards on a big wall... but each of those had an accompanying document / wiki page.

Well, the first point of Agile Manifesto says

>Individuals and interactions over processes and tools

and I would argue Scrum is a process and a rather heavyweight one. Thinking in terms of Scrum instead of your team/members and their preferences is getting it backwards.

Reply on news.ycombinator.com