Well, let's see:
Extreme Programming (XP): created by Ron Jeffries, Kent Beck and Ward Cunningham - all developers.
The Agile Manifesto: written by seventeen developers (http://agilemanifesto.org/).
Scrum: created by two of the seventeen above.
Extreme Programming (XP): created by Ron Jeffries, Kent Beck and Ward Cunningham - all developers.
The Agile Manifesto: written by seventeen developers (http://agilemanifesto.org/).
Scrum: created by two of the seventeen above.
And I'd say it still isn't trivial given the number of places that fall short of the vision as expressed in the manifesto's values and principles.
I would agree, though, that things have changed as it has been sold. That was much less about what programmers wanted to happen, and much more about what managers were willing to buy from consultants.
It's mostly just vague. Moreover, "Individuals and interactions over processes and tools" is, IMHO, wrong, and has been used to justify de-prioritizing tooling improvements on the teams I've worked on (e.g. automated testing, BDD).
The interpretation was, I think, defensible, but the outcome wasn't. Human interaction is nice but it doesn't scale.
I think a large part of Agile's popularity is due to its vagueness. A bit like religion, people just assign their own meaning to it.
Thanks for introducing me to it :)
The people who created Agile were working with languages such as smalltalk that simply allowed you to create more functionality faster - which enabled Agile. For smart, experienced people working with tooling that allowed small teams to produce whole systems fast enough that business feedback was useful, Agile could be called obvious. However to the majority of the industry at the time, struggling with hugely complex and slow compiling languages with a large time cost per feature, Agile was not obvious - it was impossible. And that was about 99% of the industry at the time Agile evolved.
It was good times - I was creating entire systems as a one or two person team, which the competition would have taken 5-10 times longer to deliver.
The industry wide tooling has generally caught up though enabling the possibility of widespread Agile. However few people do it that well from the dozens of companies I've seen the inner workings of.
Another important point that just doesn't seem to be commonly discussed is that Agile works in the context of highly experienced developers, but has now been attempted by the wide majority. All the signatories that I'm aware of were career developers with decades of experience, and it worked for them. Most of the dysfunctional agile environments I've seen have come from lack of experience and the perspective it brings, combined with the empowering attitude that agile brings - they don't know what they don't know.
It's like Jazz improvisation in that the difference between mastery and cacaphony is hard to understand for beginners - and basically impossible to master without really a lot of experience.
And the reality is many/majority of developers are actually beginners!
Consider the huge range of skills required (language, libraries, os, networking, patterns & techniques, industry advancements, then general professional skills such as organisation and communication and time management, then economic understanding to apply these to the business domain etc, the list goes on and on). It basically takes most people 5-10 years to actually grasp the skillset, and then double that again to master it.
Combine this with the growth of the IT industry which means greater numbers joined recently and fewer numbers of more experienced people started decades ago, even if they are still working. Overall the ratios are terrible with the majority of people not having the level of mastery and perspective to deliver on the potential of Agile - so they are probably better off with more up front planning!
But the voices of the crowd are deafening these days.
On the topic about the growth of IT and training, I haven't seen much talk about a team structure closer to what NASA does with each engineer having a mentor. No company I've worked so far had that as a process, it happened organically sometimes but I think what hinders a lot of young professionals is finding someone who will make them learn faster. Personally I only had that feeling once and it was definitely the best 2 years of development in my career, would love to work more at companies which have something like this in place for engineers.