I have watched a ton of these agile/waterfall debates from both sides and it is starting to get predictable: People who work in stable, well funded environments cannot understand why anyone would take a shortcut that compromises quality and increases risk. People working in dynamic, bootstrapped environments rightfully argue that when drowning in shark invested waters - it is better to just start swimming in a random direction than to discuss the survival plan with budget subcommittee of the board of directors. Ultimately, both sides are just like those blind guys who can feel only one part of the elephant.
We are living in a world of uncertainty. Business strives to create certainties. Sometimes this can be achieved, sometimes we can get close and some things are not solvable. Knowing the difference saves a lot of heartache
This was an excellent talk, and helps me a lot with understanding where some of our Agile processes go wrong - or at least gives me places to look for solutions.
@12:45 I can't post the actual link here in the comment, but if you look up Lars Goran Wallgren from the University of Gothenburg, Sweden, you will be able to download the thesis.
The only people who are going to watch a video like this are the ones who can't make any effective changes. Software developers are slaves to rampant corporate corruption. There is no rational argument you can make to change management's mind. They do not care about productivity, morale, the product, the customer, cost, or even the company or the shareholder. They care about their personal agendas and power. Watching them interact with each other is like watching A Game of Thrones. The only way to make a difference is to do good work in secret.
In fact, the shuttle could not fly very often without a major accident. Unlike airplanes, which had less planning per product. Why? Because in airplanes we don't use new parts, but a lot of reuse engineering based on real usage and feedback. If the fragility of the (BUFD of the) shuttle had been recognized, it would not have been allowed to fly with people for the first 30 years.
The shuttle is a bad example because it was an attempt to do very hard things(tm) on a budget. The Apollo program is a much better example of Waterfall working well. Waterfall works a lot better when requirements are fixed in stone, budget is near unlimited and timeline is 10 years plus. Most US military programs are Waterfall and that is why they trump the 'agile' mentality of other World armies. The opposite is true of Silicon Valley - its agile mentality runs circles round the central national planning viewpoint of other economies trying to 'do technology'. Clearly military and technology industries have some major differences.
@@michaelnurse9089 The Apollo program is also a great example of incremental approach. Each element and action of the mission to the moon was demonstrated in intermediate steps, including a preliminary flight to the Moon and back. Other example of non-waterfall approaches of DoD are all the cases where some prototypes were first built to demonstrate certain capabilities. Using planning is not necessary waterfall. Pure waterfall assumes little and late feedback/testing, the idea that you can design up front and don't need intermediate demos. The original concept of waterfall, for software systems, as described by Winston Royce in 1970, was not a pure BIG Up Front Design, but was based on a somewhat evolutionary design and "do it twice" recommendation - using at least two iterations. The problem, at least in the software, is that it was misinterpreted.
There are more options depending on the context and goal. New product? Exploratory, Spiral may work. Smaller change of an existing product? Maybe "simple design" can work. However we need also a bigger picture and understanding for a set of more simple changes.
One must divide business activities into Engineering/Technical(T), management(M) and entrepreneurial(E) concerns. Set based designed is purely an T process that viewed in a vacuum cannot be criticized. The problem comes in when E concerns thoroughly trump T concerns then something like agile HAS to be employed. AT&T may have been big but as a regulated telecoms provider their position in the market was guaranteed by the government. In other words, E was irrelevant and so only T and M mattered. This is completely different to the early days of Google where E was everything while T and M only mattered once they needed to list a couple years later.
I don't divide business activities outside of Technology. STEM - Science, Technology, Engineering, Mathematics are all used together. Everywhere. What divides them is the end product. Otherwise, they are fluid how they affect what we are doing. I haven't seen categorizing these fields outside the end product to have much benefit or impact. I know these are commonly used terms. But they are soft. And interpreted by a whim into one or more fields. STEM or other fields.
Equating patents to innovation is optimistic at best. Innovation is something that cannot be easily measured by metrics but you know it when you see it as you can't put the product down when you first come across it.
I worked for a bank which was very small. It was once owned by a large national bank who went bankrupt following failed system implementation. I asked the owner/manager/entrepreneur of the small bank what he used for systems at the time and he said a single Lotus 1-2-3 spreadsheet. The only thing was that he personally had to make all change to the sheet to ensure its results were credible. Once it grew bigger it had to buy and adapt market systems and then problems started. I realise this is a cherry picked example, but cherry picking is a useful scientific process in determining if certain rules are universal or not. Gravity might have no exceptions to its rules but almost certainly system size vs efficacy is very uneven terrain.
I wanted to watch/listen because the title sounded like it was challenging some of my beliefs. Unfortunately all I hear is an angry old man ranting against strawmen.
Super relevant talk So many cargo cult development operations using all the correct ceremonies and accoutrement, and wonder why their efforts are failing
But TDD is gospel! Jokes aside there is nothing wrong with TDD if used correctly and appropriately. I prefer it for a stable spec. If there's no spec, it's a great way to lose a customer.
"Individuals and interactions over processes and tools" - I always though the most important part of the agile manifesto was thinking. Leave this thinking out, and you might have the nimble manifesto we follow today. And most do treat the agile manifesto as the nimble manifesto. Yes, waterflow can be more agile than nimble. I might delete this. Just watch the video.
First to market is considered by business strategy experts to be the most powerful force in markets. Only when the first players drop the ball badly do later players get to supplant them (or when entire national economies support the newcomer, they can supplant incumbents too). People who say MySpace came before Facebook probably never used MySpace and saw how utterly different it was. Google, Apple, Microsoft, Facebook were all first to market if you view it from a customer needs perspective - their so called predecessors were serving a different (or perhaps a partially overlapping) market.
But I add Kalman Filters to all my code. Why? To spite all those who say it isn't rocket science. Algorithm that brought the Apollo Rocket to the moon. And often, PID's are just as easy to copy pasta than any other SO code :-P But think a little. The end product is not rocket science (unless it is). I agree it doesn't mean it is provable to be any less complex.
What I find most interesting about Scrum is the continued belief it works.
I have watched a ton of these agile/waterfall debates from both sides and it is starting to get predictable: People who work in stable, well funded environments cannot understand why anyone would take a shortcut that compromises quality and increases risk. People working in dynamic, bootstrapped environments rightfully argue that when drowning in shark invested waters - it is better to just start swimming in a random direction than to discuss the survival plan with budget subcommittee of the board of directors. Ultimately, both sides are just like those blind guys who can feel only one part of the elephant.
“Shark invested” waters - I know what you meant, but this is the phrase of the month
We are living in a world of uncertainty. Business strives to create certainties. Sometimes this can be achieved, sometimes we can get close and some things are not solvable.
Knowing the difference saves a lot of heartache
This was an excellent talk, and helps me a lot with understanding where some of our Agile processes go wrong - or at least gives me places to look for solutions.
@12:45 I can't post the actual link here in the comment, but if you look up Lars Goran Wallgren from the University of Gothenburg, Sweden, you will be able to download the thesis.
The only people who are going to watch a video like this are the ones who can't make any effective changes. Software developers are slaves to rampant corporate corruption. There is no rational argument you can make to change management's mind. They do not care about productivity, morale, the product, the customer, cost, or even the company or the shareholder. They care about their personal agendas and power. Watching them interact with each other is like watching A Game of Thrones. The only way to make a difference is to do good work in secret.
40:07 some say he's still writing the response
In fact, the shuttle could not fly very often without a major accident. Unlike airplanes, which had less planning per product. Why? Because in airplanes we don't use new parts, but a lot of reuse engineering based on real usage and feedback.
If the fragility of the (BUFD of the) shuttle had been recognized, it would not have been allowed to fly with people for the first 30 years.
The shuttle is a bad example because it was an attempt to do very hard things(tm) on a budget. The Apollo program is a much better example of Waterfall working well. Waterfall works a lot better when requirements are fixed in stone, budget is near unlimited and timeline is 10 years plus. Most US military programs are Waterfall and that is why they trump the 'agile' mentality of other World armies. The opposite is true of Silicon Valley - its agile mentality runs circles round the central national planning viewpoint of other economies trying to 'do technology'. Clearly military and technology industries have some major differences.
@@michaelnurse9089 The Apollo program is also a great example of incremental approach. Each element and action of the mission to the moon was demonstrated in intermediate steps, including a preliminary flight to the Moon and back.
Other example of non-waterfall approaches of DoD are all the cases where some prototypes were first built to demonstrate certain capabilities.
Using planning is not necessary waterfall.
Pure waterfall assumes little and late feedback/testing, the idea that you can design up front and don't need intermediate demos. The original concept of waterfall, for software systems, as described by Winston Royce in 1970, was not a pure BIG Up Front Design, but was based on a somewhat evolutionary design and "do it twice" recommendation - using at least two iterations.
The problem, at least in the software, is that it was misinterpreted.
I agree with this guy in 100%. I hate IT world with Agile, but I dont know what to do with this nonsense.
There are more options depending on the context and goal. New product? Exploratory, Spiral may work. Smaller change of an existing product? Maybe "simple design" can work. However we need also a bigger picture and understanding for a set of more simple changes.
One must divide business activities into Engineering/Technical(T), management(M) and entrepreneurial(E) concerns. Set based designed is purely an T process that viewed in a vacuum cannot be criticized. The problem comes in when E concerns thoroughly trump T concerns then something like agile HAS to be employed. AT&T may have been big but as a regulated telecoms provider their position in the market was guaranteed by the government. In other words, E was irrelevant and so only T and M mattered. This is completely different to the early days of Google where E was everything while T and M only mattered once they needed to list a couple years later.
I don't divide business activities outside of Technology. STEM - Science, Technology, Engineering, Mathematics are all used together. Everywhere. What divides them is the end product. Otherwise, they are fluid how they affect what we are doing. I haven't seen categorizing these fields outside the end product to have much benefit or impact. I know these are commonly used terms. But they are soft. And interpreted by a whim into one or more fields. STEM or other fields.
Scrum is known to lots of people as a word in countries that play rugby. I don’t know why he thinks it’s rare.
Thanks for the rest of the talk.
How many have talked to user and observed the user - when, how, and why they use the system
This is very important but how many devs do this?
I love this talk! Thank you for sharing and having it!
Equating patents to innovation is optimistic at best. Innovation is something that cannot be easily measured by metrics but you know it when you see it as you can't put the product down when you first come across it.
I worked for a bank which was very small. It was once owned by a large national bank who went bankrupt following failed system implementation. I asked the owner/manager/entrepreneur of the small bank what he used for systems at the time and he said a single Lotus 1-2-3 spreadsheet. The only thing was that he personally had to make all change to the sheet to ensure its results were credible. Once it grew bigger it had to buy and adapt market systems and then problems started. I realise this is a cherry picked example, but cherry picking is a useful scientific process in determining if certain rules are universal or not. Gravity might have no exceptions to its rules but almost certainly system size vs efficacy is very uneven terrain.
I wanted to watch/listen because the title sounded like it was challenging some of my beliefs. Unfortunately all I hear is an angry old man ranting against strawmen.
Super relevant talk
So many cargo cult development operations using all the correct ceremonies and accoutrement, and wonder why their efforts are failing
But TDD is gospel! Jokes aside there is nothing wrong with TDD if used correctly and appropriately. I prefer it for a stable spec. If there's no spec, it's a great way to lose a customer.
excellent video
"Individuals and interactions over processes and tools" - I always though the most important part of the agile manifesto was thinking. Leave this thinking out, and you might have the nimble manifesto we follow today. And most do treat the agile manifesto as the nimble manifesto. Yes, waterflow can be more agile than nimble. I might delete this. Just watch the video.
First to market is considered by business strategy experts to be the most powerful force in markets. Only when the first players drop the ball badly do later players get to supplant them (or when entire national economies support the newcomer, they can supplant incumbents too). People who say MySpace came before Facebook probably never used MySpace and saw how utterly different it was. Google, Apple, Microsoft, Facebook were all first to market if you view it from a customer needs perspective - their so called predecessors were serving a different (or perhaps a partially overlapping) market.
Google and Facebook were better, not first. Apple was the first personal computer. Microsoft was not first, nor better. It was lucky
But I add Kalman Filters to all my code. Why? To spite all those who say it isn't rocket science. Algorithm that brought the Apollo Rocket to the moon. And often, PID's are just as easy to copy pasta than any other SO code :-P But think a little. The end product is not rocket science (unless it is). I agree it doesn't mean it is provable to be any less complex.
I’m not understanding your point