Hacker News Reader

Comment by kstenerud | Hacker News Reader

Yup, my major beef with XP back in the day was in its arrogance: This is the way to do things, and if you don't do it entirely this way, you're not extreme programming! (that was literally in the manifesto)

But the article highlights the good points of agile, and I agree with them:

- Iterative development (smaller steps with faster feedback)

- Unit tests (and building with unit tests in mind)

- Code Refactoring (which you can do confidently when you have unit tests)

The rest of XP/Agile is not necessary, and in some cases even detrimental. YMMV

View on HN

> if you don't do it entirely this way, you're not extreme programming

But isn't this... OK? Extreme programming is probably defined as a certain set of practices, and if you are doing a subset of that, you are doing something else. This doesn't make you into a bad or a lazy person; it just means that your process is something other than extreme programming.

It's the same with scrum. It is extremely common for people to pick some practices from the scrum framework, skip others, and still claim that they are doing scrum. It gets very confusing when people do this.

Scrum practitioners/coaches always seemed to have this idea that if Scrum wasnt working then you werent doing it properly.

Scrum had some serious problems, too, but nobody wanted to admit to them.

Scrums biggest problem has always been management interpretation of sprints as deadlines (commitments) and not estimates (forecasts).

The former eventually leads teams to lowball everything to make sure they always complete everything at the expense of trying to accomplish more. Which will then lead the company to wonder why everything is so slow.

Getting people at the top to understand that challenge is the hard part.

Scrum, XP and/or Agile are not going to save you if the guy leading the project decides the hardware and firmware have to be completely re-done for no good reason other than his own opinion, lack of experience and ego mixed in with a bit of "not invented here syndrome", "if it ain't broken fix it anyway" and "make it complex not simple stupid" (recent random example).

My point being: other aspects of companies and teams are far more important than the latest fashionable project management methodologies/frameworks/philosophies.

I find it hard to care about these trends.

The critical piece to any framework is how work is prioritized. If it’s by 1 guy, you will have the problems you describe.

If you have an approach that forces the people doing prioritizing to weigh Return on Investment (benefit or value / estimated time) to largely guide the priorities, busywork with little benefit like you describe won’t be prioritized.

It’s critical.

Often the people at the top understand. However what most developers fail to understand is the guy at the top really needs accurate estimates. the more accurate the estimate the better he can do their job. Thus they are constantly loohing for a magic bullet that gives them that. it doesm't need to be perfect, but the closer the better.

It's not that they need accurate estimates is that often sales people want to share those estimates externally, so anything that takes longer due to unexpected complexity becomes an accountability issue.

The https://en.wikipedia.org/wiki/Osborne_effect should have taught us not to sell things that don’t exist yet and possibly never will.

There is a balance there. sometimes you need to sell on the next version's features to get enough now to develob that. Not everyone gets unlimited venture capital - and it isn't always a good idea to take it if you can.

Accountability is everywhere, but software managers are always looking for the silver bullet that would let them have a stellar reputation of being on time.

> Scrum practitioners/coaches always seemed to have this idea that if Scrum wasnt working then you werent doing it properly.

And if people mean different things by the word scrum, it is rather hard to tell whether they are doing it properly :-)

Scrum is pretty difficult to do properly (the famous "easy to understand, but difficult to master" formula; although I would argue that it isn't that easy to understand either, at least not something that someone unfamiliar with it can understand in a day or two). It requires certain changes within the organization, which few organizations are willing to adopt.

I find this to be a problem with agile, but not so much with Scrum. It's quite proscriptive and there is a set of quite specific rules and processes you can follow.

> I find this to be a problem with agile, but not so much with Scrum.

I am seeing problems left and right. Mostly because people often copy the activities (they would often even call them rituals or ceremonies, as if to make it even more obvious that they are treating them as mysterious quasi-religious practices) without understanding what they are intended to achieve.

For example:

    - Lots of daily scrums in which people go around the circle saying what they did yesterday and what they are going to do today. No sense of a common sprint goal, and no indication of collaboration in reaching it.
    - Lots of sprint reviews that are just demos
    - Lots of sprints without goals, that are just timeboxes to finish a certain number of tickets/stories
    - Lots of teams that remain hierarchical, and instead of a real product owner have some kind of a middle manager (who might also assume scrum master responsibility, because he is manager)
    - Lots of teams focusing on story points, velocity, and estimation
    - Lots of teams that don't adapt previously formed plans to the emerging reality

And so on, and so forth.

>Lots of daily scrums in which people go around the circle saying what they did yesterday and what they are going to do today. No sense of a common sprint goal, and no indication of collaboration in reaching it.

I remember reading the scrum manual but I don't remember it saying anything about it being necessary to show esprit to corps and a "collaborative spirit" during standup.

It did say how to conduct a standup ceremony though...

>Lots of teams focusing on story points, velocity, and estimation

Well, they did make these things a part of scrum.

The problem is that these kinds of things become shackles for the mind, denying the agency and mental suppleness required to navigate a changing and chaotic world for which we can never achieve perfect knowledge (or even anything remotely close to it).

There is no such thing as a perfect set of rules or practices - only things that are useful in certain contexts. It is the practitioner's task to decide which principles apply, and to what degree.

Saying "You're not doing [brand new popular thing] unless you do it this exact way" is a trap laid for neophytes who lack the experience to discern that this is just arrogant bullshit, denying them the exercise of their own brain to judge what applies where (and learn from their mistakes).

> This is the way to do things, and if you don't do it entirely this way, you're not extreme programming!

Which is fine. They defined a set of practices, called it XP, and if you don't do these, you're not doing XP.

Code refactoring with unit tests is fine when it is within the unit test units, but when it crosses unit boundaries the tests often must be re-written, doubling the effort required.

Reply on news.ycombinator.com