Hacker News Reader

I had this problem too. My younger developers pushed really hard to bring Agile in. One of the supposed benefits was that all developers were treated equally (today we might say they were fungible)

We have it a really good shot; we even hired a Certified Scrum Master. But after a while it seemed to me that we were just doing lots of tiny waterfalls. It was nothing for a developer to spend a whole sprint spinning their wheels and not making progress.

Long story short, 2 years later I took over the team, threw it all out, and set up a system based around Kanban and hands-on management. And suddenly we became productive again.

(Not saying Kanban is a solution, just that Agile is not)

People really use weird labels nowadays. Kanban is agile!

You’re right, what I should have said is that Scrum doesn’t work. And I tend to use big-A Agile when talking about the formal processes and little-a agile when talking about the manifesto.

I think the manifesto is great btw. It’s just that the formal “Agile” processes, such as the way Scrum is practiced, don’t implement it.

"Agile" in job reqs usually means "we do Scrum with Jira, you'd better be able to align with the Scrum process".

Interesting, what I like about kanban is that (in my opinion) it explicitly recognizes that work proceeds through specific stages, and therefore tickets go through a mini-waterfall. Waterfall is great with a small enough batch size. In contrast, scrum seems to pretend that design, development, code review, QA, etc, all happen at once throughout the sprint.

We are probably on the same page here but I would describe it differently.

For me, there is a whole separate prioritisation and design process that runs ahead of the Kanban board. So by the time work arrives on the board, we have a pretty good idea of what we need to build.

The difference is that in waterfall, by definition, we would build what we’re told. But implementation of a design should instead be an ongoing conversation/negotiation between the high-level designer and the low-level implementor. And that can result in big changes to the high level design as problems, inefficiencies or new ideas come up. That is the “hands on” management I mentioned.

My way of working is heavily influenced by DDD. Design can only get you so far, and any process that imposes a top-down structure is IMO likely to fail.

They do happen at once if the stories are working slices of software, and they’re all in different stages.

Agile planning has used kanban-style stage notation for a long time. It’s just not always laid out in a grid.

On day 1 of the sprint, aren't they all in the same stage?

Not in our case. We’re breaking work into small stories that are self-contained improvements that can (usually) move into production independently of anything else. Typically an individual or team can complete more than one in a two week period. But either way, we won’t break them any smaller than that atomic “completeness” to fit into an arbitrary time interval. The sprint is just for automatic estimating of when we’ll get to a story, how often to demo progress to interested parties, etc.

In that case, we might only be differing on terminology. In my understanding, scrum's defining feature was the fixed time box. What you described sounds like kanban to me!

I would say we are using a mix of kanban tools and the scrum process to practice agile software development philosophy. We aren’t really using the kanban process since teams shepherd their stories to completion regardless of WIP at any step. And user research is more based on the continuously evolving end goal than what is being pulled in by openings in the kanban board. But yes, we are not trying to define two weeks of work up front, just noting what gets done every two weeks.

Where I work we don't do any "agile" and I always have some fun explaining that to would-be hires. I think the overall reaction is generally positive.

Lots of awesome software was written without:

- Unit tests

- TDD

- Agile

- CI/CD

(to pick a few random practices). ... or in Agile terminology "there is some value in those set of practices".

The sad thing about Agile is that it reflects a certain naivety on behalf of its founders. That somehow we can encourage better software (and arguably corporate) practices through a set of principles (that aren't that bad). It's literally the road to hell is paved with good intentions.

Unit tests allow complex and nontrivial code to be modified without introducing nasty bugs. A lot of software that I've seen that has no unit tests and runs well got there because people slaved away cleaning up nasty bugs that would have been caught with unit tests. I cannot understand how people think unit tests aren't worth doing and I can only assume these people don't know how to prove their code works, which is quite worrying.

Unit tests are overrated. They are for algorithms and really complex functions.

Unit testing with 100% coverage is a red flag for me, someone spend insane amounts of time writing tests for useless shit.

Integration tests are the ones that determine whether stuff actually works, have more of them. There's no point in having a test to see if pushing a button produces the correct event if there is no integration test to see if pushing the button does what it's supposed to do in the backend.

What type of software do you write? I cant imagine writing a db implementation without unit tests for example.

Just like Agile unit tests came about as a fashion. I think the history is a bit murky but Kent Beck was one of the proponents and he also happens to be one of the signatories on the Agile Manifesto. Let's say circa 1997.

There was plenty of very well written software in existence at that point. Large applications, operating systems, databases, games, embedded applications etc. etc.

That's not to say there's anything bad about unit tests just like there's nothing bad about the Agile principles. They don't prove your code works though, that's not really possible. A useful tool- sure.

There are bad things about unit tests compared to any other way of getting test coverage. You have to make your architecture more complex to allow them - people call this “testable” and pretend dependency injection and other weird ways of avoiding straightforward code are good. And they rarely fail and have to be maintained.

It might be good to write them as you’re bringing up new code, but deleting the useless ones after that could be an improvement.

Well written by what metric? How are you evaluating that? And how do those software systems compare in complexity to what is being developed today?

Honestly- subjectively. Does the software crash often, do I see weird behaviour as a user, what's the number of users, bug report rates. I think those systems do compare in complexity to at least pieces of todays software. A lot of this older code is still powering things today/morphed into newer/larger systems.

I've worked in more recent times on software that was used by millions of people, was extremely reliable, and didn't have a lot of unit tests. We did have other forms of automated testing though.

Interesting to think that agile will somehow lead to better software. I like agile in general, and I think that rather than being a superior way to develop software, it better accomodates the realities of many software projects. Websites and -applications are fast moving targets, with marketing campaigns, new features, the need to react to an outside change - I think agile suits this environment.

The actual process doesn't matter that much. It can be waterfall, kanban or agile.

As long as there IS a process.

Agile is a way of protecting the coders from ad-hoc spec changes, because that's against The Process. The Process is a thing that management and stakeholders understand.

If there is no process, they can just turn up at Cowboy 1:s desk and request/demand/suggest their latest invention and expect it to be done.

> The Agile consultants somehow convinced a large segment of the industry that they discovered and/or invented the notion of working with users, of gathering feedback from them

even worse, now the specialist Agile consultants have themselves been replaced by McKinsey/PWC garbage

you can imagine how well one of these multi-million dollar "Agile Transformations" go

> They were taught in school that there exists this bogeyman software development methodology called "WATERFALL" where pencil-pushers in a windowless office write requirements which they hand off in a printed binder to the team of engineers in the basement, who is not allowed to ever talk to the user.

Having worked in government and big-co companies before: sadly, this is not a bogeyman trope, but reality. Including the printed binder, although it's called "spec sheet" or "tender document" (or whatever the correct english words for "Ausschreibungsunterlagen" and "Lastenheft" are).

The amount of "silos" and "leadership" involving themselves in petty fiefdom fights is astonishing - that is partially a reason why small startups are so much more efficient, they haven't had the time to develop layers and layers of middle management wanting to justify their existence, protecting budgets or establishing their authority. Government projects tend to be the worst target for such micromanager wannabe-king types, given that they can rarely be fired from their jobs for incompetence.