Tangentially, English is the most agile language of all; words can and do bleed into different categories all the time. My favorite is when people say they've "third-class'd" a route -- meaning that they climbed it without a rope.
Yeah thats kind of like how I view different things in English too. For example, when people are still confused between their/there or they're. A lot of people tend to blend all the 3 together . Call be a obnoxious but thats a pet peeve of mine
Not only is Agile still very valuable with lots of good lessons to teach us - this guy's complaints are technically wrong - his examples pertain to the use of the word as a verb or an adjective - not as a noun. And, to be fair, in the context of software, turning Agile into a verb is perfectly fair.
"Agile Master Alliance" - Adjective - it modifies "Master"
"How to Agile" - Verb.
"Agile Certificate" - Adjective. You could argue that it is a nominalization, but that is truly splitting hairs.
So, in the end, what is this guy's point, other than "get off my lawn"?
Edit/update:
Magdoub's point is this:
>You don’t need velocity, daily stand ups, points estimations, spikes, scrum masters to deliver high quality software. You just need good people.
That is so catastrophically false that I don't even know where to start. I mean, really sanity-blasting. Sure, maybe cargo-cult adherence to agile tenets is not going to help anyone, but throwing management methodology out the window and hoping that "good people" just somehow summon good software into being is comically naive.
I would say that their business goals have just changed over time, they went from being a company that spits out games, to a company that spits out money. While the end results have changed there is still underlying software that powers all of these things. Look at the in game cosmetics economy that has sprung up around dota2 and cs:go. If anything this is the definition of being Agile.
To further your advocacy... how many successful examples can you point to outside of Valve? How does that compare to the number of groups that are using some form of agile methodology to produce a successful product?
None. Like I said below, I'm not taking a stance. I practice "agile" at my company, but Valve's existence does refute the claim that it's comically naive.
Now, if I had to offer my 2 cents why it works at Valve and not others -- games are deeply creative. You actually want your engineers to go off in their own little world and somehow capture the sparks that fly. It's nearly impossible to do this with some sprint model ("OK guys, creative thinking sprint! let's go!").
To re-iterate, the reason why it doesn't work with games is sprints are output-driven yet the creative output is not so easy to capture in this manner. Its origin is mysterious and subject to "ah ha!" moments whenever/wherever. This is why games must instead focus on process (hire the best, let them do whatever) and take a hit on strict output-driven management.
Yet, the big dogs have been pushing one game out after another. For example, WoW got bought by Activision and they couldn't get new expansions out soon enough. One of the most popular MMOs, Ultima Online, was bought by EA and they immediately started their expansion line of junk and ruined the game. This wears down on the overall brand of the game. Ultimately, output-driven management of games is a sure way to lose the creativity and balance necessary to create a gem.
When I worked at certain top software companies the people I worked with were often so talented and, most importantly, cared enough about the work they did that we could have produced great software with any form of process. In fact, we often started with "base Scrum" and about 6 or so months in we would have a completely modified version of Scrum.
My point is, I don't think Valve is hiring average or below average people. Their process works for them because great people make any process work. Or maybe great people just make their own process, which is the most Agile-y of Agile things you can possibly do.
>>> and hoping that "good people" just somehow summon good software into being is comically naive
You have no idea how true this statement is. I was on a small project about a year ago, using Agile. Both mangers and a director quit within weeks. Our team basically became self sustaining. No PM's, no managers. Our team had no oversight and no captain to steer the ship. We were left to finish the project ourselves.
We had a team of 5 developers. We sat at lunch one day, bound and determined to show management we could do this without all the daily standups, agile tracking, burn down rates and stupid PM oversight.
I wanted to quit inside of two weeks. 3 developers were advocating a total rewrite and a pivot to a different stack. Myself and another developer just wanted to finish the app and get it shipped. Egos, a tight timeline and several rash decisions doomed us. Instead of showing management we could do this ourselves, it became blatantly obvious this project would not get completed without a ton of oversight and guidance from an experienced project manager.
It's all rainbows and unicorns when you think about it. "Just get some good developers together and they can get it done!" sounds so romantic, but in reality, it always ends up in a total shit show, as I experienced first hand. It was a tough lesson to learn that management actually do have a job to do and they understand a lot of stuff developers never have to worry about.
3 developers were advocating a total rewrite and a pivot to a different stack.
Those were not good developers; ie, there are some skills they were clearly lacking.
I've lived through the opposite situation as you: management left the company, and we continued to release for the next few months without any management at all.
The key, I think, was that the managers had pushed the decision making down. Everyone took turns being scrum master......so when the next sprint came, we elected a new scrum master and carried on.
Fred Brooks pointed out that with a group of competent programmers, any development methodology can work. The best development methodologies help programmers become self-sufficient (teaching them the skills if they don't have them), instead of trying to micro-manage.
> Those were not good developers; ie, there are some skills they were clearly lacking.
Ok, fine... I'll be that guy: No True Scotsman. If you define "good developers" as developers that can successfully create software without management, then yes a group of "good developers" can successfully create software without management.
When developers are trying to do Things You Should Never Do Part 1 ( http://www.joelonsoftware.com/articles/fog0000000069.html ), then it's fair to say that they are lacking some skills. I don't think you should call that a 'no true Scotswoman'
That's fair. I think the vague approach of "they were clearly lacking skills" was what triggered my response. In this case, there's a justifiable position there. But a lot of details could have changed, and that vague statement could still be blanket applied.
A "no true scotsman" argument would define good developers as developers who "don’t need velocity, daily stand ups, points estimations, spikes, scrum masters to deliver high quality software".
A different standard, such as not engaging in rash rewrites that disqualifies someone from the "good developer" category, would keep this from becoming a "no true scotsman" argument.
You didn't go through the opposite situation - the parent talks about shedding the Agile process and going for new ad-hoc methodology. You talk about simply electing a new scrum master, continuing business-as-usual.
You're actually supporting the GP's point, in that you had a good result due to maintaining good practices; 'good people' do not automatically make good software regardless of practice.
Part of the GGP's point was that management has a role to play, and that they know things developers don't. That is the conclusion I was responding to.
You are right too, of course, we still had a process.
Although those faux titles may be technically wrong, the use of capital-A Agile usually implies association with Agile the brand (the noun), not "agile as in agility".
> That is so catastrophically false that I don't even know where to start.
Doesn't sound like a great argument. The highest performing teams I've worked with were small groups of highly skilled, talented (IQ and EQ) and passionate people. These groups are usually familiar with various development methodologies and able to come to agreement on which processes to adopt and which are cargo-culty and should be thrown out. I don't think OP is arguing for zero process. In fact the opposite is clearly stated in the Agile Manifesto list: "They figure out the process that works for them and for the current problem they are working on."
Here's a much better articulated criticism on Agile that I enjoyed:
Corporate lawyer, actually. However, before I was a lawyer I was a dev, and I try to stay current.
Like any methodology, Agile has its time and its place. However, I have found that the vast majority of people who categorically write-off agile don't actually do it right - and I am not talking "no true scotsman" here. I am saying that they actually do fall into cargo-cult behavior.
This aside, small groups of highly skilled and talented people can develop and ship products - sure. Maintaining them is a different thing altogether. Adding features, adding localizations, porting to new OSes - let's be serious, these require formalized practices, especially as (now very financially successful) developers move up and out onto other things.
Software is a business. Businesses are alive. Like any living thing, they must continually adapt or they will die. As a result, Software itself is also a process. Unless there are some formalisms in that process, you don't have a sustainable business - you have a business that lives and dies with its core team. That is not an investment-grade business. Nor is it a long-term sustainable business.
The link you sent has interesting points and valuable criticisms, to be sure - but this section:
>1. Business-driven engineering.
Nearly everything in it is wrong. Seriously. All businesses are business driven - and if you want your engineering teams to be purely engineering driven - go into academia. This is not to say that business goals must ignore engineering concerns - they must address them and take them seriously - this is what talented business people do. But software, like any other business, is business-driven tautologically. Even when an engineering decision is so categorically important that it becomes its own goal - it has now become a business goal. To put it another way: a purely engineering decision has results that are pari passu with regard to business impacts. When an engineering decision is no longer pari passu with regard to its business impacts - meaning that the decision will have disparate impacts on the business depending on the route that is followed - it is no longer a purely engineering decision - it is a business decision. In order to be a good business, then, you must have someone technically competent to understand the impacts making these calls.
Accordingly, I strongly belief people complaint the avalid criticism -- having non-technical people calling the shots on engineering decisions that have business impacts when they do not have the ability to understand how the technical decisions have externalities and other impacts -- has been utterly conflated with criticisms of management methodology. Just because your PM is a chump doesn't mean we shouldn't have PMs. It means you should get a better PM.
It is an unfortunate reality that, for whatever reason (and there are several clear ones in my mind) software - which is a technical discipline, make no mistake - has so, so many technically unqualified people in management. Compare this to any other technical business discipline - medicine, structural engineering, energy, mining - and the people at the top are typically also technically qualified. Software as an industry has to stop acting like it is privileged beyond these other technical disciplines and realize that its problem is not that "decisions must be engineering driven" it is that business people must be technically competent - which is a wholly different assertion, and one that I stand by fully. I.e. - we don't do away with the managers. We make sure the managers are competent. This is so, so different.
Which, by the way, is why I am a lawyer who codes. I wouldn't hire me to be on a dev team, but I can tell you with all honesty that I can sit down with your team and understand at a non-theoretical level the engineering problems you are having and their impacts into part...
It is an unfortunate reality that, for whatever reason (and there are several clear ones in my mind) software - which is a technical discipline, make no mistake - has so, so many technically unqualified people in management
It seems obvious to me that he's referring to the dichotomy of management (top-down) versus engineering (bottom-up). I think most people understand that businesses are indeed businesses. The point is that some development methodologies commoditize engineering to such a level that engineering is disempowered. This limits potential for innovation. Innovation comes from both ends. For example, as an executive I can "ideate" a search engine faster than Google. How useful is that vision without being source by or informed by engineering innovation? Conversely, some nerd (endearing usage here) builds a new search algorithm and uses solely it to find episodes of Star Trek where Spock chastises Kirk. Not exactly serving shareholders. In a healthy organization, there's a balance between these units where both see the value the other brings.
I agree with your points about the need for managers to also be experienced (and sometimes elite) engineers. Although I'm not sure I would argue that case for Project Managers, specifically.
> The highest performing teams I've worked with were small groups of highly skilled, talented (IQ and EQ) and passionate people.
The best performing teams you were on were the highly-skilled ubermensch? That's cherry-picking, really. "We don't really need good management practices because the cream of the crop, in small numbers, do well without them"
It happens when people use the mod system to vote their position on a topic. I'm guilty of this, and I do think "agile", as a noun in quotation marks, has gone badly wrong.
A lot of us have just gotten really burned. It's immensely fair of people who do stand behind agile methods to object to the mischaracterization of agile as a set of micromanagement techniques. But to a lot of us, that is now our experience with "agile." A daily "standup" where a team lead (who often doesn't write code) asks for a progress report and follows it up questions about whether this means we'll still meet our deadlines, followed perhaps by questions about what we can do to make sure we still meet them. You're welcome to say that this isn't what agile intended, that it is a corruption. I'd agree, completely.
The real disagreement here will be whether "agile" methods are inherently unstable enough to invite this sort of corruption. The notion of daily standup is just so tempting for people who wish to micromanage, deny developers autonomy that can't be measured in daily increments, and apply deadline pressures. In many ways, they may be scratching their heads that the developers themselves proposed this arrangement, but ok, sure!
I just finished watching a game of thrones episode, evidently the plan here is to invite an outside army in, order your own army to stand down, have the outside army to put down a rebellion, ask them to leave, then reassume power? What could possibly go wrong?
I think if you are a small, close knit team, then having great people and no process works great. If you are trying to scale developer productivity as your team grows in size, then you need more structure, so yeah - I agree 100% with your point.
Note that I did not capitalize "agility", which is being used as a noun here. I think if I was going to write an article saying agile isn't a noun, I wouldn't use it as a noun in the article.
This is a bit overly simplistic. There are lots of bad ways to develop software, and a few good ways. Placing yourself in a vacuum with "good people" who insist on starting from scratch without learning from the failures and successes of others who came before them is not one of the good ways.
For the record, neither is dogmatic adherence to a methodology, but that can be useful as a learning exercise.
I'm with you. Got nothing against the word and think that it can be used appropriately, but 99% of the time, it's lazy gutter language intended to provoke and strengthen an argument on "toughness" grounds. e.g., "You fucking said that?" is interpreted a lot differently than "You really said that?"
> This post merely a reminder of the actual values mentioned in the Manifesto. I was inspired by this great talk: Agile is Dead (Long Live Agility) — Dave Thomas
The talk's title is hyperlinked to the same URL you give.
We have painting by numbers for those that cannot paint, and we have agile for those that cannot program or deliver projects. Oh, and agile (TM) really only exists to sell numerous books, conferences, and basically give useless managers and clients a hope in hell of producing something.
It's hard to take a post seriously when the author thinks project management methods didn't exist before 1999. This stuff has been going on since the 60s or earlier.
Q: What is the difference between a methodologist and a terrorist?
A: You can negotiate with a terrorist.
Methodologies are useful as tools used by developers to organize their work and make themselves more productive.
When methodologists enter the picture, the benefits are lost, because methodologists serve the methodology, not the developers' product.
All methodologies are eventually hijacked by methodologists. Some dev orgs are smart enough to avoid them or at least limit their influence. Mahmoud is clearly not working in one of them.
I think the rage is a bit over the top. I expected James Rolfe quotes... "Scrum is buffalo diarrhea!"
I don't mind the blowback against Agile, it and TDD have both entered cargo cult territory and a lot of the stricter implementations are just laughably naive and ineffective (Especially if there is a "Certified Scrum Master" involved). But to just say Agile and all the modern processes are bad is ridiculous.
It may be time to start having a discussion about what's next in software development wether that be Agile the next generation or something new. Channel the rage!
I personally think Kanban is the next step. It's certainly the next step where I work. All the things management loves, but without the silly sprint cycles. Much more fluid.
Whether it will be a better experience is yet to be seen.
Well it's now becoming acceptable English to verb nouns (a different transform), adjectivize verbs and nouns, and noun verbs. We have been doing this for centuries.
I run. (Verb)
I went on a run. (Noun)
I move at a fast run speed. (Adverb)
I went to the run start location. (Adjective)
That the constant turnover of technical concepts and terminology has accelerated the use of these transforms is not an issue special to Agile anything, nor does it imply anything about good or bad practices.
Keep your grammar nazi-isms out of my Agile critiques please!
I have seen some of the most excruciating fake-agile organizations you can imagine. I am 100% on board with efforts to criticize that.
But even the critics seem to get blinded by methodology. Methodology is only a second-order effect. The real issue is cultural and structural. If your culture is all about command and control, your agile methodologies will keep mysteriously not helping.
Debating methodology is quite beside the point. Some organizations are just structurally waterfall, deep in their bones, and can't be salvaged without massive social upheaval. You don't fix them by changing what people do, you fix them by changing how people define their relationships to the organization and each other.
There are places which call themselves agile and do shoddy short-term thinking all the time. You might want to embrace some waterfall here - processes over people so that priorities aren't changing by the minute. Story points and rigid velocity based forecasts so that we can cut scope and ship on time.
Then there are metrics-driven places with scrum masters and burn down charts and hour-long standups. Managers here want to actively manage, so they make themselves busy doing negative work. Here we can do less with processes and put more trust in people.
Agile is being used to mean both, depending on which side of the spectrum the person's frustration is. It all depends, right?
61 comments
[ 3.8 ms ] story [ 107 ms ] threadNot only is Agile still very valuable with lots of good lessons to teach us - this guy's complaints are technically wrong - his examples pertain to the use of the word as a verb or an adjective - not as a noun. And, to be fair, in the context of software, turning Agile into a verb is perfectly fair.
"Agile Master Alliance" - Adjective - it modifies "Master"
"How to Agile" - Verb.
"Agile Certificate" - Adjective. You could argue that it is a nominalization, but that is truly splitting hairs.
Let's put it another way: if this guy doesn't know what a [gerund](https://en.wikipedia.org/wiki/Gerund) is, or what [nominalization](https://en.wikipedia.org/wiki/Nominalization) is, that is not Agile's problem.
So, in the end, what is this guy's point, other than "get off my lawn"?
Edit/update:
Magdoub's point is this:
>You don’t need velocity, daily stand ups, points estimations, spikes, scrum masters to deliver high quality software. You just need good people.
That is so catastrophically false that I don't even know where to start. I mean, really sanity-blasting. Sure, maybe cargo-cult adherence to agile tenets is not going to help anyone, but throwing management methodology out the window and hoping that "good people" just somehow summon good software into being is comically naive.
Maybe so, but to play devil's advocate, it's Valve's entire business model.
Now, if I had to offer my 2 cents why it works at Valve and not others -- games are deeply creative. You actually want your engineers to go off in their own little world and somehow capture the sparks that fly. It's nearly impossible to do this with some sprint model ("OK guys, creative thinking sprint! let's go!").
To re-iterate, the reason why it doesn't work with games is sprints are output-driven yet the creative output is not so easy to capture in this manner. Its origin is mysterious and subject to "ah ha!" moments whenever/wherever. This is why games must instead focus on process (hire the best, let them do whatever) and take a hit on strict output-driven management.
Yet, the big dogs have been pushing one game out after another. For example, WoW got bought by Activision and they couldn't get new expansions out soon enough. One of the most popular MMOs, Ultima Online, was bought by EA and they immediately started their expansion line of junk and ruined the game. This wears down on the overall brand of the game. Ultimately, output-driven management of games is a sure way to lose the creativity and balance necessary to create a gem.
I'm long past the point of viewing them as a company selling software.
My point is, I don't think Valve is hiring average or below average people. Their process works for them because great people make any process work. Or maybe great people just make their own process, which is the most Agile-y of Agile things you can possibly do.
You have no idea how true this statement is. I was on a small project about a year ago, using Agile. Both mangers and a director quit within weeks. Our team basically became self sustaining. No PM's, no managers. Our team had no oversight and no captain to steer the ship. We were left to finish the project ourselves.
We had a team of 5 developers. We sat at lunch one day, bound and determined to show management we could do this without all the daily standups, agile tracking, burn down rates and stupid PM oversight.
I wanted to quit inside of two weeks. 3 developers were advocating a total rewrite and a pivot to a different stack. Myself and another developer just wanted to finish the app and get it shipped. Egos, a tight timeline and several rash decisions doomed us. Instead of showing management we could do this ourselves, it became blatantly obvious this project would not get completed without a ton of oversight and guidance from an experienced project manager.
It's all rainbows and unicorns when you think about it. "Just get some good developers together and they can get it done!" sounds so romantic, but in reality, it always ends up in a total shit show, as I experienced first hand. It was a tough lesson to learn that management actually do have a job to do and they understand a lot of stuff developers never have to worry about.
Those were not good developers; ie, there are some skills they were clearly lacking.
I've lived through the opposite situation as you: management left the company, and we continued to release for the next few months without any management at all.
The key, I think, was that the managers had pushed the decision making down. Everyone took turns being scrum master......so when the next sprint came, we elected a new scrum master and carried on.
Fred Brooks pointed out that with a group of competent programmers, any development methodology can work. The best development methodologies help programmers become self-sufficient (teaching them the skills if they don't have them), instead of trying to micro-manage.
Nailed it.
Ok, fine... I'll be that guy: No True Scotsman. If you define "good developers" as developers that can successfully create software without management, then yes a group of "good developers" can successfully create software without management.
Understandable. My comment was already getting to long, and I didn't have space to explain every detail.
BTW, if you feel members on your development team aren't capable of self-managing, this book is really good to help you develop those skills: http://www.amazon.com/Clean-Coder-Conduct-Professional-Progr...
Self-management is something every programmer should have in their skill-set.
(disclaimer: I wrote it :)
A different standard, such as not engaging in rash rewrites that disqualifies someone from the "good developer" category, would keep this from becoming a "no true scotsman" argument.
You're actually supporting the GP's point, in that you had a good result due to maintaining good practices; 'good people' do not automatically make good software regardless of practice.
Part of the GGP's point was that management has a role to play, and that they know things developers don't. That is the conclusion I was responding to.
You are right too, of course, we still had a process.
Although those faux titles may be technically wrong, the use of capital-A Agile usually implies association with Agile the brand (the noun), not "agile as in agility".
> That is so catastrophically false that I don't even know where to start.
Doesn't sound like a great argument. The highest performing teams I've worked with were small groups of highly skilled, talented (IQ and EQ) and passionate people. These groups are usually familiar with various development methodologies and able to come to agreement on which processes to adopt and which are cargo-culty and should be thrown out. I don't think OP is arguing for zero process. In fact the opposite is clearly stated in the Agile Manifesto list: "They figure out the process that works for them and for the current problem they are working on."
Here's a much better articulated criticism on Agile that I enjoyed:
https://michaelochurch.wordpress.com/2015/06/06/why-agile-an...
Like any methodology, Agile has its time and its place. However, I have found that the vast majority of people who categorically write-off agile don't actually do it right - and I am not talking "no true scotsman" here. I am saying that they actually do fall into cargo-cult behavior.
This aside, small groups of highly skilled and talented people can develop and ship products - sure. Maintaining them is a different thing altogether. Adding features, adding localizations, porting to new OSes - let's be serious, these require formalized practices, especially as (now very financially successful) developers move up and out onto other things.
Software is a business. Businesses are alive. Like any living thing, they must continually adapt or they will die. As a result, Software itself is also a process. Unless there are some formalisms in that process, you don't have a sustainable business - you have a business that lives and dies with its core team. That is not an investment-grade business. Nor is it a long-term sustainable business.
The link you sent has interesting points and valuable criticisms, to be sure - but this section:
>1. Business-driven engineering.
Nearly everything in it is wrong. Seriously. All businesses are business driven - and if you want your engineering teams to be purely engineering driven - go into academia. This is not to say that business goals must ignore engineering concerns - they must address them and take them seriously - this is what talented business people do. But software, like any other business, is business-driven tautologically. Even when an engineering decision is so categorically important that it becomes its own goal - it has now become a business goal. To put it another way: a purely engineering decision has results that are pari passu with regard to business impacts. When an engineering decision is no longer pari passu with regard to its business impacts - meaning that the decision will have disparate impacts on the business depending on the route that is followed - it is no longer a purely engineering decision - it is a business decision. In order to be a good business, then, you must have someone technically competent to understand the impacts making these calls.
Accordingly, I strongly belief people complaint the avalid criticism -- having non-technical people calling the shots on engineering decisions that have business impacts when they do not have the ability to understand how the technical decisions have externalities and other impacts -- has been utterly conflated with criticisms of management methodology. Just because your PM is a chump doesn't mean we shouldn't have PMs. It means you should get a better PM.
It is an unfortunate reality that, for whatever reason (and there are several clear ones in my mind) software - which is a technical discipline, make no mistake - has so, so many technically unqualified people in management. Compare this to any other technical business discipline - medicine, structural engineering, energy, mining - and the people at the top are typically also technically qualified. Software as an industry has to stop acting like it is privileged beyond these other technical disciplines and realize that its problem is not that "decisions must be engineering driven" it is that business people must be technically competent - which is a wholly different assertion, and one that I stand by fully. I.e. - we don't do away with the managers. We make sure the managers are competent. This is so, so different.
Which, by the way, is why I am a lawyer who codes. I wouldn't hire me to be on a dev team, but I can tell you with all honesty that I can sit down with your team and understand at a non-theoretical level the engineering problems you are having and their impacts into part...
What reasons?
I agree with your points about the need for managers to also be experienced (and sometimes elite) engineers. Although I'm not sure I would argue that case for Project Managers, specifically.
The best performing teams you were on were the highly-skilled ubermensch? That's cherry-picking, really. "We don't really need good management practices because the cream of the crop, in small numbers, do well without them"
A lot of us have just gotten really burned. It's immensely fair of people who do stand behind agile methods to object to the mischaracterization of agile as a set of micromanagement techniques. But to a lot of us, that is now our experience with "agile." A daily "standup" where a team lead (who often doesn't write code) asks for a progress report and follows it up questions about whether this means we'll still meet our deadlines, followed perhaps by questions about what we can do to make sure we still meet them. You're welcome to say that this isn't what agile intended, that it is a corruption. I'd agree, completely.
The real disagreement here will be whether "agile" methods are inherently unstable enough to invite this sort of corruption. The notion of daily standup is just so tempting for people who wish to micromanage, deny developers autonomy that can't be measured in daily increments, and apply deadline pressures. In many ways, they may be scratching their heads that the developers themselves proposed this arrangement, but ok, sure!
I just finished watching a game of thrones episode, evidently the plan here is to invite an outside army in, order your own army to stand down, have the outside army to put down a rebellion, ask them to leave, then reassume power? What could possibly go wrong?
I think if you are a small, close knit team, then having great people and no process works great. If you are trying to scale developer productivity as your team grows in size, then you need more structure, so yeah - I agree 100% with your point.
Note that I did not capitalize "agility", which is being used as a noun here. I think if I was going to write an article saying agile isn't a noun, I wouldn't use it as a noun in the article.
For the record, neither is dogmatic adherence to a methodology, but that can be useful as a learning exercise.
http://youtube.com/watch?v=a-BOSpxYJ9M
> This post merely a reminder of the actual values mentioned in the Manifesto. I was inspired by this great talk: Agile is Dead (Long Live Agility) — Dave Thomas
The talk's title is hyperlinked to the same URL you give.
The idea that programmers should be responsible for making decisions about projects, not management... that did not sit well with some.
Still doesn't.
It might be time to have another Manifesto saying the same thing under a different name.
(Mythical Man Month is a famous example. Tony Hoare also had some good thoughts on the topic: http://zoo.cs.yale.edu/classes/cs422/2014/bib/hoare81emperor... )
Methodologies are useful as tools used by developers to organize their work and make themselves more productive.
When methodologists enter the picture, the benefits are lost, because methodologists serve the methodology, not the developers' product.
All methodologies are eventually hijacked by methodologists. Some dev orgs are smart enough to avoid them or at least limit their influence. Mahmoud is clearly not working in one of them.
I don't mind the blowback against Agile, it and TDD have both entered cargo cult territory and a lot of the stricter implementations are just laughably naive and ineffective (Especially if there is a "Certified Scrum Master" involved). But to just say Agile and all the modern processes are bad is ridiculous.
It may be time to start having a discussion about what's next in software development wether that be Agile the next generation or something new. Channel the rage!
Whether it will be a better experience is yet to be seen.
I run. (Verb) I went on a run. (Noun) I move at a fast run speed. (Adverb) I went to the run start location. (Adjective)
That the constant turnover of technical concepts and terminology has accelerated the use of these transforms is not an issue special to Agile anything, nor does it imply anything about good or bad practices.
Keep your grammar nazi-isms out of my Agile critiques please!
But even the critics seem to get blinded by methodology. Methodology is only a second-order effect. The real issue is cultural and structural. If your culture is all about command and control, your agile methodologies will keep mysteriously not helping.
Debating methodology is quite beside the point. Some organizations are just structurally waterfall, deep in their bones, and can't be salvaged without massive social upheaval. You don't fix them by changing what people do, you fix them by changing how people define their relationships to the organization and each other.
Then there are metrics-driven places with scrum masters and burn down charts and hour-long standups. Managers here want to actively manage, so they make themselves busy doing negative work. Here we can do less with processes and put more trust in people.
Agile is being used to mean both, depending on which side of the spectrum the person's frustration is. It all depends, right?