I wish you'd re-edit this to show the right slides at the right time. :(

Tough crowd and extremely relevant material I Can hear them all screaming “not my data!” and “what about performance?”

So what do finance processes look like in an agile company? One of the things the finance team does is validate theres budget and validate where the money is going to (lots of scams exist to confuse people to send money to the wrong place).

8 fucking years later, the virus is still present

the moment you realise this guy is the director of QA

Flaw-lessss

At 6:40 Mr Holub makes a devastating observation: the whole organization has to be "Agile", not just the software developers. Coming from an Enterprise ISV that "forced marched" from "waterfall", classical development was painful, but Engineering did this within one year. What we discovered was that customers were not Agile. Their IT organizations could not deploy s/w developed in 90 day cycles. The back office end users rebelled against changes in the systems: their performance metrics degraded 15-20%. When one of your customers has 24,000 end users of your system, this is a problem. Their CEO calls your CEO. Lawyers get hired. The Business division owns the contract. The IT Division "owns" the operational success, but not the budget for it. Agile s/w delivery is seen as a solution to delivering CAPEX scope system changes within an OPEX budget. Customers wanted to pick and choose select feature changes as "system patches", not as full releases. Lastly, any Enterprise s/w system has to integrate with legacy and in-house s/e systems, hence the Corporate Customer's IT Division has to be Agile too.

How the tides have turned. C# is getting pretty popular nowadays. (WPF still sucks massively, though)

Cant believe the audience didnt laugh that much, "getLength, I did recieve a lot of spam suggesting this." LMFAO

Undisciplined

Very spot-on talk, I agree with the certification mills, agility of training and the dysfunctional tools points. The level of frustration in the voice tone most likely reflects actual experiences. ;)

Time traveling from 2024: At last an "Agile sux" video that makes sense. Agile doesnt suck, bad Scrum sucks. Allen pinpoints the problem - We need a culture of Agility. And Orgs are looking for a quick fix. And they love their extant culture. So change does not happen. What's most alarming is that this is 8 years old and still relevant.

I am still a believer in Scrum, but my job as a technology manager (despite many saying managers have no role -- I'm also a developer who still codes) is to protect the process and to constantly remind everybody (both on the team and in the business) of why we use it and what it is able to achieve, but only if we focus on doing it well and for the right reasons. One of the hardest things about Scrum is how to scale it, which is what inevitably led one company I worked at to embraces SAFe, which rubbed me the wrong way immediately. It was chock full of registered trademark symbols, and I saw through it immediately. But by this time, senior leadership had gotten a sniff of how effective my teams were, and they wanted that for everybody, and they had signed on the dotted line, and that was that. And that was not only the end of real agility in that department, but soon prompted me to leave. I'm still not ready to give up on Scrum, though, because I saw it work too well. I'm hopeful we can experience something similar at my current employer.

You can tell this individual has not had to deal with any form of tech archeology-figuring out what the fuck people in the past did. The whole not making adequate documentation is literally what happened with the developments of W76, W78 and W88 nuclear warheads via FOGBANK. Inadequate documentation cost billions upon tens of millions of dollars in wasted research that was forced to be done because they lost the means and methods to make the product in the first place. This is a common problem that happens particularly with long-standing technologies and it's one to clearly isn't addressed in this presentation. How can you be AGILE and also not leave a klusterfuck for future generations who now have to figure out what the fuck you and your peers were doing, how it works, and so on because documentation wasn't important because it "got in the way"/"was inefficient uses of time".

The US Air Force went through a similar thing with the Total Quality movement starting in the early nineties. The US Chief of Staff had heard that the Total Quality movement could work wonders in industry, and decided that he would apply it in the Air Force. It soon became clear that he only intended to use the terminology, while rejecting just about every substantive reform that TQ required. The whole effort was abandoned after he retired. There is now no indication in the Air Force that TQ was even attempted.

Yep, it could be true but... not every company is a software company and not every delivery process is a software build process. The basic mistake is that every company and every project inside IT corporations/companies will work with "software building" workflow and Agile methodology/frameworks. It will not. But this is all about very very very shallow understanding of how companies work.... It is like thinking that copying a file is a moving icon between folders. And when we make thing moving icon faster, the process will be faster.

Inconsistent audio level. Impossible to listen to in my car

The point about cloud aged like fine... Milk

Yes forget the word ‘Agile’ it’s really about the ‘Culture’. Unfortunately greed, money, unstable teams and poor social constructs can and will decimate the ‘Culture’. Until we find the solution to such human limitations we can only dream about the religion of Agile. In the meantime a Godless AI may supplant us all 😊😈

Nothing for a QA dept to do… oh sweet summer child. Actually a QA dept which can support dev teams whilst also maintaining system testing which tests the SYSTEM according to the system specifications or use cases known to be what the customer needs has obvious value. Even if you measure every grain, unless you’re taking a look at the actual system, you’ll probably end up with a heap and not a sandcastle. Unless your system is so small it fits into one small team where everyone knows everything…

"we do not have a hierarchy" a notion that is anathema to many business entities, not just mega corps. I once worked for a company that had maybe 40 employees. we in the technical staff were at the bottom of the org chart, and management (aka, the owners) wanted it that way. people with power will do anything to hold on to that power, and empowering their perceived underlings to take control of a major part of a business process is a threat to their power. the upper levels of the hierarchy will fight that tooth and nail. that's not some business school lesson, that's basic human nature.

Thank you very much, great class

Typical scrum project is like a waterfall without analysis and design phases. I think of it as a circle of poorly planned implementations followed by endless refactoring and bug-fixing. Scrum actually allowed and encouraged non-tech people to be directly involved in development process and it is one of the biggest problems with scrum. We can do scrum and it will work if we just replace non-tech SM and non-tech PO with Lead Dev who actually knows how development works and instead of having tons of useless meetings, just normally talk with our colleges during lunch or coffee. "Agile" should be just natural teamwork and cooperation.

Everything is true. Except the fact threat the real world complex project require integrated hardware and software which behaves unexpectedly and you tested but final system doesn’t work.

I use extended supers precisely because it has that brittle nature to it. Expecting subclasses to not have or have the wrong implementations and overrides. Essentially a glorified error generator and pattern enforcement tool (complexity enforcement). Downside is that those supers are fixed. They do not, nor should ever change only substituted and deprecated. Substitution of supers, while a bit consuming, is a very viable way to deal with it if you have well defined boundaries. That, if you still require the error machine.

Damn I didn't even do anything and I'm afraid.

Very good! Thanks!

What I don't understand... why is agile development so focused on building software WITH a customer? How do you build shit as an ISV? How do you work with agility as a game developer? That's where this narrow gatekeeping really falls apart. 80% of companies I worked in were ISVs of some sort, or were developing software just for internal use.

Best thing I've seen on Agile and scrum ever. Thanks. I wish I can join or create such a company.

Back when I did the CSM, you could get absolutely every question wrong and still be issued a certificate... because you paid for it

It's almost 9 years old and this talk is still depressingly relevant. I don't see any of the companies that are "agile" going out of business any time soon though.

Yep sounds like the daily bullshit us devs get subjected to

One of the worst talks I've ever seen. What fantasy world does this guy live in ?

The SOLID principles are terrible for maintenance and performance. So if you want slow, complex, abstract, over engineered, tangled messes of garbage then by all means.

This is all organisational management, hierarchical vs flat vs cells. His description is of flat and dynamic cells structure with LOs, but wrapped up in a cultish jargon that can be packaged and sold to companies.

Everyone is equal but some is more equal than others

"There's no hierarchy, no bosses" - So when did Spotify become a worker coop? Tribes/Guids/Squads, gross corporate-speech.

There’s a fundamental issue in the workplace where the workers simply realize their own personal interests do not line up with the business interests. This is rational. Software guys always have to deal with the threat of building themselves out of a job, especially in an economy that doesn’t just let companies borrow free money indefinitely. Management is not incentivized to pay a reasonable salary indefinitely for a class of workers they consider 90% of to be unnecessary after the thing is built. Therefore a slower, worse, more maintenance heavy product means reliable work in the long run for a vast quantity of workers, as long as its not so bad as to put them out of a job or harm their ability to get more work in the future.

I think Agile sets back the IT community decades. I would give you reasons, but Agileista-worshippers will not care, just ridicule and demean me as usual, while "the heathens" would deem my reasons to be bleeding obvious. Agile is a complete resignation to complexity.

Holub on Patterns is one of the most difficult programming I ever *tried* to read. Which begs the question, whatever happened to design patterns? Not as popular as it used to be, just like Agile.

I tend to agree with him, but I have worked in big companies, small companies, a university, etc, and I have never seen a company or organization that fits the description of agile, to me that's just a unicorn. Imagine saying let's all go to 'X' conference without asking anybody outside the team about it

It's hard to determine who is more stupid, customers who do not know what they need or the "technical people" willing to keep rewriting and retesting some software until the customer grows a brain? Quitters never win and winners never quit, but when you never quit or win you are an idiot. No one ever did "waterfall", we did build prototypes to demonstrate function and for customers to play with to uncover better ways to do "function X or Y". Agile has been a management license to kill off testers and configuration management people. Software Engineers are good for completing unit test period! You gloss over integration testing and that will cause problems unless you create an ICD(s) and pick a middleware (e.g. message oriented middleware) to define how components talk and listen. Building GUI components for the customer and collecting rules behind the display screens from users/customers has been the most successful method to build systems. One can build a user manual which will help with the maintenance lifecycle as well. I'm happy I retired just as the agile/scrum madness hit the profession. Keep in mind, the definition of SOFTWARE is code, data and documentation maintained in a specific configuration. The metrics collected on scrum/agile over the last 20 years point to utter failure, and no better than "waterfall!"

27:39 a very important point. upfront requirements doesn't work. but people are just. get the full requirements right and then only start working. till then don't do anything. i don't understand this. agile means flexibility. adapting to changes and as we get the know problem, requirement better. don't code till then. it doesn't make sense...

Unit tests are for morons lololooolol

I think he’s moreless right about getting user feedback and getting them more involved in the process over deadlines. Unfortunately, most businesses do not run this way. They deliver a product and define a scope and budget. Then, when you go through the process you’ll get that customer feedback and if you accept that feedback it will either push out the scope or you’ll close the actual project but then work with the customer after.

Tell me you hate scrum without telling me….

I agree with a lot of what is said here. But very confused about saying “in agile there are no project managers”. What??? There are certainly project managers in an agile environment. Unless; you’re saying that in an agile environment the team should be doing documentation, creating product, facilitating etc etc. that doesn’t work in the real world my friend

I like how he mentions the importance of culture and trust throughout an organization to a successful agile implementation. There's a lot of wisdom here. In fact, these might be prerequisites. In other words, if you want an agile transformation, don't start by forcing people to attend daily status report meetings or do some other aspect of Scrum dogma. Instead, focus on building trust.

I agree with every single word exept customer management. Sometime customers could be milion of people you need to manage the interaction in a very structured way.

Good look without the QA department in big/middle corporations. I find it very amazing how devs think that they are centre of the world, and dont understand other contributions. To be agile at the org level you have to define your domains and give them accountability, exacly as they give it to you as devs. These are the WoWs defined by Smart. The agile manifesto is irrelevant if you don't apply a second layer of lean management to this concept. This is what many devs dont get, it only talks about what you deliver, not how you do it. The how is always a lean process and must be well-defined at the process, role and tool levels. There is only 1 way to push to prod. If you have 300 teams, you cannot allow 300 tools doing the same, this is madness And BTW I hate SAFe, scrum and all this snake oil, but when a dev says that QA/DevOps is not necessary because they take over I can only laugh. You brought this micromanagement onto you, it was not us.