Agile is not a Fucking Noun
medium.com
medium.com
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.
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 parts of the business that are not purely engineering based. This is what allows me to be - I hope - good at my job.
If you have a legal problem that relates to software - I am your guy. At least, I'd like to think so. I care about software deeply, and can tell you from experience that if you think that the lack of technical competence among PMs and scrum masters is bad - you have obviously never worked in law.
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.
(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... )
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.
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.
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.
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.
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.
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?
> 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.
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!
For the record, neither is dogmatic adherence to a methodology, but that can be useful as a learning exercise.