Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Agile at 20: The Failed Rebellion

simplethread.com

Post reply on HN
Print view View original

91–100 of 320 posts

Re: Agile at 20: The Failed Rebellion

#91

Post by chris11 »

porker wrote: post #71
TedDoesntTalk wrote: post #58

Earlier quoted context omitted.

This sounds soul-crushing and I hope never to work in such an environment.

> This sounds soul-crushing and I hope never to work in such an environment. It isn't. Soul-crushing is doing "Agile" where the "scrum master" tells you how long each ticket will take, where the client is invisible and never involved, and where retro is 1 hour at the end of the sprint and focused on blame.

That example does sound really bad.

But I would feel disengaged if everything was broken down to 1 point stories at the beginning of the sprint.

Re: Agile at 20: The Failed Rebellion

#93

Post by fsloth »

AndrewKemendo wrote: post #41

The fundamental problem with Agile is the fundamental problem with all product development: The customer doesn't know what they want Agile assumes as a first principal that including the customer throughout the development process will align the building team and the customer to come to the same conclusion. This is almost never actually true. Having built and managed a lot of products I can state fairly confidently t…

I disagree mildly all succesfull products are pure accidents.

Especially in B2B and technical realm it is feasible to actually plan in every sense of the word "plan" a new product - business, tech, etc. Of course the plan must be malleable on the facts on ground. And probably is incorrect on a few places. But never the less, a plan that will get a business from place a (no product, but strong understanding of customer needs and business plus strong technical savvy) to place b (final product, customers, revenue etc).

I've seen this many times, both in startups with a new product and new customers (automotive software) and established companies that just expand their existing portfolio (cad software).

I'd say the "not an accident" is feasible if these facts are in place:

- enough A-team players (tech,business,sales)

- healthy culture (that facilitates long term growth and can focus on the product without too much politics)

- understanding of customer business

- identified an OBVIOUS need for the customer

- strong engineering org (can be just a few coders that get things done or larger)

So I agree, you can't train for these requirements like you can train airplane pilots.

But I do claim you can have enough understanding that is the current org in possession of these qualities. And if it is, it's a very reasonable risky investment to try to create a product for the need.

Re: Agile at 20: The Failed Rebellion

#94

Post by eesmith »

mytailorisrich wrote: post #74
AndrewKemendo wrote: post #41

The fundamental problem with Agile is the fundamental problem with all product development: The customer doesn't know what they want Agile assumes as a first principal that including the customer throughout the development process will align the building team and the customer to come to the same conclusion. This is almost never actually true. Having built and managed a lot of products I can state fairly confidently t…

"Customers don't know what they want": this is something Agile specifically tries to address by releasing often and adapting to change. This is a quick feedback loop: the customer can quickly see a product and the development can quickly adapt. What was the 'standard' way to develop systems when the Agile Manifesto was written: the same as for building a bridge. You gather and freeze requirements. You write a massive…

Your characterization is not true. The reality was quite the opposite.

Here's the introduction of Steve McConnell's "Rapid Development" from 1994 - well before the Agile Manifesto! - Chapter 1, page 1:

> The product manager told me he wanted to build a product right for a change. He wanted to pay attention to quality, prevent feature creep, control the schedule, and have a predictable ship date.

> When the time came to actually do the project, it became clear tha getting the product to market quickly was the only real priority. Usability? We don't have time. Performance? It can wait. Maintainability? Next project. Testing? Our users want the product now. Just get it out the door.

> This particular product manager wasn't the manager on just one product. He could have been almost any product manager I've worked for. This pattern is repeated day after day, state by state, all across the country. ...

This is as far from building a bridge as you can get. The next page of the book starts:

> [1.1] What is Rapid Development?

> To some people, rapid development consists of the application of a single pet tool or method. To the hacker, rapid development is coding for 36 hours at a stretch. To the information engineer, it's RAD - a combination of CASE tools, intensive user involvement, and tight timeboxes. To the vertical-market programmer, it's rapid prototyping using the latest version of Microsoft Visual Basic or Delphi. To the manager desperate to shorten a schedule, it's whatever practice was highlighted in the most recent issue of Business Week.

Agile drew from earlier methods ("intensive user involvement", "rapid prototyping") which were pretty common even before Agile.

Re: Agile at 20: The Failed Rebellion

#95

Post by axegon_ »

jnwatson wrote: post #50
axegon_ wrote: post #16

I never really understood the hype around (f)ragile (as one famous google engineer called it in a small closed circle a few years ago). I think the main problem is that in the past 7-8 years it has become more of an evangelism effort rather than anything. > The important piece that gets forgotten is that Agile was openly, militantly anti-management in the beginning. Yet here we are: The process just became an endless…

Using story points for evaluating developers goes against the ideals of Agile. It also makes story points useless. See Goodhart’s law.

No, I mean using story points for evaluating the complexity of a task (a lot of companies/teams use them this way at least).

Re: Agile at 20: The Failed Rebellion

#97

Post by baxtr »

dirkt wrote: post #57
AndrewKemendo wrote: post #41

The fundamental problem with Agile is the fundamental problem with all product development: The customer doesn't know what they want Agile assumes as a first principal that including the customer throughout the development process will align the building team and the customer to come to the same conclusion. This is almost never actually true. Having built and managed a lot of products I can state fairly confidently t…

> The fundamental problem with Agile This is not what the article is about. If you look at the Agile Manifesto, it says e.g. - Individuals and interactions over processes and tools - Responding to change over following a plan What you get in quite a few big companies following "Agile" with the air quotes is the opposite: - Processes and tools over individuals and interactions - Following (and making) a plan over resp…

It’s easy to blame management. In my experience the radicalism of some agile coaches and scrum masters helps to fuel the divide significantly.

Re: Agile at 20: The Failed Rebellion

#98

Post by fukmbas »

forgotmypw17 wrote: post #52

I've seen Agile at a handful of shops, a couple dozen projects. I've seen it implemented well just once... The "scrum master" was a dedicated role, filled by a technically able person, who sometimes helped a little bit with the coding. This individual had read several books and taken a course on Agile. They were sincerely passionate about Agile and wanted to implement it effectively. The "project manager", a DIFFEREN…

Lmao an entire day on retro... That's thousands of dollars in wasted productivity. Garbage

Re: Agile at 20: The Failed Rebellion

#99

Post by hyperman1 »

ipaddr wrote: post #84
hyperman1 wrote: post #70

Earlier quoted context omitted.

I'll give 2 examples. One was a CEO who hadn't any technical background, but he knew what ICT could and could not do for his company. One day we rewired all of our network, a massive weekend job. He was there, even if the only thing he could do was pulling network cables out of bags and straightening them. He saw who and what worked or not, he saw where we struggled even if he didn't understand a word of our technica…

That's not a CEO job. His job is to make sure the enterprise is funded and sets a vision. The first example must be a small company. 2. This sounds like a manager in an enterprise level company If you choose to work where a multi-level manager structure exists you should give that manager respect because he has to navigate a political landscape that takes certain skills. Besides managing people and knowing what custo…

1 was for a 500 people company. Not small not large. The company grw while others in the sector shrunk, so he did well.

Considering 2,this demonstrates what is wrong with big enterprise. If the politics are more important than the work, the work won't get done. Just like I don't have respect for Trump just because he managed to rule the most powerfull country in the world, I don't have to respect a manager who's team fails again and again, after which they get thrown under the bus just to save the face of a higher up.

Note how the CEO mentioned had no ICT knowledge, he just knew enough to knew where he stood. Same for marketing, accounting etc..

Re: Agile at 20: The Failed Rebellion

#100

Post by outsomnia »

baxtr wrote: post #97
dirkt wrote: post #57

Earlier quoted context omitted.

> The fundamental problem with Agile This is not what the article is about. If you look at the Agile Manifesto, it says e.g. - Individuals and interactions over processes and tools - Responding to change over following a plan What you get in quite a few big companies following "Agile" with the air quotes is the opposite: - Processes and tools over individuals and interactions - Following (and making) a plan over resp…

It’s easy to blame management. In my experience the radicalism of some agile coaches and scrum masters helps to fuel the divide significantly.

You know why it's "easy" to blame "management"?

Because they often don't understand the technology question or even what the issue is, but insist to intercept every decision.

Post reply on HN