My opinion (not "theory") is that teams are not interchangeable. Companies are not interchangeable. Industries are not interchangeable. What works for one team may not work for another. What works for a 10 man startup is not going to work for a 200,000 person company. What works for a web app company is not going to work for a video game company. But, Agile and Scrum have been shoehorned into every tech company I can see no matter how inappropriate it may be for that particular team, company or industry.
Your question prompted me to consider a thought experiment. Let's assume that management techniques are completely ineffective and the deciding factor in whether a project ships and is successful or not lies entirely with the programmers and designers. Now, let's take it one step further and say that most management techniques actually reduce the likelihood a product ships and is successful. Do you think that would stop management from trying to exert control over something that is completely out of their control? Do you think that would stop management from thinking that their input is actually making things better when in fact their input is making things worse? Managers are ultimately responsible for producing results, but they have no direct control over those results. Most humans, when put in that situation, will try to do something, anything, to make it feel like they have some control over the situation. Even if it makes that situation worse. Finally,what if what I have described above isn't actually a thought exercise, but a fairly good description of what is happening in the real world right now. Would we be able to tell?
Managers in large companies will push anything in a top-down fashion. Before, they pushed waterfall. Now, they are pushing something they call Agile. (They do, I don't.) In 5 years, the consultant-managerial complex will push something else. I agree that is bad. [1]
But the top-down thing is explicitly not what the Agile movement was about. As the early Extreme Programming community would say, "By-the-book Extreme Programming is where we suggest you start, but it's definitely not where you should end up." The notion was always that teams would take time every iteration to look at how they were working and improve it to match local conditions.
So the way to think about it isn't in terms of manager interventions. It's in terms of those non-interchangeable teams experimenting and then sharing what they've learned with other teams. Teams will learn things! Some of those things will apply to other teams. A few will apply widely. And that's exactly how the good Agile teams work today. They may start from some recommended set of practices, just like any novice does while learning things. But they are supposed to evolve from there to match local talent and conditions.
Not so weird at all. Codebase and process don't matter to a customer, all they see and judge is the end product. Sometimes even the end product doesn't matter, as the likes of Google can put much more money into ads and marketing than you.
There might be a correlation between what people do and how the project goes if you're NASA or BMW. But for 99% of the software world, nobody cares if you have the most hacky codebase ever as long as it does what it's supposed to do and doesn't have too many bugs.
The customers don't care how the programmers work as long as they get good results. But the people on the team should really care. And if they do, they should a) experiment, and b) exchange ideas with other teams.
Comments
Your theory is that software is totally random? There's no correlation between what people do and how the project goes?
That is a really weird theory for a programmer to have about anything, let alone what he's chosen to spent 80,000 hours doing.
My opinion (not "theory") is that teams are not interchangeable. Companies are not interchangeable. Industries are not interchangeable. What works for one team may not work for another. What works for a 10 man startup is not going to work for a 200,000 person company. What works for a web app company is not going to work for a video game company. But, Agile and Scrum have been shoehorned into every tech company I can see no matter how inappropriate it may be for that particular team, company or industry.
Your question prompted me to consider a thought experiment. Let's assume that management techniques are completely ineffective and the deciding factor in whether a project ships and is successful or not lies entirely with the programmers and designers. Now, let's take it one step further and say that most management techniques actually reduce the likelihood a product ships and is successful. Do you think that would stop management from trying to exert control over something that is completely out of their control? Do you think that would stop management from thinking that their input is actually making things better when in fact their input is making things worse? Managers are ultimately responsible for producing results, but they have no direct control over those results. Most humans, when put in that situation, will try to do something, anything, to make it feel like they have some control over the situation. Even if it makes that situation worse. Finally,what if what I have described above isn't actually a thought exercise, but a fairly good description of what is happening in the real world right now. Would we be able to tell?
Food for thought.
Managers in large companies will push anything in a top-down fashion. Before, they pushed waterfall. Now, they are pushing something they call Agile. (They do, I don't.) In 5 years, the consultant-managerial complex will push something else. I agree that is bad. [1]
But the top-down thing is explicitly not what the Agile movement was about. As the early Extreme Programming community would say, "By-the-book Extreme Programming is where we suggest you start, but it's definitely not where you should end up." The notion was always that teams would take time every iteration to look at how they were working and improve it to match local conditions.
That was definitely true even at the beginning; "self-organizing teams" was one of the principles from 2001: http://agilemanifesto.org/principles.html
So the way to think about it isn't in terms of manager interventions. It's in terms of those non-interchangeable teams experimenting and then sharing what they've learned with other teams. Teams will learn things! Some of those things will apply to other teams. A few will apply widely. And that's exactly how the good Agile teams work today. They may start from some recommended set of practices, just like any novice does while learning things. But they are supposed to evolve from there to match local talent and conditions.
[1] I've written more about that here: http://agilefocus.com/2011/02/21/agiles-second-chasm-and-how...
Not so weird at all. Codebase and process don't matter to a customer, all they see and judge is the end product. Sometimes even the end product doesn't matter, as the likes of Google can put much more money into ads and marketing than you.
There might be a correlation between what people do and how the project goes if you're NASA or BMW. But for 99% of the software world, nobody cares if you have the most hacky codebase ever as long as it does what it's supposed to do and doesn't have too many bugs.
The customers don't care how the programmers work as long as they get good results. But the people on the team should really care. And if they do, they should a) experiment, and b) exchange ideas with other teams.
Pretty sure that's a big part of the problem Agile and other approaches to software development try to address.