Eventually it became a sort of a religion. If you question it, it's because you don't understand it; if it yields bad results, it's because you did it wrong; if it doesn't fit the dynamics of the rest of the company, it's because the company is immature. All the methods have known limitations and prerequisites. All but Agile, which is perfect.
It's a ridiculous lack of empiricism for a discipline like software engineering.
I feel that most people don't understand that larger corporations don't adopt Agile to benefit product teams, but to add a layer of measurability to the process that is only useful for middle and upper management to establish and track OKRs.
Thus Agile may not be a failed idea, but it arguably fails at the implementation.
Agile apologists seem to be disconnected from this reality.
> Individuals and interactions over processes and tools
> Working software over comprehensive documentation
> Customer collaboration over contract negotiation
> Responding to change over following a plan
But even the Manifesto has some points that make it impractical in many circumstances.
To stick with a single example: is it safe to favor customer collaboration over contract negotiation when dealing with high budget projects? Changes in requirements, delays, reprioritizing in client's side, those are all things we know that may happen. How are we going to deal with them after you favored customer collaboration, and that collaboration doesn't exist anymore?
Agile requires Trust. But trust is a fluid thing, and we must cope with its fluctuations.
The client is cooperating? Good, let's get a bit liberal about some rules, but let's keep monitoring the situation. The team is mature enough to self-manage? Good, let the team manage itself, but keep an eye to see if things are still running smoothly as the time goes by.
The biggest problem of Agile is that it takes Trust for granted and assumes that every single stakeholder wants the project to succeed, and shares the exact same definition of success.
Yes, but note that the client is inside the circle, not an external force, in Agile.
> Changes in requirements, delays, reprioritizing in client's side, those are all things we know that may happen.
Yes, that is specifically what the point deals with, on both sides. Favoring contract negotiation over collaboration is a very poor way of dealing with those things.
(The X over Y statements in the Manifesto are not X instead of Y, but Y must be centered on supporting X; contract negotiation is necessary, but the terms must be framed to support collaboration rather than impede it by being inflexible for the kinds of things that are known to be likely to change over the time of the project development.)
> How are we going to deal with them after you favored customer collaboration, and that collaboration doesn't exist anymore?
If the need for collaboration was centered in contract negotiation, then that will be addressed.
> The biggest problem of Agile is that it takes Trust for granted
The biggest problem (though far from only) problem of Agile is that the authors of the Manifesto underestimated the degree to which people would misread “over” as “instead of”, even given an explicit admonition that that reading was incorrect, making the Manifesto terse and catchy, but ineffective in communicating it's core ideas.
Indeed, and this is one of the points Agile gets furthest from real world.
Anecdote: I've worked for an average-sized bank with users who were cooperative but not that much. One day we were faced by an urgent legal requirement and the bank had to choose: either to halt operations or to adapt the software, otherwise our equivalent of a CFO would be arrested. The customer became an integral part of the team, we had extremely fast iterations and that was my first Agile project, and I didn't know it because I was going to hear first time about Agile only three years after that.
As soon as the legal requirement was met, things got back to normal.
That's what I talk about methodologies having to subject themselves to the environment. Agilists seem to dream about inverting things in this regard.
> The biggest problem (though far from only) problem of Agile is that the authors of the Manifesto underestimated the degree to which people would misread “over” as “instead of”, even given an explicit admonition that that reading was incorrect, making the Manifesto terse and catchy, but ineffective in communicating it's core ideas
I agree, but even avoiding the "instead of" interpretation, I believe the ideas in the Manifesto are only actionable under special conditions.
Each project is a different case and demands a different combination of agile/non-agile variables, it all depends on the environment it presents (customer behavior, team's maturity, project complexity etc)
It's one of the parts the Manifesto gets most right about the real world.
> That's what I talk about methodologies having to subject themselves to the environment. Agilists seem to dream about inverting things in this regard.
I don't know “Agilists” in any general sense, I do know that adapting methodology to the specific (and shifting over time on a single project/product) combination of team, context, and task is the central focus of the Agile Manifesto.
By all means collaborate, but put it in a contract too.
The key is understanding the upfront spec, while a necessary stating point, is almost certainly wrong, maybe fundamentally so. So how are renegotiations handled?
This is in itself a major point. Managers trying to put scrum on everything. This is my main hope for scrum passing away. I have seen it now several times companies deciding to use scrum for research projects, and after a year they all realize how bad of an idea that is.
On the other hand so far I haven't worked for a single company that actually did scrum (despite claiming it). They all started by "adjusting the process" and removing the scrum master. Sure. You totally understood how this works.
A lot of the criticism seems to form around the fact that people actually develop processes around agile, even though agile discourages processes. (And that those processes in the end become empty rituals that hinder development more than support it)
But couldn't this actually be a sign that people in fact need processes to get some kind of routine and system into their work?
Were the creators of Scrum hopefully trying to introduce flexibility in the guise of process, or cynically cashing in on a trend? I don't know; all I do know is that Big Software switched from $old_process to Scrum around 2010-2012, and medium-sized companies seemed to follow in the middle of the decade.
Somehow the things in the Agile Manifesto never popularized, only those religions did.
While I agree that that’s an issue, I would argue that it stems from the fact that dynamic ideas are opposed to pragmatic ones (at least in the minds of pragmatists).
Inevitably in companies there are voices that say “we should mitigate risk”, “let’s do what worked before”, and other things that boil down to “don’t change things because I’m not good with change”.
It’s those types of people who productize everything that gains momentum as it’s a cycle of “This new thing is a threat”, “They tried it and it worked, I better change my tone or I’ll be ostracized”, “How can this be made rigid and safe?” “Oh excellent, there’s a certification program now: time to crack down now that I have a whip.”. And as they spend more company money on making it “safe”, the market responds and makes more “safe” products.
The process itself is fine.
The issue is that the practitioners are none-too-adept managers and teams.
Making software is simply hard.
No amount of Scrum frameworks solves for staffing a project with a talent-less manager. Although Scrum does help for that scenario I'll be honest.
It seems to me that Scrum has "no true Scotsman" built right in to the model. If you criticize it, a Scrum practitioner can just reply "well, just adapt it to your needs then". Or if you hear of something too crazy a team is doing with Scrum because they adapted "well, they're not doing Scrum right".
I use the phrase “the illusion of predictability” a lot when I talk about Scrum. Sadly, some people really cling to that illusion despite overwhelming evidence that it isn’t real.
You need to use tools like OKRs and good old waterfall to manage multiple team projects.
Dealing with anything social, the rules don't self enforce - they aren't gravity.
It's not. Scrum is a training/introductory agile framework. There is an evolution to scrum built right into the framework that transforms it into not-scrum. The framework encourages moving from the initial (and what most orgs think is the final state of scrum) "Type A" where the team work in isolated timeboxes, with downtime between for planning etc. through "Type B" with preparation(s) for upcoming sprints, and feedback from previous sprints, overlapping the current sprint, to "Type C" with complete "just-in-time process" transformation where doing any given ceremony is done on-demand. And, crucially, it encourages evolving _beyond_ this.
Type C will be familiar to anyone practicing Kanban. Or dare I say, anyone with experience with "doing agile right" will have an experience matching what Type C describes.
The other teams would spend 6 weeks doing nothing but planning activities. After the planning was done, they'd do a 12 month dev cycle. Once that was done they would throw what they have over the fence for the QA cycle.
That is the world scrum was introduced to. People already thought planning and separate and couldn't be mixed. Scrum dragged them closer to interweaving them. People resisted, saying it was reckless and unprofessional. They looked at this and thought "so the plan is we don't plan anymore? we just wing it?".
I think Agile has won enough that perhaps many specific processes meant to bridge the gap are now dragging people away from being more Agile.
The root cause is that most people are honestly not too amazing at this corporate teamwork thing.
External frameworks like Scrum can improve things 10-20%, maybe.
Sure it talks about delivery, working software, and the like.
But a big motivator wasn't just "Craftsmen who want to do their craft more effectively", it was "Employees who are being abused by project managers, Gantt charts, and top-down waterfall death marches, who want to have sanity"
The part of 2-week sprints that says "deliver working software at the end" is just as important as the part that says "PMs can't introduce new scope into the sprint".
So the reality is It Depends on the company.
If you're lucky enough to be in a place where you have full control over your process to deliver software, Bottoms Up, Just-In-Time Process is the perfect attitude. But if management is enforcing archaic practices for no seemingly clear reason, the "rigid" nature of Scrum actually helps enforce a good way of doing things in a way that "traditional" management can reason about.
So how is it any better?
I found this truly sad. If you want accurate "velocity", you need to track it accurately. Our estimates were wrong.
Not sure what it was meant for, since with this practice it would tautologically just show headcount * days in a sprint. More like time reporting rather than measure of progress.
You alter estimation.
The fact story points are made up BS numbers means developers have full control over the velocity chart.
My favorite part of Scrum is it makes it IMPOSSIBLE to track velocity.
By making velocity IMPOSSIBLE to track, management MUST pivot to OKR lead management.
And OKR lead management is by far the best approach to software development.
Can you describe "OKR lead management"? I am familiar with OKRs.
I oversee (i.e. just making sure they're running well and on schedule) a bunch of different project teams and this is a frequent debate I have with the leads on those projects. If x and y is working for you, but z isn't, why don't you meet with your team and adjust z to make it work with the project and, more specifically, your personnel better? The response is almost always "But then it's not Scrum." They get in this mindset that if they don't follow the Scrum workflow to a T, then they're failing as leaders. That the workflow should be a rock that you beat your team against until they conform to it. It's a struggle backing them down from that edge and convincing them that Scrum doesn't work in all (many) cases, but a few minor tweaks to it will make your team function more effectively pretty easily. A lot of them struggle to accept that the "few minor tweaks" is always different between projects and teams, too.
Retros are essential for running an effective agile workflow, whether it be Scrum, Kanban, near-Scrum, or something else. You need to take a step back, view the process from the outside with your team, and figure out how to more effectively function going forward. Trying to appease the Scrum gods or your manager by adhering to every single character of Scrum as if it is scripture doesn't make any project better, in my opinion. Everything has to be flexible to some extent, including you, your team, and your processes.
> Retros are essential for running an effective agile workflow
if retros arent going to be effective at real improvement, then its better not to do them imo*
*there are other ways to improve teamwork/processes anyways
"What should we stop doing?" "This." (The retro.)
For example, the scrum model talks about a product owner. The cargo cultists insist that this needs to be a single person, with title of Product Owner. Yeech!
The reality is that the product owner could be a single person, or could model an entire organization that is developing requirements. What the scrum team needs is for these requirements to be made known to them in an orderly manner, and enough autonomy to have a reasonable discussion about them (how realistic they are, the cost, etc).
I've seen a lot of cargo cult scrum failures, and I've seen a lot of actual scrum successes. Over time, the cargo cultists have become the majority, though. That is a shame.
That's is. SCRUM is an emergency mode operation technique that might work to sort out standard things, definitively not creating something new.
I would argue that’s not the point at all. Instead I would argue that its point is short iterative simple process development based on constant stakeholder feedback.
I suggest that many undertaking “Scrum” are simply kidding themselves that their modern day process focussed development is “agile” at all. Heavy process iterative development preceded the “agile” movement and is back under a new name… “Scrum”.
It is interesting to go to the origins of scrum and its emphasis on the team and team-work for high-quality, low-cost product development.
> ...companies in Japan and the United States are using a holistic method — as in rugby, the ball gets passed within the team as it moves as a unit up the field. This holistic approach has six characteristics: built-in instability, self-organizing project teams, overlapping development phases, 'multilearning,' subtle control, and organizational transfer of learning. The six pieces fit together like a jigsaw puzzle, forming a fast flexible process for new product development.
A radical scruffy setup that challenges both the status quo and the leadership of an org rather than confirm to any set processes and workflows.
https://hbr.org/2016/04/the-secret-history-of-agile-innovati...
---
Some more snipped excerpts:
> ...under the new approach (in its extreme form) nonexperts undertake product development. They are encouraged to acquire the necessary knowledge and skills on the job. Unlike the experts, who cannot tolerate mistakes even 1% of the time, the nonexperts are willing to challenge the status quo. But to do so, they must accumulate knowledge from across all areas of management, across different levels of the organization, functional specializations, and even organizational boundaries. Such learning in breadth serves as the necessary condition for shared division of labor to function effectively.
> A project team consisting of members with varying functional specializations, thought processes, and behavior patterns carries out new product development. While selecting a diverse team is crucial, it isn’t until the members start to interact that cross-fertilization actually takes place.
> Selecting the right people for the project team while monitoring shifts in group dynamics and adding or dropping members when necessary. Creating an open work environment. Encouraging engineers to go out into the field and listen to what customers and dealers have to say. Establishing an evaluation and reward system based on group performance. Managing the differences in rhythm throughout the development process. Tolerating and anticipating mistakes. Encouraging suppliers to become self-organizing. Involving them early during design is a step in the right direction. But the project team should refrain from telling suppliers what to do.
> Headquarters' involvement is limited to providing guidance, money, and moral support at the outset. On a day-to-day basis, top management seldom intervenes; the team is free to set its own direction. In a way, top management acts as a venture capitalist. Or as one executive said, 'We open up our purse but keep our mouth closed.'
> Top management kicks off the development process by signaling a broad goal or a general strategic direction. It rarely hands out a clear-cut new product concept or a specific work plan.
> Starting with the guidelines set forth by top management, [the team begins] to establish their own goals and keep on elevating them throughout the development process. By pursuing what appear at first to be contradictory goals, they devise ways to override the status quo and make the big discovery.
I like the term "just-in-time process". A team should have only the processes in exactly the amounts that provide value to the team, and no more. If a daily standup is found to waste people's time, don't do it, or do it less often. If team members are found to need to do more coordination, maybe other avenues of communication could be encouraged?