Live data from Hacker News

We are doing it wrong – the truth about agile development

linkedin.com

1–10 of 42 posts

Re: We are doing it wrong – the truth about agile development

#2
“You need to spend 20% of your sprint refactoring.”

Yes! Agility is largely a function of (the quality of) your code assets, so much more so than your team processes. And you can’t keep a code asset at quality unless through constant vigilance (ie, refactoring).

Now we only need to talk about who is doing the refactoring and what are their values?

Re: We are doing it wrong – the truth about agile development

#4
post #3

"Agile" should have stopped at the Agile Manifesto. The principles described there are useful. Scrum sounds good in theory but in reality I have never seen it really work. Mostly it devolved into a micromanagement tool.

I read this in the article, and had to wonder what on earth it had to do with making things:

If you are the scrum master, keep doing what you are doing. Keep coaching the development team on our core values of openness, commitment, focus, respect, and courage.

Re: We are doing it wrong – the truth about agile development

#5
Extensive discussion on agile yesterday under My 20-Year Experience of Software Development Methodologies | https://news.ycombinator.com/item?id=15476357 (Oct 2017, 142+ comments)

>sytelus: The obvious problem is that these folks prescribing the development process are not active developers.

>mmcnl: The agile manifesto was in fact drafted by software developers. Also, agile doesn't prescribe any process at all, in fact, it does the opposite. Agile in essence is quite beautiful, unfortunately it gets twisted and turned upside down until it's just another methodology (which is exactly the opposite of its original meaning).

Re: We are doing it wrong – the truth about agile development

#7
post #3

"Agile" should have stopped at the Agile Manifesto. The principles described there are useful. Scrum sounds good in theory but in reality I have never seen it really work. Mostly it devolved into a micromanagement tool.

I read this in the article, and had to wonder what on earth it had to do with making things: If you are the scrum master, keep doing what you are doing. Keep coaching the development team on our core values of openness, commitment, focus, respect, and courage.

The scrum masters I have seen (including myself) turned quickly into bureaucrats that mainly managed deadlines. In theory the scrum master should constantly improve processes but from what I have seen they quickly get blocked by management and don't achieve much.

Re: We are doing it wrong – the truth about agile development

#8
The real problem isn't Management style. Agile would be irrelevant if every programmer found it incredibly trivial to refactor huge portions of the program or very hard to introduce even one bug into the system....

We see a problem, we don't completely understand it, we think it's a problem with process but the same issues happen regardless of process, so then the issue must not be process... What's the common connection between all of this?

The complexity of code. Bugs, development time are directly related to coding style and coding technology and that is where the real issue lies.

The article author references martin fowler. Martin Fowler advocates a style of programming which makes it harder to refactor and easy to introduce bugs.

Re: We are doing it wrong – the truth about agile development

#9
post #2

“You need to spend 20% of your sprint refactoring.” Yes! Agility is largely a function of (the quality of) your code assets, so much more so than your team processes. And you can’t keep a code asset at quality unless through constant vigilance (ie, refactoring). Now we only need to talk about who is doing the refactoring and what are their values?

The number "20%" scares me because people will makes his a hard rule. Soon you'll have to justify why you didn't refactor your stuff.

Re: We are doing it wrong – the truth about agile development

#10
post #9
post #2

“You need to spend 20% of your sprint refactoring.” Yes! Agility is largely a function of (the quality of) your code assets, so much more so than your team processes. And you can’t keep a code asset at quality unless through constant vigilance (ie, refactoring). Now we only need to talk about who is doing the refactoring and what are their values?

The number "20%" scares me because people will makes his a hard rule. Soon you'll have to justify why you didn't refactor your stuff.

Or worse, I spent 1 hour writing it, so 15 minutes refactoring... And done, no more refactoring...
Post reply on HN