Managers and methodology pundits are focused on a dogmatic application of their particular religion regardless of whether it makes sense for the actual application. I have never seen a specific methodology work in reality when it was followed to the letter - people just don't work like that.
This is a very big reason why I doubt the effectiveness of creating a class of "managers" who's skill set is "managing". How can a graduated MBA lead a software development team without knowing the business or the domain?
Management, to me, is a skill that is learned through experience, not taught in a classroom. And it is in the classroom's where dogmatic methodologies are most prominent.
Depends on the pundit, really. The Extreme Programming people were pretty clear that local adaptation was vital. Either Kent Beck or Ron Jeffries told me that by-the-book XP was where they encouraged people to start, but the whole point of doing regular retrospectives was to continually improve the process.
I do share your suspicion of management as a generic separable activity. Especially since it creates such perverse incentives. It has rarely been my impression that the more managers you add, the better things get.
The methodologies don't, "suck," and the author points out in eir conclusion that not having any methodology is bad.
It's the organization part that's important. Methodologies will work differently depending on the make up of the team. The important part is discussing what works and eliminating what doesn't. Only then can you flush out the gremlins of the mind and focus on the work.
That being said -- too much methodology is a gremlin of another kind. There needs to be enough process and practice to ensure everyone understands what needs to be done and how to consistently go about it. My favorite motivator is responsibility. Let the team members in the trenches make the decisions and make them own the consequences of their decisions. Winning feels so much better that way compared to being led by a dogmatic agile-XP-scrum-master.
I think (and have argued: http://xrl.us/bmeqcm) that the problem with most development teams - Agile or not - is that the people who are on point to make the deadlines (the Project Manager and/or Product Owner) usually don't have the agency to increase resources or move deadlines - they normally just have the ability to bully programmers and decrease software quality (pressure on tests and documentation)
Let me just say this flat out: if the product manager can't change scope and deadlines, then they are not doing anything I recognize as Agile. Fixed scope/fixed date approaches are the exact opposite of what every Agile pioneer had in mind.
> Let the team members in the trenches make the decisions and make them own the consequences of their decisions.
This! And this:
Maybe it’s an extension of the deeply held view that from an economic viewpoint, it would be ideal if people were interchangeable.
People are unique, each person has her own talent: you can profit from it and get a nice product, or you can try and annihilate it into a strict methodology and get a sloppy result - but you'll have obtained it with your favourite methodology!
I’ve read a lot of software engineering research[1], because I’m interested in being as productive as possible, but SE research reminds me of a lot of empirical economics from the 70s. People were (and still are) trying to figure out what can be done for developing countries. Back then, researchers more much more likely to try to figure out what methods were the absolute best, period. Now, people are much more likely to acknowledge that there’s path dependence, and that something that works in one context may be completely useless in another context.
It’s rare to see serious empirical work in SE that’s up the same standards as empirical work in modern economics (either an RCT, or a good pseudo-experiment from a clever instrumental variable), and when you do, there’s little to no discussion of how generalizable the work is. There’s often a paragraph about how the study may not generalize, which seems to be enough to satisfy peer reviewers, but isn’t nearly enough to figure out if the methodology under test has any applicability whatsoever to your setting.
[1] if you're curious, and want to look up what's in vougue, the premier SE conferences are ICSE and FSE
I always thought methodologies suck because of their lack of evolution. They're too rigid in a fluid world. They stay the same for years while the world around them is constantly changing. They attempt to take one idea, one theme, one solution and apply it to every problem rather than looking at everything on a case by case basis.
Humans don't like thinking, it's expensive, it requires time and effort. So people like to think once, find an answer, copy and paste that answer over and over, and never think again.
It's the ultimate human mistake, trying to use simple dumbed down solutions to complex problems. The same goes for liberal/conservative/christian/muslim/jewish/athiest/republican/democrat/libertarian ideologies. Any time you group a series of solutions together into an idea, party, or organization you've given them planned obsolescence.
I found the following to be the main point of the article:
==================================
You might think that puts us in an impossible position when it comes to deciding how to run teams. But consider why software development is not a regular environment, and why it is so hard to run experiments, to acquire skills, and to measure which practices and decisions lead to success, and which to failure. The root cause in all these cases – the reason the environment is not regular – is that the feedback loop between making a change and understanding the result of that change is too long. The word “change” here should be understood very generally to mean change in requirements, change in methodology, change in development practices, change in business plan, or code or configuration change.
There are many benefits to reducing cycle time – it’s one of the most important principles that emerges when we apply Lean Thinking to software development. Short cycle times are certainly essential for creating great products: as Bret Victor says in his mind-blowing video Inventing on Principle, “so much of creation is discovery, and you can’t discover anything if you can’t see what you’re doing.”
But for me this is the clincher: It’s virtually impossible for us to practice continuous improvement, to learn how to get better as teams or as individuals, and to acquire the skills that enable the successful creation of great products and services – unless we focus on getting that feedback loop as short as possible so we can actually detect correlations, and discern cause and effect.
==================================
Jez seems to believe that Development Methodologies suck when they reach the point of getting in the way of developers creating things and when you have long cycle times before you can see the fruits of your labor, wonderful ideas are potentially lost. One of the important aspects of Continuous Delivery is to reduce that feedback loop as much as possible - people start to do amazing things and create wonderful ideas with immediate results to the changes they are making.
One of the reasons I think we don't have a clear understanding of methodology effectiveness is that there's too many other variables. For example you could take the same team, completing the same project and have them work under different methodologies in order to see which one was the fastest, best quality, etc. but even that isn't possible since the team would be better the second time around. Also what works for one team may not work for another due to personalities, work culture, etc. different projects may be better suited to a different approach. We tend to want to find the one true methodology, but I don't think it exists.
I tend to think that just using any methodology at all will tend to give better results because it means the team is at least attempting to manage the process. It usually means that at least somebody on the team cares about keeping some kind of organization. Even if it's a loose version of a methodology. Having no methodology at all can work too, but tends to rely on heroics and can be more stressful for everyone - especially the other people in the company who need to plan their work around the development schedule.
This is a very big reason why I doubt the effectiveness of creating a class of "managers" who's skill set is "managing". How can a graduated MBA lead a software development team without knowing the business or the domain?
Management, to me, is a skill that is learned through experience, not taught in a classroom. And it is in the classroom's where dogmatic methodologies are most prominent.