Agile Is Dead (Long Live Agility)
pragdave.me
pragdave.me
On that basis, methodology isn't that relevant.
I just watched a company apply SCRUM to apparently solve process problems and it just made things worse because the staff aren't disciplined or interested in what they do.
That's after five years of agile consultants and perpetual change.
If you want a manifesto with real values:
1. Fix shit when it goes wrong right away.
2. Tell people what you are doing.
3. Write everything down somewhere centrally that everyone can get to(tickets)
4. Have a rough vision and make sure people are working towards it. Don't plan the details too much.
5. Be opinionated. Someone's got to win an argument.
that's it.
That's a large part of what agility was/is about. The rest also matches up pretty well.
A vehicle for rats.
For ref, I've migrated to the side of thing where I get pulled in (Harry Tuttle style) to sort companies out after they've been pillaged by these asshats.
I don't think a missused word was ever reclaimed, in any language. But while you are on that path, can you do something about "hacker" too? (Or maybe you should start with the easier, less valuable "ordinary" and "literaly".)
My impression of the original Agile project (C2), from reading their wiki, was that it was an attempt to make their customer feel really bad that they were incapable of lasting a week without changing the requirements.
Also, didn't the project fail? Though, in a way where it actually got partially deployed.
And they should be hired; they're often perfectly competent programmers, testers, etc, just not so good at working effectively with this kind of agility.
I'll post it here again, without any of the other distracting things he said about verbs and so on. Just take a moment to think about what these steps actually mean:
- Find out where you are
- Take a small step towards your goal
- Adjust your understanding based on what you learned
- Repeat
...if you don't care, or can't be bothered, well, that's fine too (self reflection isn't easy); just realize that your own set of pedantic dogmatic rules is no better than any other Agile process set.
There are so many dogmas out there (Fail fast, MVP, Agile, Lean, etc) which all boil down to the same thing: Maximizing information gain and minimizing the cost of failure.
I'm planning on a blog post/email course/talk/something in the next few weeks but it's not quite ready yet.
Oh come on, you can't tease us like that! You have a duty to satisfy our curiosity now. :)
How can hangman with decision theory apply to software development?
I would also be thrilled to get my first signup. :)
I think this concept also describes the essence of "agile" well (along with the four points you quote).
It's new tech, just from the XIV century... It would be great if people were that up to date.
That's pretty much the #1 reason I find Scrum useful. It makes shit hurt. When introduced in a disfunctional organisation, it's basically a role-playing version of root cause analysis.
Of course, when implemented internally in a disfunctional organisation by people who are part of the problem, those issues will be swept under the rug and the problem will only get worse.
If an organisation doesn't want to change (including making the hard decision of firing the incompetent and undisciplined), not methodology will help.
And neither will your manifesto.
Yes, everything depends on having the right people and having them organise themselves (which is the very foundation of Scrum and most Agile methodologies). But in order to organise yourself it's helpful to use a clearly defined method instead of re-inventing the wheel.
Teams that fail with any Agile method are likely to fail at self-organising anyway.
No methodology solves the people problem, but some methods, particularly Scrum, are very good at identifying the exact nature of the people problem.
I think that's the point. Agile/Scrum is often just window dressing. If you have a good team then it will give you some nice things like frequent interim releases and a better idea of progress. But if you don't have staff who are interested, disciplined (and talented!) then you're screwed either way. And I've met a lot of staff who are not like this.
Frankly I'd rather that people had a mandatory five-year term in a disciplined team at one of the traditional, enterprise-class, quality focussed firms that demand good practice. I can work in whatever methodology you want, but that made me the software engineer I am today.
It has its dark corners like anywhere else, I'm willing to concede it may just have been the teams I worked with that were awesome, it's certainly not cool, I wouldn't want to spend my whole career working for them and (frankly) god help you if you let one of their salesman in the building... But I learned a lot about doing things right. And now I'm a freelancer without the massive organisational overhead so I get to do things fast and right.
I dunno, maybe a large traditional corp isn't the only answer, but some way of enforcing good practice on people for a while, like a boot camp, so that they can take some of it with them to environments where it's not enforced as rigidly.
My general rule of thumb for considering somebody good (or great) is his/her ability to recognize / to be upset about problems / to care about usability or correctness of the implemented business logic ... and to roll up their sleeves and simply fix it, even without confirmation. If you have such people on the team, then the team can self-organize, if not, then prepare for sprints and meetings.
Agile puts the focus on developers, but often the wrong people are management.
I'll add one point:
6. Don't punish (for various forms of "punishment") the people who pro-actively do these things.
http://martinfowler.com/bliki/SoftwareDevelopmentAttitude.ht...
In Fowler's terms, the intent of the original Agile Manifesto was EnablingAttitude, but the result of the term "Agile" in many environments has been DirectingAttitude. It's a nasty cognitive dissonance - that "Agile" has in many places become a heavy, clumsy, tool-driven process that gets in the way of developers rather than helping them work efficiently.
And I'm not saying this in the "just let us hack" mindset either, because I pretty much despise that sloppy, careless mentality. It doesn't work in environments larger than a few people, much less genuinely large projects. But process needs to be scaled to team size, talent, and risk tolerance. A broad-strokes "Agile" process that restricts competent teams is worse than useless.
There's a surprising low upper limit on the size of a closed-source codebase before which it becomes a lead weight. Why? Because large projects (beyond about 6 devs in 2 years) without modularity generate a lot of maintenance work. (Modular design is to pay that maintenance cost upfront, which most executives don't like.) Maintenance needs to be done well, but the only thing that motivates good people to do it (instead of hopping to another team, changing jobs, or demanding a $500k+ salary) is either (a) caring about the module as a client, which means they typically aren't more than 25%-time maintainers because their main project is whatever uses the module, or (b) the possibility of gaining a national reputation in OSS.
The open-source ecosystem can motivate the kind of work that large codebases need. (That doesn't mean they never turn to crap. It means that it's not inexorable.) Corporate codebases don't have that.
Twitter hasn't open-sourced, for one example, Storm because they're nice guys (not to rag on them; this is one of a million examples I could use). That may be a factor, but the main reason is that they don't want it to turn to crap, and the open-source ecosystem is more robust against that than anything in the closed-source world. If you rely on something but it's not extremely proprietary, you should probably open source it for its own health. Proprietary stuff should probably be kept as data, not code.
This. In my experience moving to small teams, service-oriented architecture, and semi-open allocation, the underlying problems of coordination were not solved. We had all sorts of issues coordinating API work and being blocked because one team's API was not performing up to par, but they were not fixing it because they had competing priorities. What ultimately helped get us moving again was getting a new engineering lead who had very good overall product judgement and could bang heads to get people on the same track.
If your app is intrinsically decoupled, then obviously small teams and SOA is a good idea. But if your app is inherently interconnected and requires coordination among complex pieces, then you are really choosing your poison either way.
Ultimately, I think the only proven solution for building high quality, complex software systems is to have Steve Jobs or another extremely talented and charismatic BDFL.
I would say that when you are within a project team it should emphasize the agile values but once you are on an organizational level where several project teams need to co-operate to deliver a product the constraints given to teams should be formalized over the right hand side, strongly, but in a way that is ready to take immediate feedback from the realities. Preferably, my dream system would be formed of strong spec based contracts between teams, enforced by automatic tools and architects, who work as part of feature teams implementing features and have the ownership of the spec-framework and can swiftly change it to respond to changes.
Completely forgoing specs and plans leads to anarchy and headache where the only two-channel communication with developers is facilitated by broken unit tests and system-test or (the horror) customer side regressions.
Good software systems are composed through a firmly kept set of as strong constraints as possible, IMO, and someone needs to own the constraints.
I think it is beneficial to have a plan in certain situations.
However, if you are not going to Follow a Plan, and while you're at it, you are attempting to Eliminate Waste as per the lean thinking movement, one may quickly follow with the conclusion that plans that are not followed are wasteful, and therefore unnecessary.
My experience has shown me that this is the interpretation people very often make. YMMV as always, though.
I agree with this. You create a plan so you have an idea when the project will finish, when resources will become free, when you deliver to other dependent teams etc. That doesn't mean the plan is cast in stone and once the Gantt Chart is finished, it never changes.
Obviously, you do what you can with scope, resource moving, etc to keep to original dates but if you can't, then the plan should be updated to reflect reality.
I'm going to steal this. Spot on.
"Plans are worthless, but planning is everything"
For all the points in the Agile Manifesto, the right hand term isn't bad at all. It's a good and important thing, but the left hand term is even more important. Plans and processes (in a large organization) are definitely important, but they should never trump change and people. Documentation is also important, just not as important as working code. Contract negotiation is unavoidably important in any business environment, but don't let it get in the way of cooperation.
I don't think being misled by snake oil salesmen is the only, or even the primary reason people get misdirected away from true agility toward 'agile'.
There are intrinsic motivations and interests in most human organizations which lead against actual agility.
A few of these include:
* The need for people in many positions to feel and be able to represent themselves as in control of the process and product;
* the desire to have someone else to blame when something goes wrong;
* the interest in shortcuts and magic bullets, instead of realizing how much work and time things will actually take (including from non-technical stakeholders).
There are social/organizational reasons that make true agility hard, especially in large organizations, especially in organizations where software dev/IT is just one component of a larger mission. But that doesn't change that actual agility is the only way to produce high-quality software efficiently. And we probably do need people investigating and suggesting how we overcome these barriers; but indeed, the 'agile' industry has not succeeded in doing so, they mostly take the easier path of figuring out how to cater to these barriers while calling it 'agile', instead of how to change organizational culture and surmount them.
Very worth reading entirely.
The place I balked, is where he said that design patterns are almost dead. I find design pattersn to be invaluable, and so does at Apple Computer and with them millions of developers, so the death of design patterns is a bit premature.
When someone mentions your name all the time, they're trying to sell you something, but what did it mean to mention other people's names all the time? If they're selling the message that they're Spolsky's close personal friend, it's hardly working.
I guess it lets you steal their page views if you summarize their post…
But other than that, I agree. What should be making our work easier has been turned into something complex by itself. Though in a sense, maybe that's unavoidable. Not everybody truly groks agility, so they have to be taught, which means training and certification. Although personally I think if you don't innately understand it, you can't learn it in a workshop either. Maybe you need to discover it through experience, and I know people who never will.
So where does that leave us? Only the people who grok agility should work this way, and those who don't should stick to something else? What about the companies who want the hip new buzzword, but also want to have some handle on the process they're using?
An agile process like Scrum definitely fills a need, but I've also learned that Scrum in one place can be totally different from Scrum in another place. Nobody completely follows all the ideas of Scrum, but maybe that's as it should be: adapt what you do to what you need. And there may be a limit to the amount of agility some companies can deal with.
Your knowledge of English programming is excellent, it is a rare and underrated skill. I can only recall one article on English coding posted on HN [0]. BTW love the double negative at the end.
The only programming languages I know of that use adjectives for their names are "Basic" and "Groovy". So this suggests when adjectives are used as nouns is a strong indicator of consultants flogging faulty processes and products for both development methodologies and programming languages alike.
But the idea that we should switch to a new word because the old one has been abused makes no sense. Why rally behind a word? Brands and labels only serve to stop people from thinking. They go against the whole idea.
Words become dogma. Hell, even principles become dogma. Trying to distill it down to something that's easy to digest robs it of its value.
The solution isn't a better dogma. It's people who can think. If you don't have the right people, no principle will save you.
You can. The question that you might ask is whether the plan is good or not.
You can't follow dogma
As above. Dogma actually has its uses. The trick is knowing how, where and when to use it, or someone who is dogmatic. Machiavellian, but its a tool nonetheless.
Saying we don't need a plan is to thumb our nose at thousands of years of wisdom. Sun Tzu was not stupid when he suggested choosing a path only once the objective and environment are understood. Stephen Covey puts the same concept into modern terms when he suggests beginning with the end in mind.
And that brings us to the disconnect we live in. Developing something using agile practices does not require a plan. A plan is however required at a level above the developer to steer development. As you go, you'll find yourself becoming interested in that plan more and more. It's a natural shift because the plan reflects the strategy, development is purely tactical. Understanding the strategy is motivational - it answers the why. Development is all about the how.
Real value as a developer only comes from experience. An experienced developer is successful in spite of any methodology, approach or framework, not because of it. Something else we're really good at blinding ourselves to.
Experience has no price. It amuses me to no end that we as an industry place higher value on the 20-something hacker than we do on the 50-something veteran. We're unintentionally letting culture hobble our chances of success.
I would not eschew a plan, but I would alter or abandon it when it's favorable to do so. I meant only to advocate pragmatism, not anarchy.
I'm a developer, but I have described myself as an agile consultant in the past.
This isn't out of cynically spotting an opportunity to make a buck. Its because I've spent a lot of time working in agile environments, learning the pitfalls and how to do it well, and want to share what I really and genuinely think is a better way to deliver software.
When vendors and consultants start to coallesce around an idea, it usually means that the idea is a good one that is gaining traction, coming down from the ivory tower. It's a positive thing and not something to leave the community that you founded over.
I've heard this argument many times over the years, and it always sticks in the throat a little. I'm evangelising an idea that I passionately believe in but am seen to be selling out the community ideals somehow. I walk the same line on my current venture in the DevOps space.
What was our mantra? "Design a little, code a little, test a little".
Agile re-invented or popularized various ideas that had been around for a long time. As always, you adjust for the problem at hand. Royce, the so-called inventor of waterfall (he presented it as an obviously flawed concept, a straw man), argued for copious documentation. Documentation makes a lot of sense when trying to built a jet-liner, and is often a time and money sink if you are trying to write, say, research code for computer vision.
So, "revolutionary"? I dunno? Certainly many places had taken the deliberately flawed Royce model as the way to do things, and so there was a big change as far as that goes. But I can't recall a time where some form of iterative/evolutionary development method was not known about and practiced, or where decision making was favored over process.
To make this clearer - the Royce-ers patted themselves on the back, and then got hopelessly entangled with process. Yourdon came along. Wow, was that a great process - which everyone got entangled with. Then there was Booch..... And now, we have Agile. The details vary, to be sure, but the fundamentals remain the same. Some good ideas for approaching engineering a solution gets turned into conferences, endless books and training, independent consultants, certifications, requirements to be certified to win contracts, and on and on.
I'm old.
That's not waterfall as used in the conventional sense. A key element of waterfall was/is: "Thus the waterfall model maintains that one should move to a phase only when its preceding phase is reviewed and verified."[1]
>The details vary, to be sure, but the fundamentals remain the same.
I disagree. Agile is distincly different at a fundamental level from waterfall. If you walk into a modern shop doing mostly agile with continuous delivery, you'll find that there is almost no process at all that maps directly to waterfall. Literally, not a single one: not design, not coding, not testing, not building, not deploying. They're all fundamentally very different. Coding is probably the one that comes closest and if the site uses TDD or pair programming, it will be clear how drastically different even that is. [1] https://en.wikipedia.org/wiki/Waterfall_model
That wikipedia article is a bit of a mess, but read the article at footnote 7:
http://www.idinews.com/waterfall.html
I was there. I was on those projects. They existed, and unless everything went perfectly according to plan, they were messes.
I always understood agile development as a way to organize your team and yourself in a way that works best for everyone. So don't follow a scheme, even if it's called agile, but think yourself.
Probably this is, how I WANT to understand it, because I don't like to follow rules that make me unproductive, even if others may become more productive by following the same rules.
Who does?
technically that was a syntax quibble though, so the joke doesn't work as well
I firmly believe that Agile is about doing what makes sense in this team right now. You let the team to decide on their process, on their way of work and get away. And for good managers this is enough - you are empowering your team to succeed.
Recently I had a great success demolishing standups in our team. We clearly weren't getting enough value from them (I though they were plainly hurting us), so it was time for change. I had a great resistance from the management team, but some developers were keen to try a change (some of them were long enough in the industry to remember the pre-agile days, when we were delivering software too). So we tried it for some time, everybody loved it, and we stopped doing it completely.
Now days we all agree that iterative development is the way forward. We should also think if we can apply the same on a meta level - the team, the process, the product, the design, the organization. Do small steps, check if you are going into the right direction, repeat. It may work :)
I'm on the fence with daily standup meetings. they definitely can help a team communicate when there are a large number of external forces at play in a larger organization and if there are no underlying asynchronous communication channels available. on the other hand, in a team that communicates regularly with historical communications available to new team members, they aren't as useful.
- Rarely the right information. Every person in the team have different needs for information. It is even harder to deliver the right amount and on the right level if your team includes designers, quality engineers, project/product managers.
- Rarely at the right time. If your company culture includes flexible hours, no matter at what time you put the standup somebody will suffer. Most of the time the team members who come early suffer - they already started work, now you are forcing them to get out of context and attend a meeting.
- Sometimes standups are used as a way to force some team members to do what they have promised (the what I'll do today). But if you are using them in this way is really counterproductive - you either trust that your peers are doing their best for the team or you might consider team change (which I understand is beyond our control sometimes).
- Failure to communicate (or "the what problems I have/had" part). If your team members are mature enough and they had a problem during the course of the day, they shouldn't wait for the next day's standup to let everybody know about that. The should be proactive and seek resolution as the problem comes up.
- Finally the "what I did yesterday" part. This information is commonly used by the managers, but there are better ways to deliver it. Most of us use some way of tracking our work. We only need to flow this information to our managers. It is also a mind shift for them - instead somebody pushing this information to them, they should be proactive and seek it and pull it. If you don't know what somebody is working on, then go and ask him. You don't need to loose the time of the whole team for this.
That being said whether you will use standups or not depends largely on your team dynamics. In new teams or teams formed largely by junior developers it makes sense to have standups - its a way to force communication patterns and certainly can be used as a casual form of a team building. But in my opinion as the team matures there is less and less need for standups, so at one point it just becomes a hurdle. And the good thing about being agile (not SCRUM) is that you can evaluate your process and change it as you (and your team) see it fit.
> - Rarely the right information.
You were doing it wrong: standups are not to give or receive information, just to inform the team what did you do yesterday, what are you doing to day and any blockers.
> - Rarely at the right time.
We schedule them 15 minutes before the first team member goes out for lunch (10:45 am), this forces a hard deadline.
> - Failure to communicate.
You should communicate blockers to your SCRUMMASTER immediately, the daily meeting is to remind him/her the blocker is still there.
> - Finally the "what I did yesterday" part.... If you don't know what somebody is working on, then go and ask him.
This is so wrong in so many ways. The SCRUMMASTER's job is to keep management off developers back and play interference so they can focus on getting the job done.
A stakeholder should NEVER be invited to talk directly to developers about what they are working on. If they want a daily status, they can attend the daily standup where they cannot talk, just listen. If they have questions, ask the scrummaster after the meeting.
The daily standup is a tradeoff, as SCRUMMASTER you promise the team they will not get dragged to any other meeting during the iteration.
However I still thank the Agile "industry and business" as it allowed me to open my eyes as a developer years ago.
Because believe it or not, some of the so called master/consultant are genuinely caring about the values behind the manifesto, and putting a lot of efforts into improving everyone practice of software development.
Also he wrote some quite good books, 'Pragmatic Thinking and Learning' come to mind. I don't think your comment is particularly fair, nor does it diminish the point he is making in any way even if you're right.
"Once the Manifesto became popular, the word agile became a magnet for anyone with points to espouse, hours to bill, or products to sell. It became a marketing term, co-opted to improve sales in the same way that words such as eco and natural are. A word that is abused in this way becomes useless—it stops having meaning as it transitions into a brand."
From his company's website:
http://pragprog.com/categories/practices
I think the callout is appropriate.
As to your point about whether they wrote any books on 'agile' I think it could be argued either way. More specifically, whether or not "The Pragmatic Programmer" (the book they made their name with) counts as a book about 'agile' is an interesting question, and one that throws some light on the wider debate.
Although they sometimes talk about "pragmatic programming" as if it were a thing, in the same way as XP and Scrum, their approach was more one of giving a smorgasbord of potentially useful techniques and practices rather than codifying a tightly defined set of best practices.
Agile to me is real: it has not been diluted as I know exactly how I will implement an agile process (scrum in my instance). I don't care if others misuse or misunderstand the term. For me it's concrete.
At a previous client, I was sitting next to a really nice poster that emphasized the difference between "doing agile" and "being agile". You don't "do" agile. That's simply not a thing. You have to be agile.
Working with more agility is totally fine. But if you do that, it means you won't be sticking blindly to your existing process, it means you should consider what you actually need from that process.
Basically, the process is recursive, but my explanation is more agile.
Changing the name to agility is only going to make everyone follow suit and convert that into a marketing buzzword.
1. Communication, communication, communication 2. Short iterations 3. Concrete deliverables 4. Client/customer engagement with deliverables
Everything else is details.
Life before death, strength before weakness, journey before destination.
Language is not an immutable thing and is always evolving in its use to reflect the concepts of the people using it. I think capitalizing Agile as a noun makes it a "thing" that we can refer to collectively and ultimately helps us communicate about the concepts that it entails. The unfortunate down-side is when a popular term is misused due to ignorance and misunderstanding by a large group of people - which will happen more prevalently as a word becomes popular.
As someone who has had the pleasure of receiving Scrum coaching from Jeff Sutherland, I can say that there is a HUGE difference in understanding between people who spend time to learn it (from a book or coach) and those who muddle their way through - never taking the time to learn about it more deeply and put it to practical use (the only way to truly learn is through doing).
I work at a small company and teach an internal course on the principles of Scrum to our project managers, so I have first-hand exposure here. It's amazing how really smart people who have heard the terms used for several years and even claim to have been involved in Scrum teams at past jobs still have many misconceptions about the core principles and how to practically apply them when the situation arises. There is definitely a shallow understanding amongst a good majority of developers and it's exacerbated by companies that claim to use "Agile" practices yet have only really scratched the surface. It's immediately clear that many have used "Scrum-but" and really only do standup meetings as if that will be all that is needed. Actually many people think Scrum is "that process where you hold standup meetings".
I like Scrum because it brings together not only a way to manage a project, but more importantly a way to lead a team of people! I think being a servant leader to the team and providing them the necessary resources to be at their peak effectiveness is a trait of a good leader. It's actually kind of amazing all the different ways even very smart people can get "stuck" - distracted by a less important task that is shiny and interesting, slog through hours of debugging to resolve an issue that someone else on the team could have helped them with, not communicating with other team members that they can't get their part done unless another has provided them something first. From experience, just helping people identify these blockers and get the team unstuck has been a big win.
I think tools absolutely are a big help too. I've used sticky notes on whiteboards and it's good for small teams that are co-located. It breaks down for distributed teams. We just started using JIRA and it is surprisingly good at helping us managing all of our work which would grow unwieldy using more primitive methods.
I'm not sure how I feel about the agile manifesto. I guess it has its historic place as a reaction against the poor waterfall practices of the past and paved the way for new methods to emerge. Besides that, it seems a bit dated and hasn't served a useful practical purpose for me.
I do think the word "Agile" is getting over-loaded (I recently had an talk with some folks at the GDS and it went sideways when we did not realise we meant different things). So the manifesto is useful just as a common reference point.
I am also glad someone else is saying "hey sticky notes and paper may not be so useful in a remote working world".
Admittedly I do love the methodology he espouses
What to do:
Find out where you are
Take a small step towards your goal
Adjust your understanding based on what you learned
Repeat
How to do it:
When faced with two of more alternatives that deliver roughly the same value, take the path that makes future change easier.Regarding the Agile manifesto. It seems like it's a relic of the past and perhaps that's why it's not included directly in the Scrum Rulebook. I haven't gotten any practical use out of it, and it seems to only confuse people who do not take a minute to interpret the wording at more than a superficial level.
You can't teach something to someone if their livelihood depends on them not knowing it.
For instance, if you start with an departments whose sole job is build software, and they make scrum teams that happen to have 5 people that only know the business, 3 testsrs that don't know how to write code, a dba who is the only person who can change DB structures, and 4 developers who do not talk to users, there is NO WAY you can make scrum work without major amounts of turnover. 13 team members is too many for a scrum. Scrum members have to be able to play multiple roles, even if they are only excellent at one of them. Otherwise, the team is not self organizing, and can't adapt to much.
Most large organizations around town that claim to do scrum follow that pattern, and the end result is that they are doing all the scrum ceremonies, but the teams are lumbering hulks of failure.
I agree with the article: Agility is more important than the process, and people have to carry agility with them. If your team is full of specialist that can't claim ownership of the totality of the team's output, there is no agility.
If it's really working for you and your team, that's great though. But there really isn't anything magic about Scrum. It's not the silver bullet many of it's proponents sell it as.
And not that I think this is worth anything, but I have learned it from a coach, I'm even a "certified Scrum Master (tm)", which again isn't worth anything, and I worked on a team where everyone was trained in Scrum, using a coach. It was arguably one of the least "Agile" teams I've worked on. Additionally, I've attended and even organized "Agile" conferences, both before and after working with that team.
I agree 100% with Dave.
If you like Scrum I think that's ok, I don't actually think it's a bad process, but in the hands of a mediocre team it's next to useless. However, in a lot of ways things like Scrum are anti-agile. Call it "Scrum" if you want to, but, and you're right, words do have meanings and "Agile" has been co-opted by these consultants for all the wrong reasons.
I was thinking this recently about agile. Lots of "agile" followers seem to advocate a lot of process SCRUM, or "always do TDD".
Does the Agile manifesto not say: "Individuals and interactions over processes and tools".
Basically these people are doing the opposite.
Since organizations are tough to change and all dysfunctions have champions (some deeply hidden) the "Agile" ends up having to make smaller and smaller motions while its desire for control, as the velocity in an irrotational vortex, gets stronger. Then it devolves into micromanagement, as discussed here: http://www.mountaingoatsoftware.com/blog/ssssh....agile-is-a...
The reality is that the future just has no use for closed-allocation tech companies. Every tech company needs to decide either to play for real and try to excel (open allocation, highly selective hiring) or GTFO and do something else.
Scrum is a formational hack, but closed allocation is a foundational problem and, if technical excellence is needed, a show-stopper.
There are plenty of companies putting out bad software, slowly but profitably. They occupy various niches where the people doing the selective hiring or being hired selectively just aren't interested in playing. Sure, they could be out-competed by an agile, well-staffed, disruptive new competitor. They could be, but they probably won't be.