Google's DeepMind Achieves Speech-Generation Breakthrough - <AUTHOR> http://www.bloomberg.com/news/articles/2016-09-09/google-s-ai-brainiacs-achieve-speech-generation-breakthrough <comment><USER2> Also [https://news.ycombinator.com/item?id=12455510](https://news.ycombinator.com/item?id=12455510)

<comment><USER3> This Bloomberg article adds nothing, and is less informative & interesting (doesn't have the audio samples for starters) than the original DeepMind blog post, and shouldn't be on the front page.

</comment></comment><comment><USER4> Here's the link to the paper: [https://drive.google.com/file/d/0B3cxcnOkPx9AeWpLVXhkTDJINDQ...](https://drive.google.com/file/d/0B3cxcnOkPx9AeWpLVXhkTDJINDQ/view)

And the WaveNet site with audio samples: [https://deepmind.com/blog/wavenet- generative-model-raw-audio...](https://deepmind.com/blog/wavenet-generative- model-raw-audio/)

The comparison against state of the art Parametric and Concatenative methods are pretty mind blowing.

Particularly listen to the music samples. That's a generated piano piece that sounds quite musical.

They even include breaths and other auditory signals that really make for a convincing speech sample.

<comment><USER5> > Particularly listen to the music samples. That's a generated piano piece > that sounds quite musical.

That blew my mind. I've heard computer generated music before, but it's been just synthesized with usual methods while the computer is just the "composer".

I find the crackling and buzzing a bit awkward, though. It's probably an artifact of the algorithm and can probably be mitigated with some simple filtering.

</comment></comment><comment><USER6> This raises some interesting questions. I've always thought that recording conversations would be sufficient "proof" of what someone said. It seems that soon audio alone will not be sufficient — video will be necessary as well.

<comment><USER7> Sorry! look at this video and restate your statement about "video". [https://www.youtube.com/watch?v=ohmajJTcpNk](https://www.youtube.com/watch?v=ohmajJTcpNk)

<comment><USER8> Wow!! That is amazing!

<comment><USER9> They used this technique in Mr.Robot to emulate Obama talking about the Ecorp hack

<comment><USER10> WOW

i figured knowing obama's interest in good tv shows, he might have done the cameo! this is really neat stuff

</comment></comment></comment></comment></comment><comment><USER11> It'll be interesting to see once "true" voice emulators become main stream how it's exploited for good and evil.

Reminds me of "virtual" kidnapping scams where an attacker knows the victims phone will be unreachable and the attacker calls a relative demanding they wire funds or the victim will be killed. Attacker plays back a voice sample they've captured from the victim that makes it sound like they're in trouble an need help; basically the attacker calls the victim and say something like "May I help you?" repeatively until the victim responds with something like "No, I don't need your help!" an panicked voice - which is then edited to say "Help! I need your help! Help!"

</comment><comment><USER12> On the fluff note: If this system is called WaveNet. The next weather prediction system based on deep learning should be called SkyNet.

<comment><USER13> SpaceX's server farm is called exactly that. Supposedly Elon hates the name...

<comment><USER14> I can almost hear him: "SkyNet is no joke, guys..."

</comment></comment></comment><comment><USER15> Here are some fun samples for curious

[https://deepmind.com/blog/wavenet-generative-model-raw- audio...](https://deepmind.com/blog/wavenet-generative-model-raw-audio/)

</comment><comment><USER16> always wondered if something like this could be done. Now just train it on an famous individuals wav data and you got a free celebrity endorsement.

<comment><USER17> I think that something rather different may take place: celebrity voices will be copyrighted (or granted similar protection under law) by the individual themselves or their estate, and licensed for use.

David Attenborough, Morgan Freeman and Billy West: call your offices.

<comment><USER18> What if they are trained on soundalikes' voices? The tricky part would be that you probably couldn't label it as the celebrity's voice.

<comment><USER16> The more I think about it even if you used originals you could licensed John Wayne's voice from Disney(or who ever owns clips of it) or something you couldn't imply there was an endorsement it would be fraud.

</comment></comment></comment></comment><comment><USER19> I want to see WaveNet used to create a synthetic William Shatner, trained on old episodes of Star Trek, TJ Hooker and priceline.com commercials!!!

<comment><USER14> Patrick Stewart and Morgan Freeman's voices should definitely be replicated.

</comment></comment><comment><USER20> What's the point of authoring an article like this and not including samples so we can listen to it?

<comment><USER21> The original blogpost has samples and everything, resulting in a much better article

[https://deepmind.com/blog/wavenet-generative-model-raw- audio...](https://deepmind.com/blog/wavenet-generative-model-raw-audio/)

</comment></comment><comment><USER22> Really this is natural text-to-speech.

16,000 analyses per second. So, given Moore's law, around the iphone 9?

<comment><USER3> 90 minutes of computation for 1 second of audio on DeepMind's GPUs: [https://twitter.com/hardmaru/status/773968758519902208](https://twitter.com/hardmaru/status/773968758519902208)

That's a lot of cranks of Moore's law. Better hope for considerable algorithmic improvements. (Raw is probably overkill anyway.)

<comment><USER22> 54000 seconds! Let's say it halves every year. To get it to one second you need about 12 years. But if it drops by 1/3 every year, it would take 7.

Not stating anything especially mind-blowing. Just restating the shocking speed of exponential growth/shrinkage.</comment></comment></comment>


The Failure of Agile - <AUTHOR> http://blog.toolshed.com/2015/05/the-failure-of-agile.html <comment><USER2> The only "process" that I've ever seen work is "have someone really good in charge." It doesn't matter if they are male or female, and I've learned that it doesn't matter if they initially have a technical background.

The best project manager I ever worked with, in the 16 years I've done this work, was a woman who initially did not have a technical background, but she was willing to dive into the technical end of things. She eventually taught herself SQL and how to write Cucumber tests, so she could better QA test the code she was overseeing. I met when she was in her 4th year, and she had an impressive skill for estimating how long a given task would take, and whether things were going well or badly.

If you have someone really good in charge, and they call their system "Agile", then it might appear that Agile works. If you have someone terrible in charge, and they call their system "Agile", then it might appear that Agile sucks. Likewise, if they call their system "XP" or "Deep Review" or anything else. But the only process that seems to matter is "have someone really good in charge."

<comment><USER3> Uh,

I can't see how a person can have "goodness" without that goodness having a structure which could be studied, systematized and taught somehow.

Whether that could be made into the kind of system marketed by gurus is naturally a different question and I'd be skeptical about that.

<comment><USER4> > I can't see how a person can have "goodness" without that goodness having a > structure which could be studied, systematized and taught somehow.

How do you teach someone an attention to detail, good work ethic, and perseverance?

Those are character traits, not methodologies. If a PM has those 3, he'll be a good PM regardless of anything else. Actually, if someone has those 3, they'll be a good _anything_.

Agile or something else might make someone _better_ , but they can't determine if someone is _good_.

<comment><USER5> You can teach them. I personally had a lot less attention to detail before studying math. Good work ethic and perseverance can be taught as part of reaching a bigger goal, for example in sports.

<comment><USER6> Yeah I agree, but I suppose the person has to be willing to learn too. I can point to a couple of specific teachers and lecturers during my school years, and then the technical director at one job, who all influenced me a lot and shaped my work ethic and desire for attention to detail. Colleagues and friends may not have felt as influenced by the same people.

<comment><USER5> It takes two people. I guess I'm implicitly assuming that the student will be relatively bright and wiling to learn but will be lacking some of those soft skills at first.

</comment></comment></comment></comment></comment></comment><comment><USER7> I've unfortunately never seen Agile work. I had one project where we basically had our own process that just kind of evolved, a mix between waterfall and agile I guess. That actually worked well for a year, until management had to fix it, because we weren't Agile. We actually went from 2hrs of meetings/week to _almost two full days, I 'm not shitting you_ (to be fair, they went a bit back on that and cut it down to one day fairly quickly, but we still wasted more time by becoming more Agile).

Then my job was to fix others peoples projects from companies that weren't familiar with the technology they used as a consultant. All of them were agile, SCRUM and SCRUM of SCRUM.

And it just didn't work, Ive never seen such dysfunctional teams before. Nothing worked. I realize I've probably only seen the bad side of SCRUM because whenever I got called in they were behind schedule and already fucked up the project anyways.

I think SCRUM can work, maybe, hopefully. But to this day I have yet to see it happen. You have to do it right, and even with basically zero experience with SCRUM I was able to tell that they weren't doing it right, they were just wasting time and not having ANY coordination whatsoever.

I think what others have said here is right, if you have a great team, it will organize itself anyway. If you have a bad team, jumping on the agile bandwagon won't help you.

<comment><USER8> > we basically had our own process that just kind of evolved, a mix between > waterfall and agile I guess.

Interestingly enough, I find that to be something more in line with agile than the way most teams treat agile process. The agile manifesto itself event says:

> Individuals and interactions over __Processes __and tools

Which in a way makes most agile processes a sort of oxymoron. At the end of the day we just need to understand that we're building software, and we need to do more of what helps us build software and less of what prevents us from building software. Agile (or what people call agile) can do both.

<comment><USER7> This.

Basically, our process before was that the PM would plan a release with the customer and a few senior devs, distribute the tickets needed for that release to team members, and then the team shifted them around between eachother trying to make it work, sometimes we couldn't fit some tickets in, sometimes we were able to fit a bit more in. These were fairly long cycles like up to 3 months or even longer in one rare case.

Then we became Agile. When you have 20 devs on a project, your standups won't take 5 minutes. Estimating the tickets won't be done in an hour because too many dependencies. They tried to split teams up into two, but then team A had no idea what team B was doing and there was just way more overhead.

Most people will look at you in a weird way when you tell them you had 20 devs in _one_ team. But what can I say, it certainly worked better than the other things we tried.

As I said, I'm sure it _can_ work, but you need to do it right, and we certainly didn't.

</comment></comment></comment><comment><USER9> Most of the agile problems I've seen have been organizations cargo-culting things they've read, rather than trying to actually be dexterous. Big-A agile versus, well, "agile".

Scrum has been the largest offender - squashing discussion in standups, allowing scrum to erode QA process, rote meetings that take 50% of the week, story points and refusing to discuss timetables in hours when absolutely needed, reporting status multiple times, having others estimate tasks who are not doing those tasks, etc.

These organizations that have done so have been some of the least agile, and waterfall-esque organizations can even be better. (They planned up front well, they changed a few minor things in the middle maybe, but cut out the overhead).

<comment><USER10> I think most teams that implement/try to implement agile/scrum/xp and end up disliking it / failing at it completely miss the point of the retrospective step - and thus, skip that step.

Without the retrospective, it's just modified waterfall.

<comment><USER9> We had them in about half of the scrum shops. The retrospective, in my experience, was yet another meeting where things didn't get done either. "We are having too many meetings" was usually not popular either. Don't get me wrong, I like _good_ meetings that result in actionable decisions.

My personal view on scrum is it attempts to trick a software team into micro- managing itself, and it usually results in feeling like kindergarten as a result.

The better shops have been "agile", but not "Agile", and just did what worked, and made changes when they needed to.

I don't think a retrospective is essentially required, but the ability to change and throw out things that don't work -- and have only the right amount of meetings and to talk about the things that matter rather than a template - is.

When a retrospective is to make the team feel they have a voice to make changes, and in reality, nothing changes, that makes the retrospective itself rather soul-crushing theatre, so everybody just says nice things and hopefully nobody gets thrown under the bus when "what could have gone better" is discussed - but often, that still happens.

Scrum is, to me, something people pick when managers don't want to manage.

I like release-early release-often, MVP (in small doses), see [http://michaeldehaan.net/post/118860078737/the-rock-paper- sc...](http://michaeldehaan.net/post/118860078737/the-rock-paper-scissors-of- product-management), and many of those concepts. But I also don't like the idea that requirements constantly shift - which means architecture can't plan ahead.

I also find Scrum usually is so time-pressured, it can create a constant death-march, and also tends to sacrifice time to crush technical problems as a result - there's no "getting done early, so time to fix the architecture over here", etc. If you have a PM that doesn't allow time for such things, it can be rough.

(Not everything fits in two week blocks either)

<comment><USER11> >>I also find Scrum usually is so time-pressured, it can create a constant death-march, and also tends to sacrifice time to crush technical problems as a result - there's no "getting done early, so time to fix the architecture over here", etc.

Sounds like your teams were underestimating task effort.

>>If you have a PM that doesn't allow time for such things, it can be rough.

Anything's rough with a shitty PM, which is what you've described.

<comment><USER12> I think one problem is that Agile gives a numerical value to how much work has been done: story points.

Management get addicted to getting more story points, and any push back from developers that would lower the number in the short term is ignored. Seriously, I've seen "average story points per developer per sprint" reported to 2 decimal places as if it's a meaningful number.

<comment><USER10> That's a problem with management. All of the agile/scrum resources I've read exclaim, in big bold letters, 'THESE ARE NOT METRICS TO EVALUATE PERFORMANCE; THEY ARE FOR ESTIMATION OF EFFORT'

<comment><USER13> Head shops have big signs stating that the goods for sale there are strictly for smoking tobacco too.

</comment></comment></comment></comment></comment></comment></comment><comment><USER14> Every time I read one of those posts, it makes me go back to [http://programming-motherfucker.com](http://programming-motherfucker.com) and I enjoy it just a bit more than the previous time.

<comment><USER15> That's rather good.

<comment><USER16> It is, but I can't look at that website for more than 30 seconds without my eyes burning out.

</comment></comment></comment><comment><USER17> The article starts with the current note - agile as it was preached was never actually achieved, and most companies and practioners are doing it "wrong" (for varying degrees of wrong).

But then it goes downhill with proposing yet another model that will people will try to adopt verbatim, and again, experience failure to implement.

Software is hard, people are hard, so the idea should be to have as little process as possible. Most of it exists as arse-covering material anyway.

What really killed agile fwiw, where the consultants, going from development team to team, peddling false hope, snake oil, and tedious time zapping process that people learnt to game rather than actually deliver.

Of course, someone will pop up saying agile is awesome, they love the daily scrums, the project is fab, the sky is blue, etc. Question is: can it be better?

<comment><USER18> In my experience, the people who say agile is awesome would likely say any process is awesome. Because the true awesomeness they are experiencing comes from being on a good team. After wading through years and years of agile, even working for a major agile tool maker for a while, I've come to the conclusion what process you choose isn't that important. Get a good, passionate, driven team together, and they'll figure out how to kick ass. Without that ingredient, nothing else matters.

<comment><USER19> > In my experience, the people who say agile is awesome would likely say any > process is awesome. In my experience, the people who say agile is awesome > would likely say any process is awesome.

Agile is awesome because its not a process, but a set of principles which addresses exactly the problem that context-blind adoption of processes creates that makes good teams mediocre and bad teams worse.

Most of the processes sold in a context-blind manner as "Agile" suck, but they are a recreation of exactly what the Agile Manifesto was a reaction against.

<comment><USER18> That's true in theory but rarely in reality. The reality is Agile is a process, often a rigid one. I find good teams resist bad process, and mold process to their needs. For teams that do that, whether they are "agile" or not largely becomes irrelevant. I will admit I have found through lots of experience that the "agile movement" is silly at best, so I'm perhaps a bit biased.

<comment><USER19> > The reality is Agile is a process, often a rigid one.

No, the reality is that Agile is not a process, though there are a number of _different_ processes sold as "Agile". (The most common now seems to be Scrum as defined in the Scrum guide and a number of variants on it; for a while XP was somewhat prominent as well.)

> find good teams resist bad process, and mold process to their needs. For > teams that do that, whether they are "agile" or not largely becomes > irrelevant.

Teams that do that _are_ Agile: that's exactly and all of what the Agile Manifesto says.

> I will admit I have found through lots of experience that the "agile > movement" is silly at best, so I'm perhaps a bit biased.

The thing is the "Agile movement" consists of two separate and opposed forces: one (and the origin of "Agile") is people promoting exactly the behavior you mention characterizes good teams, the second (and the thing you seem to have a problem with) is people using the name that the first group came up with to promote exactly what the first group is reacting against -- rigid, context- blind adoption of externally-developed process (largely as a reaction against the threat posed by the good ideas of the first to the second groups pre- existing business of selling rigid, context-blind processes.)

<comment><USER18> But the reality is almost everyone who "does agile" has rigidly adopted scrum, xp, kanban, etc. That is the reality most of us face. Just because a group got together 14 years ago and created a hypothetical scenario that essentially no one follows doesn't seem all that relevant to me.

And at the same time, the fact that a good, adaptive team that figures out what works for them is what you and the original group deem to be "agile" simply reinforces that the whole thing is ridiculous to me. Why did we need a name and a manifesto for that?

The end reality is we have an entire industry built around that stupid manifesto. Sure, it's not what they wanted, but it's what we all got. We would have been better off without it.

<comment><USER19> > And at the same time, the fact that a good, adaptive team that figures out > what works for them is what you and the original group deem to be "agile" > simply reinforces that the whole thing is ridiculous to me. Why did we need > a name and a manifesto for that?

Because while there are lots of people who won't understand that _with_ an explanation, and some people who get it intuitively and _don 't_ need an explanation even with all the noise from people selling one true way, there's also lots of people in the middle who benefit from people selling there one- size fits all approaches _not_ being the only voice in the marketplace of ideas.

> The end reality is we have an entire industry built around that stupid > manifesto

No, we have an industry that existed _long_ before the manifesto built around selling canned, context-blind process and jumping on anything even mildly popular to sell it that, predictably, when the manifesto calling for exactly the opposite of what that industry sold became popular, jumped on that to sell _exactly_ the same thing they'd always been selling.

> We would have been better off without it.

No, I think that there are lots of people who have learned something from the Agile Manifesto, writings actually addressing how to implement its principles that don't amount to context-blind process, and related movements (Lean software development, etc.) and applied the ideas to improve teams and make software in a better way.

Most developers -- before and after the manifesto -- work in places where management is operated with shallow knowledge and poor respect for their staff and buying whatever consultants are selling in terms of process, sure, but that's not the fault of the Agile Manifesto

<comment><USER18> You do make some good points. Perhaps my frustration at the Agile Manifesto is misplaced. I'd still argue that the canned processes that emerged due to the creation of the Agile manifesto are amongst the worst ones available, but for sure I have no real proof for that other than my own personal experience.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER20> I still remain totally unconvinced that 'Agile' is broken, or has failed. I have worked in places that do FakeAgile, and places that do GoodAgile, and there are two conclusions:

1\. Bad companies and practices will not be magically fixed by applying 'Agile' or whatever other methodology you want. 2\. When companies do agile development well, it is effective at solving some of the worst problems that software development faces.

Apparently I'm in the minority for thinking that Scrum in particular is a pretty effective development methodology. I'll tell you what our process is.

\- Spend a couple of hours planning a sprint of work. Two weeks, in our case. During that planning meeting, look at the backlog of features and tickets that the product manager has built up. Identify tasks we can reasonably accomplish in that time frame, ensure we have enough information to start, and discuss each one so we have a clear idea of what it involves.

\- Make sure that those tasks are customer-visible features wherever possible. It's not always the case that this can be done, but it helps to provide feedback.

\- 10-minute daily stand-up to discuss any issues and communicate who's working on what. Also time for the product manager to feed back any information from outside the team.

\- Work on some tickets. Review the code. Pass them through QA. Deploy them. Let the product owner receive feedback from customers.

\- Review the sprint when it's done – take an hour, discuss what went well, what didn't go well, and anything we can improve.

That's the core of Scrum, and I don't see what's wrong with it. The problem arises when it's abused; story points as burndown charts, or productivity monitored in terms of 'number of tickets finished', or whole-company stand- ups, or whatever.

Agile development works well if you're agile. It's not a set of rules that _must be followed_ – it's a set of guidelines that can help to improve the development process. If you are performing useless, time-consuming overhead tasks, then you are not doing Agile – end of story.

<comment><USER21> _> That's the core of Scrum, and I don't see what's wrong with it._

Where does professional development come in, my true Scotsman?

<comment><USER22> From what I've seen, professional development in a scrum shop means moving from junior developer to people manager.

If you want to keep coding, you're expected to leave within two years.

<comment><USER21> Agreed (though maybe not "two years"), and that was what I was getting at. Scrum is not a system for investing in people--and _we need to do that_. It's a fairly exploitative mode of organization and this industry's largely uncritical adoption of it is something we don't look at particularly often or with much real gusto.

<comment><USER20> _Scrum is not a system for investing in people_

You're right – Scrum is a process framework for developing software.

That is _totally, absolutely, 100%_ orthogonal to professional development. I work in a mostly-Scrum environment as I described; that doesn't preclude research, or conference attendance, or any other form of professional development.

Bad culture is bad culture, regardless of development methodology.

<comment><USER22> What you're essentially telling your engineers is that A) doing their job has nothing to do with getting better at their job, and B) if they want to advance beyond the junior engineer level, they will have to do so on their own time. I've seen this referred to as "terminal juniority."

Having a development process that does not produce senior engineers is a problem, even if you try to make up for it by providing a conference attendance budget and a Safari books membership. At the very least, such a process unfairly penalizes those with large personal time commitments.

<comment><USER21> Fantastic post, and I agree. I've always been in a weird place professionally because I came out of school at a somewhat-above-junior level and so I've been in an interesting position to watch companies try to mold developers. There's that "five years of experience"/"one year of experience, five times" thing people sometimes refer to, and Scrum seems tailored to doing the latter.

Terminal juniority is an amazing term for that. Thanks.

<comment><USER22> Thanks, though I can't take credit for it. I stole it from an epic anti-agile jeremiad on Quora: [http://www.quora.com/Why-do-some-developers-at-strong- compan...](http://www.quora.com/Why-do-some-developers-at-strong-companies- like-Google-consider-Agile-development-to-be-nonsense/answer/Michael-O-Church)

<comment><USER21> Ha, it sounded familiar. I don't always agree with Michael but he's a great dude.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER23> Just a quick rant about SCRUM:

I have found that SCRUM is used to allow everyone in the company to believe that the development team is at maximum productivity. It encourages conservative estimation, low-ambition projects, and generally business- friendly, highly measurable pace (with metrics that don't really matter but sound good).

If you have to resort to SCRUM, your company is probably already toxic (or else the last company your VP of Engineering worked at was toxic).

When you don't have good product/market fit, everything the development team builds looks like a miss (because it is) even if the technology works very well. Thus, good product management is crucial.

In the greater scheme of things it matters very little if every single features ships two months late. The most important thing is that the product gets closer and closer to the product/market fit bullseye.

SCRUM insulates developers from managers who would constantly change their mind and thrash the team around willy nilly, but it also insulates developers from the realities of the business.

With good product management, everyone buys into the challenge of product market fit, and everyone wants to apply the right blend of qualitative and quantitative approaches to build the right thing at the right time. SCRUM is fine if everyone is already cynical and there is widespread mistrust, but if you want real team cohesion it's a bad idea.

<comment><USER24> I'd like to at least offer some support to this -- I'm not sure I agree with all of your conclusions but since switching to Scrum mentality I definitely notice that the goals of our team have become much less ambitious... Rather than insulating for development cycles that may not yield much for a few of months but in the end equals proper enterprise architecture, the business/devs have found it much easier to focus on small iterative tasks that are much more superficial in the grand scheme of things.

I think engineering processes benefit when they are insulated from direct scrutiny of timelines. Resorting to tackling smaller, neater issues in Agile seems to be a sign that there is a lack of technical leadership/vision. This is not necessarily the fault of Agile (I don't mind Agile, I think projects can succeed with it if approached properly), I simply agree that increasing process rigor seems to be a symptom of an engineering/mgmt team that is floundering.

In short, if your team's problem is that things are getting "messy" and "hectic" because of too much crappy copy/paste code, I have seen how Agile can just deepen that wound while masking it in a veil of "tangible progress" seen in burndown charts. Then, again, if you don't have the right people you don't have the right people. What else can you say?

<comment><USER25> I'm guessing if you're the kind of manager that sees progress in burndown charts you're already on the wrong course as it is.

</comment></comment></comment><comment><USER26> Almost every new idea in software development is having problems when facing "majority adoption" phase. Agile definitely is replacing waterfall now and there are so many people that capitalize on this trend and don't give a shit about agile roots and principles. Every new wave is eventually hiped and monetized. Agile is not an exception. It doesn't mean agile is bad, it just means agile went mainstream with all side effects.

I personally have a strong feeling that this article is just another attempt to monetize agile, by selling "agile failure". Agile is not failed for sure. Some people did.

<comment><USER27> Every new idea in management have problems at the "majority adoption" phase. Software is no exception.

Those problems appear because organizations are chaotic, in the mathematical sense, in that the sum of the details completely eclipses the worth of any idea. And that's an inherent problem.

</comment></comment><comment><USER28> The problem with agile development has always been Agile Development.

Cargo-cult management practices freely adopted the brand facade without embracing or even understanding the underlying principles that must be present before the branded process elements can be good practice.

I don't care how good your process consultants are. They are not going to convince any manager to reduce his own importance within the organization. Just like it is much more difficult to make software secure by waiting until version 2.0 to add it, it is harder to make an organization agile by patching that in after the startup phase. It is far easier to be born agile than to reorganize into it.

The failure comes when trying to convince a clumsy organization, with plenty of vested interest in remaining that way, to become agile. What you end up with is a racing stripe painted onto their t-shirts and shiny plastic spoilers taped onto their asses, and no real improvement.

So in this context, GROWS will also fail. The only way to stop it from happening is by the developers pushing back hard against any more brand-name processes that are uncritically peddled to any organization flush enough to pay a process consultant. Screw your new snake oil, buddy. My org listens to me barely enough right now, and I don't need anyone messing that up with some new kind of pointless meeting.

</comment><comment><USER29> I was on board with the article until he tried to sell me Agile 2.0. (an unproven and confusing iteration, to make matters worse. Dreyfus skill model? Nursing industry? I'll wait and see and hope someone else has some sort of success with this before considering it myself)

<comment><USER30> I half-expected this article to be an elaborate troll =/

<comment><USER31> It started good and I thought it would get even better by creating a imaginary new method (even with the "TM" sign) to make fun of the craziness it was complaining about. At the end I didn't know if it was a joke or not but, sadly, it looks it's no joke (to the authors, at least).

</comment></comment></comment><comment><USER24> my company is "totally agile" (they wish) and it gives the management layer something to do cuz they are analyzing JIRA all day coming up with horse-shit charts, so of course they keep pushing all of it like its solving high-level organizational issues in ways we will experience tangibly sometime by 2018...

if you got rid of all that process infrastructure and just had a few programmers discussing proper design patterns now & then our company would be lightyears ahead of where it is now. i think everything becomes cargo cult when you refocus technical people onto processes that discourage technicality to make management feel fuzzy about their stats. people aren't more productive now, they are just gaming the agile system

process planning has its place i just feel like its becoming the focal point of discussion rather than a means to it. bureaucracies will continue to grow, what can you do other than look for a job with a more technical group that is focused on code?

i'm a former academic, i was astronomically more productive in that setting and there were no real process restrictions imposed at all. people need to be cultured into code & self-education, not process. optimize process once there is a good technical core in place, not in lieu of one

(i've also noticed that fake agile just promotes a lack of requirements docs from business... in that case i'd be better off doing damn waterfall with a half-decent reqs doc anyway...)

<comment><USER32> Urgh Jira. Jira symbolizes the entire problem. Issue and task tracking where the actual issue and tasks are 3 layers deep from the main interface, and graphs and burn down charts are front and centre. It's all carefully architected to appeal and sell to the managers who buy it, rather then the dev's who use it.

Contrast to something like GitHub, where code is front and center, and issues are a flat list and which has no other BS cluttering it up. Why? Because GitHub _isn 't_ selling a product to managers first - it's selling to to dev's first (via getting them in on open source).

<comment><USER33> Jira has its moments, especially for larger teams. I've seen it used for large projects, and there GitHub Issues would be garbage.

You can ditch a lot of the cruft from Jira by making your own dashboard etc.

</comment></comment></comment><comment><USER34> In many martial arts there is the concept of 3 stages of learning that are roughly[1]:

1) Learn a bunch of rules and follow them by rote

2) Learn when to break the rules

3) Learn to make your own rules

Looking up the Dreyfus model of skill development mentioned in the article, there is a similar concept.

In martial arts, teaching at level #1 is easy; if person A knows a rule that person B doesn't, then person B can teach it to person A. Similarly one person can teach a large class of people a rule all at once. If you ever had a friend as a kid do a year of e.g. Karate and say "Grab my wrist... No, not that way, this way..." you've seen it taught at that level.

In martial arts, at least, learning above level 1 isn't really something that scales, nor is it something that will easily happen without a lot of self- motivation from the learner. There are, however, some traditions that are successful in aiding someone in the transition in a sort of mentorship relationship.

Such traditions aren't peculiar to martial arts though, as most crafts have ways of doing it. It would be interesting to know if modern behavioral sciences have found improvements, as the development of such traditions has always been ad-hoc informal and more of "this is how my mentor did it" rather than "we have good reason to think this way is best"

1: Here's an article on wikipedia about it; the martial-art I learned about this was not Japanese, nor Chinese, so it was somewhat different: [http://en.wikipedia.org/wiki/Shuhari](http://en.wikipedia.org/wiki/Shuhari)

</comment><comment><USER35> The essence of Agile and XP still stand tall

      - sit close to the customer (literally)
      - write good automated test coverage
      - release early and often and get feedback (see point 1)

If you are doing those three things, it's hard to totally fuck up. There is a lot of process in making those things happen to be sure, but how that process happens is not important.

the Agile Maifesto / Scrum tried to downplay process so much it became a by- word for no process, and almost broke the good it was doing as no one could track / report what was going on so every implementation looks like an uncontrolled mess.

(Yes there were sticky notes up on boards, but it's hard to mail that to upper management)

So a little more process, a lot more talking to end users and waaaaay more automated tests and automated releases and we might have something

<comment><USER36> Yes. Feedback!

Feedback from customers by iterating and releasing early and often.

Feedback from the team with proper frequent retrospectives.

Projects that I have been part of that skip or mangle retrospectives have all struggled. Listen to the team. Keep tweaking, improving every week/sprint. But keep the delta low so you can see what actually made an impact. And keep retrospective to mostly the team only so root causes are actually mentioned and not railroaded by external chiefs.

</comment></comment><comment><USER37> If we even look past the 15 years of Agile and into the 50+ years of big- business software development, looking at the differences between the organizations that succeed and the far, far more numerable organizations that fail[1], then I don't think we see any differences that come close to touching the technology or individual work habits of the employees. The differences we see are organizations who trust their employees to be experts, and organizations who try to manage top-down.

Centralized, authoritarian structures, whether for business or government, are where the "lack of agility" come from that the Agile Manifesto spoke against. Creating a new set of rules called "Agile" that such a centralized authority can impose on its underlings doesn't change that.

[1] by some metric, either by time or budget or employee health and retention, which is really just a failure of budget that has been paid for in a way that doesn't show up on the accounting sheets.

</comment><comment><USER38> Like most people, I've had mixed experiences with agile. I like short regular meetings where I hear what people are doing - but not for process reasons - it's just nice to hear. The places I've worked fit comfortably into one of two categories.

In smaller shops, developers circumvent the process (whatever it is) when it makes sense. Things are messy, but it's not so bad. Hard to say how much process helps there.

In larger shops, the process has won and people just work around it. Developers still try to get around the bad parts, but The Process is stronger than any individual. Work seems to get done less, but everyone understands why the work didn't happen. Generally, I get to go home earlier in these kinds of environments.

All that said, a co-worker recently said they were excited to get more into agile and linked a product that uses this chart to advertise their agile tracking software: [http://i.imgur.com/uYZwtFY.png](http://i.imgur.com/uYZwtFY.png) . I cannot for the life of me figure out how we got from "people over process" to that monstrosity.

</comment><comment><USER39> Ignoring the article for a moment. I think one of the problems with agile-in- the-wild is that people who try to use it think in binary terms. In the original manifesto, the idea put forth pretty clearly is about rebalancing the way things are done -- not doing one thing instead of the other.

For example, it's not "Working software _instead of_ documentation" it's "Working software over comprehensive documentation".

Agile should be a philosophy about development, not a set of rules.

To make matters worse, Agile-as-a-product (with Seminars, and Books and whatever) seems to only amplify this. I've had scrum masters tell me very directly that "the proper agile procedure for such and such is..." or things very similar.

It doesn't mean you don't have tools or process or contracts or whatever...and it's frustrating that most people don't seem to get that.

</comment><comment><USER40> Agile is a very useful product.. for a certain target market.

The problem is that the target market isn't developers, and the product isn't improved productivity.

The target is middle management, and the product is risk management. Or more accurately, perceived risk management -- it doesn't really matter if it works, the narrative of "being agile" is more important because that narrative can be sold outside the group with all sorts of fancy charts showing just how well managed things are.

That sounds cynical, but in a lot of ways it can be a good thing. Some fictions really do have a utility. For instance, by creating measurables (story points, etc), even if those measurable metrics are largely fictitious, it can give a group credibility that will prevent interference from outside stakeholders, and it can calm upper management that would otherwise be antsy.

</comment><comment><USER41> There's an interesting discussion on [http://www.reddit.com/r/programming/comments/354aze/the_fail...](http://www.reddit.com/r/programming/comments/354aze/the_failure_of_agile/)

</comment><comment><USER42> This _has_ to be a really late April Fools' joke. There is no way in hell they could seriously be trying to pitch a "basically-new-agile-methodology" that is this buzzword laden. I mean, the (TM) on the name?? Come on...

<comment><USER19> Trademarking the name may be a way to prevent GROWS from being hijacked the way Agile has been. The reference to the Dreyfus model makes me suspect that (aside from rebooting to bypass the way Agile has been coopted) this may be an attempt to put some concrete guidance into the metamethodology of developing process in an Agile (in the Manifesto sense) organization, which was always a fairly big gap in the Agile literature, which tended to be largely principles plus the specific processes used by specific organization, without covering how the _agility_ actually should work (though, if you got outside of the Agile brand into works on Lean, which is pretty much the same set of principles arrived at from a basis that has much stronger process engineering background, and so tends to feature a lot more work on concrete methods of process evaluation, there was quite a bit of that.)

</comment></comment><comment><USER43> I recently wrote an answer to a question on Quora about Agile.

[http://www.quora.com/Why-do-some-developers-at-strong- compan...](http://www.quora.com/Why-do-some-developers-at-strong-companies- like-Google-consider-Agile-development-to-be-nonsense/answer/Rajaraman- Raghuraman)

To summarize my answers as to why developers have started hating Agile?

1\. Most organizations have a wrong understanding/implementation of Agile. 2\. People especially at the management/leadership levels think that if a team follows Scrum, they are Agile. 3\. There is an entire industry which is trying to over exaggerate/misguide the Agile movement and make money out of it. 4\. The troubled understanding that Agile is a One Size Fits All kinda thing. 5\. Being in a Fixed Mindset (Anti-Agile). 6\. Some teams are already Agile. And for them, Scrum should not be forced. 7\. Scrum by definition doesn't give a damn to the seniority of engineers. Because everyone is a Scrum Team Member. 8\. Impediments are not removed. Or worse new impediments crop up when implementing Agile in a bad fashion. 9\. Scrum by definition doesn't care about flow state of a programmer.

And the essence of the article that I have just read is that there is gonnna be a competitor for Scrum and it is called GROWS.. Wow.. Let's see what happens next.

And as someone rightly pointed out, as long as there is corporatism which tries to implement Agile, there will be lot of failures. So in a nutshell, it is not the failure of Agile, but the failure of people who didn't understand Agile properly.

</comment><comment><USER44> Agile only seems to be useful if you have prior exposure to the Waterfall model, people who start off with Agile as their first software development methodology tend to parse 'agile' as 'license to freely use bad practices'. I've seen this often enough to a point, at times I think the older waterfall model would work a lot better for a lot of shops.

Back in the day people would do a good deal of paper work as a part of requirements gathering, this would iron out a lot of clarification and specify clear definitions of what people wanted to do. These days 'define as you code', often leads to getting requirements in piece meal, often adhoc with no broader sense of design and what follows is endless refactoring. Delayed projects, and rewrites.

One more damage agile is causing to the Google generation of programmers is destroying skills related to reading and writing documentation. In a urge to do everything in a hurry, we end up doing more damage than good.

And agile never quite really got rid of beaucracratic rituals of the waterfall model, they just got re invented into their new forms.

</comment><comment><USER45> The Agile Manifesto has a lot of good ideas and was motivated by real world problems and how they were solved. The problem is like many other good ideas is that they evaporate in a cultural vacuum. Agile methods like Scrum and XP are based on the thought that introducing some rules can overcome culture.

What happens in practice is that culture subverts those rules in order to reinforce itself.

Resistance to change is a stronger force than any buzzword methodology or profound observations. This is further confounded by the very nature of software development as something that can't be distilled into a set of rules. Different situations require different approaches.

Is all lost? I don't think so. Agile has contributed to the way people think about software development and gives the right team in the right culture more tools they can use in the right situations. It's not going to "fix" software development in general though.

</comment><comment><USER46> If GROWS became popular, it would also be 'sloganized', branded and ruined. People would go to one-day intensive GROWS courses, get certified and then just do waterfall anyway - exactly what's happened to Scrum and everything else.

I find it slightly ironic that they (correctly) say they are no silver bullets, then suggest a silver bullet.

<comment><USER47> I don't know anyone who just does waterfall anyway except for simple projects. You just can't get all you architecture and design done up front. There is a lot of iteration between architecture, design and coding. Requirements change and things need to adapt. That is not waterfall.

<comment><USER48> Lots of places do agile-washed waterfall.

They're mostly places that look for a methodology-in-a-box type solutions.

</comment></comment></comment><comment><USER49> I think that I left software development just as these schemes where becoming en vogue.

Being on the outside of the industry and reading about all of these acronyms of "how to succeed with great apes" ... it reminds me of being in middle school band. It smells like how first chair worked to get all of us clarinets to practice more and to try to out do each other performance-wise.

It works.

But eventually it changes from first chair to "first chair". And then it became, iirc, a lighting-rod for interpersonal problems amongst the single- reeds that became disruptive.

I suppose that I think of these schemes as MBA-encoded first chair politics. They work while the meta-game is immature. But as soon as players get to see the carrot for what it is ... it is all about a competition for who gets to hold the stick.

<comment><USER50> It's funny - as a former French Horn player, the second horns get all the good parts...

I've been political, I have been apolitical, I've been places where there were no politics. In the end, it's all the same.

</comment></comment><comment><USER51> Agile is great, for many reasons. Not least but including:

Having loads and loads of meetings. Like teaching people to build a car or town with Lego using an Agile methodology. Instead of letting them do it themselves, it was a game-changer on memories of Lego as a kid, the impact was like coming off a waterfall, no, even being in a waterfall.

Improving meetings by doing them standing up with a whiteboards instead of a meeting room glassboard. Not only freeing up precious meeting room space for those teams doing scrums with remote teams that also do stand-up whiteboard scrums on their own, our white boards cost leading to less wear-and-tear, scrums tend to last for 30-60 minutes, improving everyone's cardiovascular system, and we can do them at any time of the day whenever the team lead decides a scrum should be done, damn everyone's productivity, it is all about the scrum and helping everyone get things done. My team lead says Agile is a better method for managing things.

Overtime is now referred to as a 'sprint' when we realize we're behind deadline, but can enjoy the process of sprinting every 2 weeks. We have replaced the boring, planned methodology of milestones and working overtime to fix what we hadn't planned by sprints, where we do overtime on a systematically planned 2-times-per-month basis, and everyone is happy because of the 'focus time' whenever we're not scrumming, and free taxi home at night. We also work shift 2 days per week because that totally helps sleep patterns. Enjoy the early morning and late evening at least twice per month.

If the sprint doesn't work, we just push things to the next release. It seems to keep everyone happy.

Agile tools are so flexible we have to make our own, as our organization is so paranoid and locked-down regarding information security we cannot use anything that doesn't go through an approval chain so many miles long it literally virtually circles the earth several times over. So we resist this, and dedicate 1/4 of all of our resources to beating these out-of-date systems at their own game. A guy said he could do the whole 300 person project in Excel, but we thought maintaining a staff Name-ID-email-telephone table would not totally not work, and kept the 300 people making this system Agile instead, we're just using a single API, after all. Agile is all about the team.

Even our bathroom staff are Agile. When the GM leaves in the evening, all tissue paper is removed from the bathroom, promptly. It is replaced when he returns in the morning. That is keeping a tight, ship.

*All the above is true, if somewhat hastily typed.

</comment><comment><USER52> The Agile manifesto was originally written, from what I understand, by people who actually understood software.

I just don't understand what logic brought us to this place where it's not seen as weird that someone wholly non-technical and unfamiliar with software can be a manager of a software team (or run a software company, for that matter).

I'm not arguing that software is somehow 'special' either - I'd make the same argument if say, for example, someone wholly unfamiliar with steel fabrication was acting as a factory foreman. Or if me, as a software guy, decided to just one day declare that I'm qualified to successfully manage a farm.

I feel like this is a big part of the problem. Not the whole problem, but a big ccontributor.

<comment><USER19> > I just don't understand what logic brought us to this place where it's not > seen as weird that someone wholly non-technical and unfamiliar with software > can be a manager of a software team (or run a software company, for that > matter).

"Brought us to this place"? We've always been in that place. In the last few decades, we might have started inching _away_ from it a little bit, we certainly haven't recently arrived at it.

The idea that leadership of an technical organization should be skilled technicians (at least up to the point in the organization where there is a distinctly technical organization) is something that has _never_ been the dominant wisdom in business ("management" as a distinct and transferrable skill set has been more dominant.)

Certainly Lean Software Development (and its direct predecessor in Lean Manufacturing and some of the other things that fed into Lean Manufacturing) tend to hold the position that leadership in a technical organization should be technical, but while that Lean has become powerful in some areas of manufacturing, its never been dominant in software development or business generally.

</comment></comment><comment><USER53> I feel like someone should develop and market the "I Ching" and the "Tao te Ching" as a development methodology. It could attain the same cultural position that "The Art of War" enjoys in business.

> Chapter 54

> That which is well established cannot be uprooted

> That which is strongly held cannot be taken

> The descendants will commemorate it forever

Here, the classic teaches us that strong coupling incurs technical debt which limits the future of the application. Just because we've always done it this way, doesn't mean you must rigidly follow bad methodology.

Plus, the inclusion of I Ching divination provides a built in means of making easy decisions and resolving conflicts.

</comment><comment><USER54> agile per se is good -- making it a religious is ususally bad;

I saw many companies using scrum and often I felt like this is a process for slower moving teams, instead of the opposite;

Great software is being written by great individuals that move it forward, pretty indecent of whatever process a company tries to use. To me a process must not get in the way or productivity and creativity.

</comment><comment><USER55> The problem with Agile is that it's political; it gives programmers lots of power because it allows them to control the scope of the project and it gives the more access to the client/customer/business analyst/user. It also lets them argue for improving quality through test-driven development and pair programming.

When you have a manager, a marketing department, you have multiple points of power where the manager(s) come first and try to control everything. Giving up that control is difficult to do. When you have a marketing department, they assume they know what is best for the user and what features the user needs and at what time (all the features done by day X). The developer ends up being a code monkey who's hired to implement exactly what some MBA (or even worse, non-MBA!) wants. It doesn't even matter if users hate; it doesn't matter how slow it is, as long as it meets the whims of the managers in charge.

With Agile, you get rid of the bureaucracy and you make the feedback cycle faster and you have quality built-in. You don't really need marketing or a manager calling the shots because you can go to the customer directly (or through the customer proxy who also is with your agile team every single day). You've effectively removed one or two jobs or at least reduced them to part- time work; that's very dangerous in a hierarchy.

Programmers are low status; when we're high status we can have Agile and we can influence the work we do.

</comment><comment><USER56> Process is valuable, but too often people fall into the trap of trying to trust everything to process. Which will never work. A process is like a little code snippet. The best processes involve heuristics which complement the experience and judgment of human beings in the loop. Otherwise you just get a kafkaesque nightmare.

Agile has some special additional problems, including a misleading sense of detail, a tendency towards short-sightedness, and misplaced credit for success on the process. Having a ton of "artifacts" or stats doesn't mean you have the _right_ data, or even enough data, but if you have a lot of interesting data you tend to fall into the trap of believing you know everything. Agile's short planning windows often means that you don't get proper credit for long, drawn out work and planning very far ahead. This is actually intentional, as Agile/SCRUM have been designed to get productivity out of unproductive and dysfunctional teams, but sometimes you need more than just stumbling along. Also, because Agile has a lot of detail to it people tend to give it credit for successes due to the post hoc fallacy (e.g. "we did Agile, and then we shipped a great product, yay Agile!").

</comment><comment><USER57> I think the conclusion is telling:

> And finally, whatever we attempt here has to work for the whole system, not > just the developers, not just the managers, not just the testers, not just > the users, not just the sponsors. There is no "us" versus "them." There is > only us.

The goal in all these methodologies is to get everybody so perfectly aligned, they'll naturally zero in on The Right Thing.

But the people who are really in charge have no intention of ever letting this happen. It doesn't matter what the methodology is.

People try to apply Agile or whatever in the modern American corporate environment, which is a seething pit of fear and mistrust with no job security. So everyone wants harder guarantees. Brighter lines, that show if they've done their job well or not.

So despite their best intentions, there are strong incentives to _maintain_ all the anti-agility boundaries, in order that blame and credit flow to the appropriate people. If there was a truly Agile product that succeeded, who is to be rewarded? It's hard to say. If it failed, who is to be blamed? Everybody? Nobody?

This isn't short-sightedness -- this is purely rational. This is why you get "Agile"... plus hard requirements docs... hammered out in advance... and a waterfall schedule.

</comment><comment><USER58> The problem with agile is that it requires a completely different way to think about productivity and company finances not just in the team but the entire connected reality of a project.

Agile solves a conceptual issue which is it creates a more effective feedback loop that keeps everyone more informed than they used to be with classic waterfall models.

The problem though is that the financial reality isn't following the logic of the agile model and so whether you are trying to use the agile model for customer projects or internally in your organization you are still a child of the the overarching financial reality which dictates how companies are measured and budgets created.

Agile is great for innovation where there is no deadline and no limited budgets. It creates a false sense of effectiveness when it comes to projects with deadlines and budgets.

At the end of the day all it does is allow you to say earlier to those you have to deliver to that they aren't going to get everything they asked for at the same price as what they thought they were getting.

<comment><USER59> > "Agile is great for innovation where there is no deadline and no limited > budgets"

that rings very true with me. I'm nearing the end of a 3 year project where scrum was prescribed and followed, but the truth is we've basically shoehorned agile practices into a waterfall model because of business needs.

My experience with agile projects is probably far removed from how it should be implemented, but it still feels like it's fundamentally flawed to address business needs which rely on fixed scope and accurate estimates from the start of the project succeed (e.g. critical 3rd party tools being end-of-lifed, product mandates beyond company control, renewing client licenses based on feature completion).

I guess until something better comes along, I'm stuck with being told to do some strange type of scrumfall/water-gile.

</comment></comment><comment><USER60> Even Dave Thomas (another original signatory) has admitted there are serious problems with the way agile is generally practiced.

[http://www.drdobbs.com/architecture-and-design/dave- thomas-i...](http://www.drdobbs.com/architecture-and-design/dave-thomas- interview-the-corruption-of/240166688)

<comment><USER6> Yeah Dave Thomas has written about it here too [http://pragdave.me/blog/2014/03/04/time-to-kill- agile/](http://pragdave.me/blog/2014/03/04/time-to-kill-agile/) and also Mike Cohn one of the developers of scrum has criticised blindly following methodologies (which is sort of related) [http://www.mountaingoatsoftware.com/blog/dont-blindly- follow](http://www.mountaingoatsoftware.com/blog/dont-blindly-follow)

<comment><USER60> I think the fault was that they focused more on codifying approaches to deal with specific problems rather than discussing the problems they address, and encouraging people to recognize those rather than take a specific approach.

The manifesto was nearly a ten commandments of software development.

</comment></comment></comment><comment><USER61> Agile as practiced by the industry is nothing more than a way for dysfunctional businesses to punish their developers.

</comment><comment><USER62> Over on [http://growsmethod.com/](http://growsmethod.com/), when you sign up for the mailing list, the page confirming your subscription is loading in mixed content (JS!). I'm suddenly not inspired.

That said, I don't see the point of "methods", agile, waterfall or otherwise. When I worked building SaaS for school districts, we shipped roughly once a month, so I guess that was waterfall, but some ideas we iterated multiple times within that ship period until we liked one. Now I work with a set of e-commerce websites, and nothing front-end isn't AB tested (which slows down shipping anything), and new backend functionality is iterated almost daily. But I've never called these methods anything other than the right approach based on the situation.

</comment><comment><USER63> The proposed solution feels good and all but in my experience it would be almost impossible to adopt for most companies operating in VC-istan.

The most extreme case I can think of was a "startup" I worked at that was VC'd to the gills, had an impressive board, with no traction, no revenue and about 25 engineers on staff. What they did was what I liked to call "product development by whim" where they had 5 product managers which each got to decide which features they wanted and the devs went and built it (we really really really needed a way for our non existent users to invite their friends via email, etc).

So if we needed evidence before development the whole house of cards would come falling down because the evidence would have shown no one wanted what we were selling, period.

</comment><comment><USER64> The reason that BigCo never does capital-A Agile is that their release dates are fixed months ahead of time (to coordinate across the organization), and they want to know what they'll actually be shipping in 6 months (again, to coordinate across the org). This makes the biggest two selling points of Agile - continuous release and rapid change - completely worthless.

The only model I've actually seen in a large organization is for the dev team to throw together a barely-working prototype, then spend the next 6 months fixing all its problems while the Marketing, Sales, and Customer Service departments train up on the new software. And they'll find a way to call this "agile", because otherwise the developers will revolt.

</comment><comment><USER65> Is it April 1? Andy poo-talks Agile and then drops GROWS (TM) on us? You have got to be kidding me.

It's been mentioned on here a lot that if you have a skilled set of programmers on your team you probably don't need Agile. They are self-managed and tend to do the Right Thing (TM) on their own.

I have seen Agile work and when it does it's pretty fun. Things move along, issues are dealt with, and nobody panics when things get behind a little. Just move it to the next release.

I think the problem is that The Consultants sold Agile to enterprise dev shops and they really ate it up. I don't feel Agile works from the top-down but rather organically from the bottom-up. In fact I believe that is true for most programming methodologies like this.

And Scrum. Don't get me started on Scrum.

<comment><USER26> > if you have a skilled set of programmers on your team you probably don't > need Agile

This. Craft and passion beat any process. These people will organize themselves into the most efficient process eventually.

<comment><USER20> _This. Craft and passion beat any process. These people will organize themselves into the most efficient process eventually._

My direct experience of working with programmers over the years is that this will generally descend rapidly into an inefficient mess. Yes – maybe it works, sometimes. I'd argue that's the exception, rather than the rule.

<comment><USER66> [http://manifesto.softwarecraftsmanship.org/](http://manifesto.softwarecraftsmanship.org/)

If you work with people who dont care, youre screwed. Nothing will ever work to force them to actively engage with the process of creating good software.

..but, surprisingly, when you _do_ work with people who _do_ care, they self organize remarkably well. The Valve megacorporation is fundamentally based on this. It works. Thats been _my_ personal experience, over the years.

The problem that has to be addressed is convincing people to care, and self improve.

Forcing a process on the unwilling is going to fail no matter what you do.

<comment><USER20> I agree that a group of people who don't care will almost always produce substandard results.

I don't agree that people who do care necessarily self-organise well, or that this self-organisation is compatible with other business goals.

Sometimes it works, and a group of engineers et al. do a good job of forming a coherent team with minimal process. Valve's maybe an example – I don't know. My experience is that this is the exception, rather than the common case.

A good process can provide tools that help good people who care communicate and deliver more effectively. They help us to keep track of how we're performing and analyse pain points, and to make sure that there are methods for dealing with common problems.

For example, if my team felt that daily stand-ups were an inconvenience that weren't helpful, then we wouldn't do them. That's the goal; there's no cast- iron set of rules, just a generally applicable set of principles to follow.

<comment><USER67> Some kicks in the assets and firing bad apples also go a long way in keeping the team focused.

Some people are self motivated and other needs their slap in the morning (for some, that's a couple of times daily).

<comment><USER68> You know, I probably don't know as much as you do, but every time I've ever seen lots of negative reinforcement get applied to teams both in software and outside, it seems to have the opposite effect. Sometimes you have to quietly handle the most toxic people, but on the whole, when you take this sort of approach to managing, I would be very surprised if you only make the situation drastically worse in the long run.

</comment></comment></comment></comment></comment></comment></comment><comment><USER69> It really, apparently, isn't a joke: [https://twitter.com/growsmethod/status/596404929679458304](https://twitter.com/growsmethod/status/596404929679458304)

</comment><comment><USER70> I've found Agile to be a collection of useful tools, but just like "opinionated" framework, it's only perfect for solving the author's problems. In my experience, agile works better for web apps than native mobile apps.

What worries me is toxic dogma. Too many Agile people say:

* "Agile failed? They weren't practicing it correctly!" a.k.a. the "No True Scotsman" fallacy * "You have to choose between Waterfall and Agile" a.k.a. the "Black and White" fallacy.

I realize that not all agile people are like this, but there are enough vocal members of the community that it reminds me of religious fundamentalism.

</comment><comment><USER61> I've seen Agile work, except it wasn't called Agile, and it was before Agile existed.

At a small game studio, you may have one guy that knows the hardware really well at a low level, but not the engine or how it's used, but the engine developer does. When you put these two guys in a room together, they will crank out something beautiful in an amazing amount of time, something neither of them could have accomplished alone.

That's agile. Not whatever crap the current mantra is. The manifesto gets this, but it never should have been made into a process.

</comment><comment><USER71> A key thing not mentioned in the article or the comments, is that agile only works for certain _kinds_ of software (when the software category is still being custom built).

For others (when the software category has become a commodity), waterfall methods like six sigma are better.

Simon Wardley is great on this:

[http://blog.gardeviance.org/2014/07/agile-agile- everywhere.h...](http://blog.gardeviance.org/2014/07/agile-agile- everywhere.html)

</comment><comment><USER72> Agile fails at most companies because they fail to understand that Agile is a culture not a process. Take the first statement of the manifesto, to allow the individuals to interact you have devolve responsibility down to the level where individuals can make decisions without having to run it up the ladder.

This scares the crap out of alpha executives and so they throw process and tools to ensure that the individuals interact in the "correct" way defeating the whole effort.

<comment><USER73> You're describing this:

[http://www.halfarsedagilemanifesto.org/](http://www.halfarsedagilemanifesto.org/)

</comment></comment><comment><USER74> > GROWS in this case is an acronym, for GRowing Real-World Oriented Working > Systems

Why emphasize the R in GRowing when the R for GROWS could have been taken from "Real-world"?

</comment><comment><USER75> Uh oh, The Client is figuring out that Agile isn't a silver bullet for building great software... Time to turn the crank..

Get your team GROWS™ certified today!

</comment><comment><USER76> It looks like all sw development processes try to guarantee budget by taming "unanticipated change". Unfortunately this can't be planned or taken into account early enough, by the definition of "unanticipated". Some processes are better in avoiding collateral damages when trying to restore the budget than others, but at the end of the day, we have a change in our hands.

</comment><comment><USER77> People can call these things whatever they like: there is a difference between passion and indifference that cannot be overcome by any process.

</comment><comment><USER78> "Agile methods ask practitioners to think, and frankly, that's a hard sell."

Wonderful point, and spot-on. But that's not just for agile newbies, I'd extend that to other groups that are immersed in something. The best example I can think of at the moment are MBAs. For whatever reason, smart people go off to charm school, earn their MBA, and then forget how to think.

</comment><comment><USER48> I've been at one place where agile/scrum worked. None of us were superstar 10x developers. What made it work was that we had a lot of trust between the developers and management. And that we knew the code-base well enough to be able to give accurate estimates (low turnover is good that way).

</comment><comment><USER79> It sounds like Andy Hunt has finally discovered ISO 9000. Plan. Implement. Measure. Review. Improve.

The pattern I keep seeing is the IT community's need to re-invent the wheel and give it names like 'agile', 'scrum', etc. Why can't people call a wheel a wheel?

</comment><comment><USER80> It appears this is less about agile and more about some new... thing... called GROWS:

[http://growsmethod.com/](http://growsmethod.com/)

I can't figure out what it is, though. Then again, I never figured out what agile is either.

</comment><comment><USER81> Relevant talk by 'Uncle Bob' about how Scrum became what it is now, as opposed to what it was intended to be:

[https://www.youtube.com/watch?v=hG4LH6P8Syk](https://www.youtube.com/watch?v=hG4LH6P8Syk)

</comment><comment><USER82> I think methodologies in general don't work as they are basically someone's reflection on some process (ex. Lean Startup by Eric Ries), an attempt to generalize one's experience that isn't widely applicable by construction.

</comment><comment><USER13> The new agile manifesto:

1\. You're doing agile wrong.

2\. If you pay me I can make it so you're doing agile right.

</comment><comment><USER83> Is a "new Agile" really what will solve this problem? I think really this just isn't a priority for many employers. Maybe we just need something new so us employees can see who's paying attention and flock there?

</comment><comment><USER84> Relevant : [http://pragdave.me/blog/2014/03/04/time-to-kill- agile/](http://pragdave.me/blog/2014/03/04/time-to-kill-agile/)

</comment><comment><USER85> Agile cannot fail. People fail. People will fail at whatever process or method for various reasons. At least Agile methods embrace failure and demand adaption or change in order to become successful again.

<comment><USER86> > _Agile cannot fail. People fail._

a.k.a self immunization

</comment></comment><comment><USER87> while we're in this discussion, is there any good hosted agile/scrum tool? (note: asana doesn't seem to count, it's too flexible, like a glorified todo app).

if there isn't any, i'd take this as an opportunity to develop one (i recently acquired agile.id and scrum.id domain, otherwise i'll just sell the domains).

...or maybe because their mantra "people over process" so the practitioners never feel the need of management software?

</comment><comment><USER88> process is often the symptom of tight coupling.

<comment><USER89> That sounds really strange to me, to the point that I'm not sure if you are being sarcastic.

<comment><USER27> Sarcastic or not, it's true.

I mean, it's completely tautological; conveys no useful information, and must be fully understood before acting over it in any way.

It's also funny. I'm upvoting :)

</comment></comment></comment><comment><USER90> "Agile process" is an oxymoron. Agile hasn't failed, process has.

</comment><comment><USER69> GROWS (TM) sounds like another Scrum instead of being another Agile.

</comment><comment><USER91> If any of you would like to learn more about GROWS™, I have started a GROWS™ consultancy, and I am also offering a GROWS™ certification process. My GROWS™ stands for God-awful Regurgitation Of Weak-ass Snakeoil. These seem like important concepts.

</comment><comment><USER92> Any discussion about agile invariably yields the predictable flurry of personal hangups and misrepresentations.

Most common of all, though, are the claims that if you just have a great team full of great developers, you don't need a process. Agile and waterfall both be damned.

But most teams aren't great. Most of the teams of people participating on HN statistically aren't great. But those teams still need to develop something -- banks and big cos and countless firms are churning out code by the millions of lines, by millions of completely average developers -- and agile is an honest conclusion that the classic method of software development doesn't work, most critically by biting off work in such enormous chunks that implementation or design issues -- the fit to the problem -- aren't discovered until enormous efforts have been wasted.

So talk about how agile failed, in your estimation, at some shop or another. But the truth is that almost anything would be a "failure" versus the idealized notion of a perfect design built expertly by great developers. Agile is trying to make the best of a normal situation.

<comment><USER93> None of the people who complain about agile offer any viable alternatives. I get the impression that these are developers who simply hate being managed period, and would prefer that management never spoke to them at all.

<comment><USER94> I certainly wouldn't mind if the middle manager that had an hour long meeting today never spoke to me again. The first slide was MLK with "I have a dream" which then continued onwards with 15 minutes talking about how to move post-it stickers on a whiteboard and 15 minutes spent doing a failed analogy between a GPS and continuous reevaluation of when the next release will be done.

At the same time, management has decided to have a release cycle that is 10 months (or in reality after the inevitable delays: 12)..

</comment></comment></comment><comment><USER95> the thing that often gets lost in these discussions is that a software development process is mainly a method of communicating state to management. management does need to know, despite developer complaints, because company resources need to be allocated and tracked.

if developers can't figure how to let management get the information they need, then management will impose whatever they think is best, even if they have no particular way of figuring that out.

the failure of agile is mainly a breakdown in this communication. the process itself works if it is followed, just as lighter and heavier processes can work. are they optimal? probably not, but communication amongst teams is a fairly difficult problem to optimize and it's likely to not have any one solution.

</comment><comment><USER96> I've worked at over a dozen places claiming to be agile to some degree, shape, or form, and have yet to see a process that's even remotely close, let alone agile. The failure of agile isn't that it takes time to learn and practice correctly or that it's too rigid. Its main failure is an inability to communicate its purpose to its users effectively. Agile is a good process in theory, but it seems the original creators did not anticipate the people that would try to put it into place and their agendas.

Agile goes against the mandates of almost all corporate culture in that it requires one to get out of the estimates as deadline mindset that rules corporate development. Agile tries to be flexible because that's the only rational option when developing software. When faced with irrationality, however, agile just becomes another justification for deadlines, time-wasting meetings (standup and otherwise), and other nonsense that leads to a productivity plunge everywhere I've seen it implemented.

This corporate culture based around deadlines and subservience of engineers is something that cannot simply be defeated with a methodology, especially when that methodology is, at best, only partially adopted. I will go as far to say that there is no methodology that can change this mindset. Regardless of what the author thinks, corporations and their managers will simply not allow something that will disrupt their world views and opinions.

While agile was trying to solve the problem of waterfall design--which is not always a problem and sometimes the best process--many corporate schmucks (both in management and engineering, both at giant companies and startups) saw it as a way to eliminate the design stage altogether. What great software has resulted! While agile was pushing for quicker iteration and release cycles so that code and features doesn't pile up and prevent / delay / disrupt the release, many corporate schmucks (managers only in this case) decided to use it as a justification for working their engineers overtime so they could push the features they "promised" out live by the release date.

There are few things in this industry that have wasted as much time as the doomed implementation of agile. Many have gotten rich off of it, but it has provided little to no value. The idea that processes can be malleable and flexible that the author advances is just pure insanity. It may work with a group of hackers cranking something out, but something like that will especially be discarded or twisted into something dark by management.

This idea, that a perfectly good process can be turned against itself is what the author does not understand and why his new process will likely fail in the same, dangerous way (should it gain acceptance and adoption), wreaking havoc on the engineers and managers it was supposed to help.

</comment><comment><USER97> Agile glorifies treading water, which will sometimes save your life, but won't get you anywhere. The problem is that it discourages actually swimming, and people forget how.

To explain: where this sort of project management actually works is in a short-term, time-limited crisis that large companies might call a "Code Red" or (in the original meaning of the word) a Scrum. See my Quora post on the topic: [http://www.quora.com/Why-do-some-developers-at-strong- compan...](http://www.quora.com/Why-do-some-developers-at-strong-companies- like-Google-consider-Agile-development-to-be-nonsense/answer/Michael-O-Church)

When you're a small web consultancy that has landed a make-or-break project that (say) must be delivered inside of 4 weeks, and when you have absolutely no leverage and must accept any changes in scope as they come, Agile can work. You can reasonably expect people to set aside their long-term goals (career progress, tech debt reduction) and solve the problem at hand. Moreover, when you're a big company fighting a Code Red (meaning, money is being lost right now in large amounts) and have to assemble a cross-cutting do-nothing-else- for-now team with no clear manager, Scrum can actually make sense.

In a true sprint-- a short-term reorganization necessary to solve an immediate problem-- unsustainable effort is OK because, well, no one's going to be expected to sustain it. You're under a short term emergency. You can ignore whether the assigned work helps peoples' careers, because they're not going to be doing it for long. You can mandate that people work on the "official" top priority (of which there's only one) and most people will do so.

The problem is the perma-Scrum that's been sold (dishonestly) by the Agile industry. This stuff works for a few weeks and people don't mind doing it. In fact, even if the work itself is painful and the hours are bad and status updates are (by necessity) frequently demanded, being tapped for the "elite emergency team" is something that people generally like and, over a span of 2 to 6 weeks, it gets results. However, when you have permanent "sprinting" and frequent status meetings or impose these rules over the whole organization, it starts to hurt morale. It starts to feel less like being on an elite emergency team and more like a culture of permanent juniority/micromanagement... which is what Scrum/Agile has become in many organizations.

<comment><USER98> You're saying that Scrum and Agile promote long hours? What does "sprinting" mean?

<comment><USER97> Long hours are just one variety of unsustainable practice. Accumulation of technical debt, and an absence of concern for individuals' career needs and goals, are likewise acceptable in the context of a short-term emergency but not sustainable.

In perma-Scrum terminology, though, the end of one sprint leads straight into the next. This is the core problem with Agile/Scrum as it's sold: it takes behaviors that are known to be unsustainable and encourages people to carry them permanently, and then says they're not doing them right (No True Scrumsmen) if the arrangement deteriorates. It can't be sold truthfully, as a short-term fix that does a lot of damage if it stays in place for too long-- no one would buy it if it were advertised as something that only works for 6 weeks, max, out of a given year-- so the Agilemongers present it as a permanent arrangement.

<comment><USER98> I think you are confused. A "sprint" is not "crunch". Its not a period where we work our asses off, late hours, weekends etc. A sprint is just a period of time. For us its two, forty hour weeks. Its sustainable and we've been doing it for 16 months.

It leads to a very confusing situation, where on the one hand the team is lauded for being the most productive team in the company, and on the other, for not working hard enough. o_0

If you can find anything in any Scrum publication that says otherwise then you can make the No True Scotsman claim, but otherwise you are at best misinformed.</comment></comment></comment></comment>


Basics of probability and statistics - <AUTHOR> http://videolectures.net/bootcamp07_keller_bss/

<comment><USER2> It's a nice presentation, although IMO there are better introductory talks, even on the same site.

What's funny about this one though is that over half of the comments say "she's cute" or something similar, it's a bit creepy.

<comment><USER3> You never hear women described as creepy for saying "he's cute" or something similar.

<comment><USER4> On the other hand, you usually don't see a majority of comments on male presenters saying "he's cute".

<comment><USER5> Not that I disagree with you. But HN is not sufficiently female dominated for such a thing to conceivably happen :)

</comment></comment></comment></comment><comment><USER6> As per the guidelines, it's polite to put "[video]" in the title if it's a self-starting video. I had 25 tabs open when suddenly the machine started talking to me and I had to work out which tab it was to stop it.

<comment><USER7> While I do agree that a [video] tag would've been nice, I'll also recommend you get FlashBlock for whatever browser you're using.

(Sorry for blatant OT)

</comment></comment><comment><USER8> Video doesn't load. I wish those people where using some other well tested video platform.</comment>


Implementing Multidimensional Arrays in JavaScript - <AUTHOR> http://0fps.wordpress.com/2013/05/22/implementing-multidimensional-arrays-in-javascript/

<comment><USER2> sorry if this is obvious - Is this useable in the browser? I couldn't find mention of this anywhere, But everything that is inolved (typed arrays) seem like they should work client side.

thx.

<comment><USER3> Yep! It should work in both settings. Just use browserify and you can stick it in your project.

</comment></comment><comment><USER4> Did you consider any alternatives to numeric.js?

<comment><USER3> I tried searching but didn't find much. If you have some good suggestions I'd be happy to know about them.</comment></comment>


OpenEMS: a free and open electromagnetic field solver - <AUTHOR> http://openems.de/start/index.php <comment><USER2> Page is down, but here's the Github repo:

[https://github.com/thliebig/openEMS- Project](https://github.com/thliebig/openEMS-Project)

<comment><USER3> google cache : [https://webcache.googleusercontent.com/search?q=cache:OSe8Ov...](https://webcache.googleusercontent.com/search?q=cache:OSe8Ovb1jWEJ:openems.de/+&cd=1&hl=en&ct=clnk&gl=us)

Also : [http://openems.de/start/index.php?show=home](http://openems.de/start/index.php?show=home)

[connectivity worked initially, it appears the site is being 'HN'ed']

</comment></comment><comment><USER4> Interesting piece of software.

Seems similar (though much more advanced), to a piece of DOS software I remember floating around various "overunity" forums I used to visit years ago (I have a secret fascination with such efforts; I know they can't succeed, but it is interesting to see the lengths and effort people go for to try), though I don't recall its name.

This software would probably be very useful for designing motors and generators, and for the DIY crowd in those areas.

<comment><USER5> Motors usually use static field solvers; i.e. E and H field are independent. This uses FTDT which is more for propagating waves in media.

<comment><USER6> So signal processing?

<comment><USER7> Yes, though these days the term 'signal processing' is usually only used for operations on the signal in digital form, ie after sampling. Since this works for the propagation of the signal in analog form, it is more useful for doing calculations about propagation of signals in waveguides or in a TWT or something.

</comment></comment></comment></comment><comment><USER8> It's informative to look at the strengths and weaknesses of the FDTD method on Wikipedia: [1].

[1] [https://en.wikipedia.org/wiki/Finite-difference_time- domain_...](https://en.wikipedia.org/wiki/Finite-difference_time- domain_method#Strengths_of_FDTD_modeling)

</comment><comment><USER5> Maybe have to try this. Been using commercial EM tools for years. Really boils down to ease of use; model entry and results post-processing.

<comment><USER9> What's your take on model accuracy? I ask because my startup has developed a high-order accurate CEM solver (think MoM full-wave type solvers but every time you double the mesh density you get a 100x accuracy improvement thanks to a bunch of algorithmic breakthroughs). But we've also been putting in a lot of work to make CAD import fast and easy and it's not clear to me what's going to get people more interested - the technical performance of the solver or the usability of the GUI. I'd be interested in thoughts on that. Or anyone interested in getting hands-on, send me an email (see my profile).

<comment><USER5> Have you tried stripline as a benchmark? It's analytic solution for infinite ground planes, so plotting error vs simulation time (mesh refinement) gives nice accuracy vs time curves. Jim Rautio did this for Sonnet a few years ago, and I then used it to benchmark several solvers. Really just to show that 2.5D solvers gives much better accuracy vs. simulation time than 3D, for planar problems.

I use AWR (Axiem, Anaylst), CST, and Sonnet. I'm satisfied with accuracy; need more speed. It's at a point where material and manufacturing tolerances are more of an issue, so I need to run parameter sweeps, yield analysis, etc. So multi-threading, GPU acceleration, and distributed computing help that.

Working on a thick patch antenna today. Axiem (2.5D infinite substrate) said 1.57 GHz. Analyst says 1.51 GHz. It actually measured 1.53 GHz. That's a 3% error on an 8% 12 dB RL bandwidth antenna. Those simulated results are after mesh convergence, so finer meshing won't help.

So I use 2-3 solvers on a single problem. It's important that the geometry translation between them be quick and easy. That's where AWR comes into play; everything plugs into it. 3D solver (modeling) is horrible for pushing polygons during the design process. 2.5D solvers are awesome for this, but then you need to sometimes push the geometry to 3D solver.

<comment><USER10> Going +1 on this. I'm not an engineer, but I'm a plasma physicist who lives doing Particle-in-Cell sims, so a very different regime and perspective.

Accuracy isn't really at the forefront of our concerns because most EM solvers since the 70's are good enough in those terms, and going to higher order methods aren't worth it for us if it is so much slower. What we need is speed. For me, give me a way to do 50 simulations in a month that are converged enough that allow me to do a parameter scan over laser phase, focal point, etc. Allow me to do more 3D simulations. That what I need. The reason is that for me, plasma is so fuzzy anyway that the nth term error in the expansion pales in comparison to if laser focuses half a micron off target, which is a much more common source of error bars in a real experiment.

I imagine it's similar for engineers, our solvers are good enough for most problems, just make them faster and allow us to do more 3D simulations in shorter time.

<comment><USER5> I went to a defense oriented EM conference about 25 years ago. One of the military guys slams a TWT down on the table and says he'll pay $1M to model this; he was serious. Of course now I can buy CST particle studio. I assume it's feasible now.

<comment><USER11> (Traveling-wave tube?)

\----

(Edit: What a cool device!! I've just been reading up on them and Wowee! I'm in the wrong field. No pun intend.)

<comment><USER5> Yep. Any sort of particle & wave interaction; klystrons, TWT, magnetrons, etc. with nonlinear and thermal effects rolled in. Nasty problems.

</comment></comment></comment></comment></comment></comment></comment><comment><USER12> Page seems down from here (Germany).

<comment><USER13> Here too (Pakistan)

</comment></comment><comment><USER14> How does this compare to NEC2?

</comment><comment><USER15> Is that a common acronym for electromagnetic solvers? It can also deal with health and the power grid depending on context.

</comment><comment><USER16> anyone have any experience on how it compares to meep ([http://ab- initio.mit.edu/wiki/index.php/Meep](http://ab- initio.mit.edu/wiki/index.php/Meep))? I've used meep for a few things but am not too entrenched that I can't switch...

<comment><USER17> It uses the same method, but the focus of openEMS is more in RF devices while Meep is more focused on optics. One important difference is that openEMS supports graded (inhomogeneous) meshes. You need this since for RF devices some features are much much smaller than the wavelength, e.g. feeding lines, and you do not want (or need) a dense mesh everywhere in those cases. Furthermore openEMS has a small GUI to display the defined structure and mesh to inspect if your setup is ok.

</comment></comment><comment><USER18> Useful for antenna design, right?

<comment><USER5> Yes, at least for electrically small antennas.

<comment><USER17> Large antenna arrays a fine too... Just takes longer to simulate of course.

</comment></comment></comment><comment><USER19> How does it compare to Meep?</comment>


Ask HN: Company IP Assignment contract - <AUTHOR> This clause in the ip contract my company is making everyone sign:
> The Company is and shall be, the sole and exclusive owner of all right, title and interest throughout the world in and to all the results and proceeds of the Services performed under or in any way in connection with this Agreement, which are hereby deemed a "work made for hire" as defined in 17 U.S.C. § 101 for the Company. If, for any reason, any of such works do not constitute a "work made for hire," Consultant hereby irrevocably assigns to the Company, in each case without additional consideration, all right, title and interest throughout the world in and to such works, including all Intellectual Property Rights therein. Consultant will and hereby is obligated make full and prompt disclosure to the Company of any inventions or processes, as such terms are defined in 35 U.S.C. § 100 (the "Patent Act"), made or conceived by Consultant, alone or with others, during the Term, whether or not such inventions or processes are patentable or protected as trade secrets and whether or not such inventions or processes are made or conceived during normal working hours or on the premises of the Company. Consultant will not disclose to any third party the nature or details of any such inventions or processes without the prior written consent of the Company. ---
How can I approach the subject about them not owning my stuff, and responses to canned answers like "It's a standard contract that we have everyone sign". If I have to sign, then I want them to give me honest answers to my questions about this circus of a clause, for my peace in mind at least.
I've spoken to lawyers, but they often charge me $700+ for spending an hour with them. I don't have that kind of money to throw around. I'm also in Maryland, USA so the California protection stuff I read about doesn't apply to me.
Btw, if you guys have any questions you'd like for me to ask, I'll ask and see what they say. We can make a game of it! <comment><USER2> This sounds completely fine. The "results and proceeds of the Services performed under or in any way in connection with this Agreement" are the work products that they're paying for.

<comment><AUTHOR> What does this mean -- __If, for any reason, any of such works do not constitute a "work made for hire," __

Doesn 't this mean anything I do at home (And thus is not 'work made for hire') has the ip assigned to the company?</comment></comment>


The Red Queen Problem – Innovation in the DoD and Intelligence Community - <AUTHOR> https://steveblank.com/2017/10/17/the-red-queen-problem-innovation-in-the-dod-and-intelligence-community/ <comment><USER2> Very thoughtful insights from someone who doesn't understand that a lack of thoughtful insight isn't the problem with our bloated and inefficient bureaucracies, and therefore fails to address those problems. You don't turn a bunch of bureaucratic lifers into tech-esque startup-minded types with teaching, you need new people and new structures to support and incentive them.

Right now, ass-covering and stasis _are_ rewarded, the rest is not. Focusing on the results of bad behavior and not the roots will always fail.

<comment><USER3> its tough because how do you drain such a large swamp without the gators fighting back? it's a miserable situation for sure. I've been in gov work for quite awhile and agree we need to nuke the lifers out, shit wont change because they will always be incompetent

<comment><USER2> If I had those answers, I'd be doing more than opining here. As you say the scale of the problem is staggering and self-perpetuating.</comment></comment></comment>