The fundamental problem with Agile is the fundamental problem with all product development:
The customer doesn't know what they want
Agile assumes as a first principal that including the customer throughout the development process will align the building team and the customer to come to the same conclusion.
This is almost never actually true. Having built and managed a lot of products I can state fairly confidently that the amount of time the customer has, and clarity about the problem they want solved is orders of magnitude more ambiguous than is required to actually build and deliver something to their satisfaction.
In my opinion successful products, and I mean ones with significant flywheels with customers and viral growth and stickiness are with few exceptions - accidents. It was someone who had an interesting thought and a lot of people for whom the product was good enough for their desire that they often didn't even know they had
You can't write down how to do that, it's like asking a nobel prize winner how they came up with their discovery. It's not repeatable. Some people have better intuitions than others and these are the people who are repeatably successful with products. But it doesn't generalize.
That said, the fundamental problem isn't wrong in theory, it's just naiive in practice.
The agile manifesto was the problem. It's a vague as hell set of proscriptions that everybody could project their own ideas on to that got turned into a pseudo-religion.
I once had it used against me to justify not writing tests ("processes and tools!"). We had meetings about bugs instead. Seriously. Complain all you like about perversion, that was a perfectly valid interpretation coz those hallowed commandments are, frankly, ill-defined bollocks.
The principles are better but still suffer the same problem. If the most efficient way to convey information in a dev team is face to face why don't you come over here and I'll whisper my pull request in your ear. Jesus.
There's no point complaining about the perversion of a thing that was never very specific about what it wanted to be in the first place.
Once people (especially managers) get specific about what agile means to them it turns out it means very different things to different people. This is entirely the fault of the originators.
One benefit of Scrum (the catholic church to agile's christian sect) was that it was proscriptive and was specific. Unfortunately it's also a bit shit and its practitioner-priests LOVE to tell you that if it isnt working, well, You Probably Just Weren't Doing It Correctly.
>The agile manifesto was the problem. It's a vague as hell set of proscriptions that everybody could project their own ideas on to that got turned into a pseudo-religion.
thank you, Thank You, THANK YOU!
It is a useless set of vague platitudes which offered nothing but a sense of seeming aphoristic depth. How so many people fell for it is still a mystery to me. Instead of focusing on the core problem of Requirements gathering and Software Specification, well known trial-and-error approaches were dressed up as something profound and a whole industry was created out of thin air. People seem to have forgotten the works of Fred Brooks/Barry Boehm and that their iterative "Spiral Model" IS Agile. There is nothing new i could find in the "modern" Agile/Scrum movement except mindless emphasis on Processes/Tools which is insanity, eg; The position of "Scrum Master" is the very definition of a "Bullshit Job" and should be abolished forthwith.
> the core problem of _Requirements gathering and Software Specification_
Where I work there was a huge shift in this.
From Business analysts (BA), who usually had comp sci or engineering degrees, and an expectation to get PMP and CBAP / PMI-PBA / other BA certification to move up, were responsible for requirements.
Now we have product managers and scrum masters with a 1-3 day agile certification and no comp sci or engineering background who are responsible for requirements.
Over the years we have developed the policy that it is important for the supervisor to thoroughly know and understand the work of his group. A debate on this has been carried on by management people for years. Some say you can be a good manager without having the slightest idea of what you are trying to manage, that the techniques of management are all important. There are many organizations which work that way. I don't argue that the job can't be done that way but I do argue strongly that the best job can be done when the manager or supervisor has a real and genuine understanding of his group's work. I don't see how a person can even understand what proper standards are and what performance is required unless he does understand in some detail the very specific nature of the work he is trying to supervise. We have held closely to this philosophy and we intend to continue to do so. We expect you who are supervising to learn techniques of supervision and keep up to date. I want to emphasize you can supervise best when you know a great deal about the work you are supervising and when you know the techniques of supervision as well.
> It's a vague as hell set of proscriptions that everybody could project their own ideas on to that got turned into a pseudo-religion.
Then you're just complaining about the nature of language, because people do the same thing with religious text, literary text, the law, contracts, even daily conversations and flirtations. This is hardly a point that you can hold against the Agile manifesto.
> I once had it used against me to justify not writing tests
If you thought of your work as a complex system where there are a lot of variables which have multiple underlying causes, then you would have been able to describe some undesirable effect as being heavily caused by not having writing tests. And really, this is why people don't get Agile--they don't see their work and their organization as a complex system.
>Then you're just complaining about the nature of language, because people do the same thing with religious text, literary text, the law, contracts, even daily conversations and flirtations. This is hardly a point that you can hold against the Agile manifesto.
Funnily enough the features of language which are ideally suited for flirtation and writing poetry and preaching religion or nationalism and other such "let your fantasy go wild and fill in the gaps" uses of language aren't as appropriate when you're doing engineering.
Law and contracts ARE different (more like engineering), incidentally. What is described as "legalese" actually exists because non-legal equivalent language is often insufficiently precise and subject to dangerous and costly misinterpretation. Mathematical discussion has the same problem to such an extreme degree that it's almost pointless using English at all most of the time.
>And really, this is why people don't get Agile
The reason people say "people don't get Agile" is because they don't get that when the manifesto flirted with them it encouraged them to fill in the gaps with their own idealized version of software development that wasn't necessarily shared by everyone else.
> aren't as appropriate when you're doing engineering
Yeah but that's not the point that I'm making, is it? What I'm saying is that people project their own meanings into language all the time regardless of whether the language is being used in deeply personal interactions or in professional settings; therefore you can't just fault the Agile manifesto for its supposed "ambiguity".
On the point re: how laws and contracts are different -- sure, these things have gotten more precise over time, but if the language of law was inherently precise then we wouldn't have a need for judges and courts and congresses. Heck, even mathematics isn't safe from the problem of the imprecision of language. Wasn't there a time just in the last year or two when people were debating about the correctness of the statement, "one plus one always equals two"?
Which, really, brings us to the ultimate question, which also happens to be my response to your last sentence:
> The reason people say "people don't get Agile" is because they don't get that when the manifesto flirted with them it encouraged them to fill in the gaps with their own idealized version of software development that wasn't necessarily shared by everyone else.
So then is it a problem with the manifesto or with the people?
>Yeah but that's not the point that I'm making, is it? What I'm saying is that people project their own meanings into language all the time
That was MY point.
>therefore you can't just fault the Agile manifesto for its supposed "ambiguity".
You absolutely can. They didn't have to write it in an obtuse, ambiguous and metaphorical way that practically required people to project their own meaning. They deliberately chose to.
Scrum is a clear example of a methodology that is relatively (not completely) unambiguous. It's describing (in theory) a much more concrete form of "aspirational agile" and as such is at a lower risk of becoming all religious.
>On the point re: how laws and contracts are different -- sure, these things have gotten more precise over time, but if the language of law was inherently precise then we wouldn't have a need for judges and courts and congresses. Heck, even mathematics isn't safe from the problem of the imprecision of language. Wasn't there a time just in the last year or two when people were debating about the correctness of the statement, "one plus one always equals two"?
It's a sliding scale. Flirting and poetry is way over on the far left with the agile manifesto. Scrum is further to the right. Legalese is further still to the right. Math further still. It's fairly self-evident that the level of specificity required in the language used varies depending on the task. Being too specific when you flirt is common sitcom grist and nobody's ever made poetry out of a shopping list.
>Which, really, brings us to the ultimate question, which also happens to be my response to your last sentence: So then is it a problem with the manifesto or with the people?
>It's a sliding scale. Flirting and poetry is way over on the far left with the agile manifesto. Scrum is further to the right. Legalese is further still to the right. Math further still. It's fairly self-evident that the level of specificity required in the language used varies depending on the task. Being too specific when you flirt is common sitcom grist and nobody's ever made poetry out of a shopping list.
I think that you fundamentally misunderstand the purpose of the Agile manifesto. It’s not meant to be an algorithm or a highly specific set of instructions—it’s really just a collection of values that are meant to be the foundations of specific Agile frameworks, like Scrum. If you have trouble understanding that, then you must have trouble understanding the difference between Mission-Vision statements and KPIs.
You also belittle scrum for becoming too specific.
Seems you’re still processing what to make of any of it.
Knowledge work is immaterial and should have no prescribed rails or all you get is run of the mill outputs.
It’s similar to business; billions have been spent investigating what technology or management style brought the biggest gains. The math quickly becomes so Byzantine there no meaningful conclusions.
No matter how detailed our consciousness will let us imagine, there’s still one reality ruled by physics. Esoteric math may be correct in that it has the order of operations right, but that truth doesn’t give it any real influence on physical reality.
Yes they were. The cynical side of me says that this was because they were purposefully trying to create a rallying cry or something akin to a religion to better sell their wares and were unconcerned about the fallout that would ensue.
The less cynical side of me says they did it because they came up with "extreme programming" and knew that a lot of it was kind of bullshit, disagreed with each other on the details, but wanted some way to push people in "that sort of direction".
The net result either way was... well, a kind of religion.
>You also belittle scrum for becoming too specific.
No, I didn't belittle scrum for being specific. It's one of the good things about it. It is, however, a specifically defined bad way of running a team. We do need designed processes as specific as scrum, that are less one-size-fits-all and that have a more systematic and refined approach to software quality, estimation and design.
"Scrumban" is definitely an improvement, but even that is still lacking.
I'd like to see software team processes treated in many respects as a kind of "software to run teams", specifically meaning:
* That it gets iterated frequently and responds to feedback at every level (not just team, but philosophically - by its founders).
* That it's clearly and precisely defined.
* That there are a variety of different config switches depending on circumstances (e.g. number of people, skill distribution, are you building CRM or flying space rockets, etc.).
* That the individual pieces (e.g. retros, sprint planning) can be chopped and changed and upgraded/iterated on individually and yet still couple to each other sensibly - akin to the UNIX philosophy.
>Knowledge work is immaterial and should have no prescribed rails
>this was because they were purposefully trying to create a rallying cry or something akin to a religion to better sell their wares
> they came up with "extreme programming" and knew that a lot of it was kind of bullshit, disagreed with each other on the details
Money quotes!
I had attended a presentation by Kent Beck on "eXtreme Programming" well before the Agile/Scrum movement started and came away with the exact sentiments listed above.
>But you would further impose problem solving constraints on others thought work.
I would, yes. I've worked with a diversity of methodologies and several times with no explicit methodology all and in a team context we ended up a disorganized mess.
You might try to accept the rest of us don’t jump through the hoops of having a financially thriving job for you.
It’s not to bring order to chaos. It’s to afford shelter, food, and healthcare.
Sorry, not sorry.
Perhaps you’d be happier living as a hermit, where you can organize as you wish; everything just so! without the rest of humanity, that does quite a bit of the heavy lifting for you, interfering.
I think the way the Manifesto and early community around it lent itself to this inversion is this:
(1) The Manifesto is written in non-actionable terms.
(2) Many of the same people that initially attached themselves to the manifesto were already pitching canned processes, that may have been the outcome of agile process where they originated but did not put the critical feedback mechanisms more prominently than the low-level processes. So, those became the actionable versions of “Agile”.
It would be so much better if instead of the “X over Y” language, the Manifesto has spent a few words talking about how the less important things were subordinated to the more important ones.
The weird thing is that continuous, bottom-up, empirically-based process improvement wasn't an unknown concept at the time the Manifesto was written. It wouldn't have been hard for it to reference more concrete, actionable, concepts and practices.
The existence of coaches and scrum masters is the result of decisions of management, that see agile as a way of getting daily reports from the team through the daily standup.
I don’t think that people who don't write or never wrote software should have a place in a software development team. We don’t allow scrum masters and agile coaches in hospitals and ask them to “improve the process”, because we know the only “improvement” we will get is millions of dead and injured. But for whatever reason we allow freshly minted certified scrum masters to lecture seasoned professionals on process, to organise 19 meetings a day to discuss the differences between scrum and agile and, in general, to unleash havoc and destruction.
This is exactly what drove me off my last team. We were seasoned developers with a combined experience of more than 50 years, 25 of them in scrum. And we were assigned a scrum master that never worked in software development before, fresh of the scrum master training and was telling us in a very condescending tone, how we could improve ourselves and our team. That guy didn't know anything about software development, not anything about our problem domain and nothing really about our client or users. It was ridiculous.
The consultant that comes into your company decides to start by applying scrum to software development teams. Leadership likes this new approach and expands it to other departments. Now you have scrum masters who were previously accountants, marketers, HR, and other business domain experts. Consultant decides that it’s in the scrum coaching team’s best interest to let the scrum masters determine where they are placed. Scrum masters want to work on software because other companies pay more. All scrum masters converge to become involved in software teams.
> We don’t allow scrum masters and agile coaches in hospitals
They're not called scrum masters but the healthcare industry is absolutely full of them. One peculiar thing about the covid crisis was, at least around this particular corner of the planet, in the all-hands-on-deck situation where everyone on the floor in healthcare had to help out, these people suddenly found other things to do. It was impressive to see what could be accomplished when everyone was focused on a singular goal, without a coach in sight. I'm sure there's a lesson there somewhere.
> I'm sure there's a lesson there somewhere.
There sure is: Having one goal and being able to allocate all/most resources towards that goal. The problem is that this is not sustainable. Times of crisis usually ends and then what? Then we are back at square one with "How do we allocate our scarse resources between these really important 4-5 goals?"
Concluding: It is certainly refreshing how efficient groups can be once a crisis forces all attention towards one single goal. (Perhaps unfortuntately) that is not a reliable (crisises are usually not predictable) nor sustainable (other goals tend to get neglected in crisis mode).
A fair number of hospitals have been taken over by MBAs. The result is generally more money for the administration, and cost-cutting elsewhere.
Since the purpose of a hospital is not to make money but to improve health-related outcomes, this is usually bad.
On the other hand, it turns out that focus on improving health-related outcomes by applying science and statistics works really well... and usually decreases costs, too.
> I don’t think that people who don't write or never wrote software should have a place in a software development team
This is no guarantee any more. Newly minted managers coming from a development position that have only ever worked in dysfunctional organisations (and got promoted from within) will only reinforce the existing bad practices.
My hospital had them 10 years ago. Leaving is, second to marrying my wife, the best decision I ever made. Hospitals are, much to my sincere regret, not able to attract much talent in IT. Mediocrity is the best you can hope for, and I wouldn't even count on that.
It is the same as the government IT problem: if you can make much more money in private practice, why would you work at a hospital or government? Selling software to the hospitals or government is a better deal.
It's easy to blame management because developers and engineers haven't the foggiest idea what management actually does.
Instead of engaging with that problem, they retreat to themselves where they hiss the name management in dark corners.
Fact is: Developers are incapable of self organising, and would drown overnight without management's stiff hand.
I absolutely hate how accurate that is because I always thought I was a big boy and I wouldn't need management if I just had "1 good tech idea".
Docker had the philosophy.
Now they are dying after losing the container wars. That's what happens when you have no idea what a product actually is...
>but insist to intercept every decision
Yes, because left to our own devices, developers will not contribute meaningful business value.
There is a better way, evidently it's not agile, but it needs management's buy in, because well they're in charge (get over it in all honestly, none of us actually want the job, trust me).
WE as engineers need to find a better way to engage management.
But those of you who just grumble "management ruin everything" deserve the pain that such a divide causes and we need to stop wasting lifeboat's on that mentality please
> Fact is: Developers are incapable of self organising, and would drown overnight without management's stiff hand.
I beg to differ.
A dev team doing agile, with a team leader who is a manager/dev, can definitely self-organise. The team leader interfaces with non-dev management, removes roadblocks, and in collaboration with the rest of the devs sets the direction for a sprint.
You need this team lader role to keep the suits off your back, and to ensure the demands are achievable.
Project managers used to be people who wandered around with GANTT charts, and signed-off expenses and timesheets. Very rarely, I worked with a PM who saw their role as removing roadblocks, and shielding devs from suits. Those few PMs were a delight to work with (this was long before the appearance of Agile etc.)
> Yes, because left to our own devices, developers will not contribute meaningful business value.
I think that's rather obvious; management runs the business and sells the products. They set the business objectives, and there has to be clear communication between the devs and management, otherwise you get the "rewrite it all in X" syndrome.
> I think that's rather obvious; management runs the business and sells the products. They set the business objectives, and there has to be clear communication between the devs and management, otherwise you get the "rewrite it all in X" syndrome.
That’s a view in many large corporates. However, in product focused companies and many startups every developer has to have a customer focused mind. Every single day.
I think you'll find that view in any smoothly-running business with an eye on the future - not just large corporations. Unless the management are the devs.
We have to specialise at some point - not everybody that gets hired is going to be an ace industrial strategist. Few devs know how to qualify a sales prospect. If you have such people in management, then as a dev I don't want to do their job for them; they should set strategy and find good customers.
I guess we all have differing perspectives on this kind of thing; one's perspective is partly formed by one's experiences.
I'm not talking about startups - I never worked in one. But I've worked for quite a few companies with < 20 staff.
I've found the opposite to be true. Management is what chases the quick buck and not the long term scalability of more money.
When I first started we would be doing 1-off feature requests "because the client would _really_ like it". Everything was justified because money and because "we cant afford to lose that customer!" in our SaaS product.
I saw our main product being neglected because we'd invest so much time in these 1 off features only 1 client would use. All we would ever do would be client features, I was going crazy. It took a lot of talking, and still to this day I have to get him to think in terms of the product instead of the individual client.
Now we make more money, have more clients, and better our product for everyone which in turn gets more clients to get more money.
Doing 1 or 2 features at a time to make 1 client happy or win one deal is called consulting. Not that there's anything wrong with consulting: consulting can be quite lucrative and fulfilling but mistaking it for "product" work is responsible for some large X% of small/early startups failing.
> Fact is: Developers are incapable of self organising, and would drown overnight without management's stiff hand.
Open source does self-organise, and manages to produce some products of exceptional quality. It’s just almost completely unsteerable.
In a company, you can pretend to order people around. But the truth is that what really matters is how all the personal and political goals happen to align.
I think the difference is having a leader vs shepherds. Most open source projects have shepherds who do a lot of invisible work.
The project I work on has around 100 regular contributors, but also a few small teams, either volunteer or staff, who meet regularly and make sure things move forward in a coherent and sustainable way.
> Fact is: Developers are incapable of self organising, and would drown overnight without management's stiff hand.
If that's true in an organization, its only because either management has failed to hire developers that can self organize, or management has constructed structures and incentives which inhibit self-organization by developers. Usually, both. Often deliberately, because line managers are often more comfortable passively recieving directives from above and crafting directives for below than any other mechanism of management, since this minimizes conflicts with those in organizational power positions.
If developers were given Operational Research and a couple management classes during university training, the pretense that they are some kind of highly functioning idiots would evaporate overnight.
Problem is that the industry is full of untrained individuals who hustled their way ”fake it until you make it” and will use all their political and manipulatoy clout to justify their positions and fight back any attempt at effective process engineering.
There is probably some truth in all of that (although I strongly disagree in some specific points), but also consider that if "management" is incapable to convey their own value, and to cooperate with "engineers" in a non-antagonizing way, maybe they share some of the responsibilities in the divide... esp. if they are supposed to be "management" and take care of rational things (business value being an obviously rational one...) while engineers are basically... playing with their toys?
I don't understand how your vision of things is not also contributory to a strong divide.
You can also flip that around. As much as devs try to disagree, technology is not a goal in of itself. Management is an abstraction on top of money in/money out and if in<out it doesn’t matter if you have the crispest tech, you’re going out of business.
I’ve seen countless systems built where technology choices where more exciting than economical. Why build something in c# on top of SQL-server in six months when it can be done in three years with micro services, Kotlin, Cassandra, Kafka, mongoDb etc…
For real. That why I’ve focused my consulting on pure Microsoft stack at insurance companies. My knowledge _acumulates_ for each assignment, rather than having to start over with the tech du jour.
Get to rewrite the micro services, Kotlin, Cassandra, Kafka, mongoDb hardly documented, back into C# on top of SQL Server when the teams have left for the new jobs after haved pimped up their CV.
To be fair, this can also be because one random developer suggests this, management hears a fancy new term for their buzzword bingo, and they decree that that tech shall henceforth be used.
Management in turn doesn't pay any attention whatsoever to the technology. They have no idea how quality and productivity is influenced by outdated or poor choices or simply a lack of investment into maintenance.
You need people that care about the how you do it as much about the why and the what. Everything else is going to be disfunctional rather soon.
It’s part of your job to explain that to them. And you have to do it in business terms, that is, how it will impact budget and schedule for the project. And prepare for questions like “ok, you have convinced me that Kotlin is superior to Java, but you are the only one in the team with any Kotlin experience, and we have a rather hard deadline for this project in 9 months. Are you hundred percent sure that we will both manage to train the team and deliver in that timeframe? And you know Karl, who’s retiring in a few years, he doesn’t seem to be very eager to learn something new. And he’s a damn productive Java programmer.”
When I hear “we need to rewrite this in…”, it's usually because someone isn't familiar with the language it's currently in and wants to switch to the old language/framework they like best. I don't think I've ever actually heard someone trying to advocate for shiny new x just because.
It’s a constant daily struggle to explain technology experts that inferior technology with superior business/customer/product results can be prioritised over superior technology with inferior business/customer/product results.
I'm all for shitting on the JS ecosystem, but honestly there haven't been any noticeable shifts whatsoever in its ecosystem for at least 6 or 7 years now.
Both React and Vue.js are now older than jQuery was when both were released. Same for Babel and Webpack. Typescript is older than all of these. SASS/SCSS also older than Typescript. Those are the only things you see in 99% of the frontend job descriptions out there.
If anything, frontend is kinda boring, and it can be argued that some of those tools above need some disruption.
The track record for compatibility in the tools I mentioned is extremely good. Even when new approaches were launched (Hooks, Composition in Vue), backwards compatibility was kept. You can even mix and match approaches in the same app. Of course there's Angular, but that's the exception to the rule.
Heck, Microsoft has completely changed the way of writing native Windows apps in the last 10 years more ways than Javascript frameworks have introduced new stuff. Apple even changed the language to one that (unlike Typescript) is not backwards compatible. Complaining about the JS ecosystem evolving too fast is anachronistic, that happened more than 8 years ago.
> Heck, Microsoft has completely changed the way of writing native Windows apps in the last 10 years more ways than Javascript frameworks have introduced new stuff.
No they haven't. You still write them in Delphi or Free Pascal / Lazarus just the same way you did ten years ago.
Oh, you meant "the way of writing native Windows apps" with Microsoft tools? Yeah, well... Heard the old joke about the guy who complains, "Doctor, doctor, it hurts when I do this!"? My answer is the same as the doctor's: Well, don't do that then.
It’s easy to blame management but there are also good reasons for it.
The naïve thing to do when you’re a manager is to manage more in response to problems. When you start out with an agile process, and you manage more / manage harder, you end up with no agile process at all.
Scrum masters / agile coaches are very hit or miss. Just like managers, just like programmers. Management takes the blame because their failures have a larger blast radius.
There’s a fascinating talk by Dave Thomas, one of the authors of the agile manifesto, speaking of the simple meaning of the manifesto and the insanity of the Agile Industrial Complex bureaucratic cult created around it.
The Agile Manifesto never came out and said so, but it only ever made any sense if you give up the idea of a fixed delivery date. Of course, the idea of a fixed delivery date for a software project never made sense in the first place, but you’ll have to pry that nonsense from their cold dead hands. Big-A “Agile” is an attempt to keep what they (think they) want… so it ends up being useless.
Or you can have a fixed delivery date, but not a fixed feature set. If a feature isn't ready by the release date, it gets pushed to the next release. If you deliver often as agile encourages, this is a fairly short delay.
This reeks of “no true scotsman” to me. They claim is the manifesto, but the author even makes the claim that his process allowed engineers “a month of time without management intervention (a sprint length of 4 weeks). The author being one of the original signers and creator of scrum.
If that’s not following a plan over responding to change, i don’t know what is.
The problem is most agile followers take
"Responding to change over following a plan" to mean
Don't plan.
So you have 100+ person organizations running in a direction quickly for 2 week sprints to find out what the new direction they are going to run once they get there.
Problem is that most developers think they're in product manufacturing rather than product design. If only the requirements were clear, we could build it right in one go.
Agile tries to turn software development into a product design process rather than a product manufacturing process. Together with the client, iteratively you try to find the right solution and design for the customer problem.
By being easy to adopt, software lends itself to an iterative design process, where you adopt it multiple times based on the iterative feedback of the customer. But this means that at the end of the design process, you can skip the manufacturing part, as you've already built the software during design.
Alternatively you could argue that this is too expensive, inefficient and slow, and you need some design before you begin to manufacture software. Modeling tools could help here, e.g, low code tooling like CAD tools in fysical product design.
> Problem is that most developers think they're in product manufacturing rather than product design. If only the requirements were clear, we could build it right in one go.
Oh, man. I think you hit the head of the nail. One succinct phrase that describes the entire problem.
I don't think agile was meant to take everything client says without critical thinking. Quite opposite actually, it encourages dialogue. Often developers know better how to solve certain problems.
Early in my career somebody said something like "make sure you distinguish between <<what they (customers) want>> and <<what they need>>.". This thought stuck with me for years and in my opinion has been reposible for success I witnessed.
It's important to unwrap "what they want" so you, as developer, can apply more first principle thinking to arrive at "what they need".
BAs have tendency to project their own solutions, however when unwrapped so you see the problem that needs solving, you may arrive at solution that is simpler (like orders of magnitue is not that rare in my experience), reflects reality better, takes advantage of somehow hidden from BAs PoV system internals etc.
Agile enouraged dialogue is the platform where those ideas can surface.
I thought agile hedged against that by getting product in front of customers early - they may not know what they want but if you show them 100 things they don't want you'll probably be close
That is the theory, except on the customer side you actually need the people that will use the product.
Usually what happens is that you get a customer team, that is supposed to voice how the organization wants the software to be.
So the same mismatch is bound to happen anyway.
And when they do involve the people from the field, depending on the company culture, they might even be quite positive on the demos (cause being negative isn't good) and then completely find it unusable on final delivery.
Agile misses that many engineering teams lack people skills to actually navigate and avoid these scenarios.
This is (IMHO) the biggest single miss in most attempts to be "Agile". The customer/end user is supposed to be embedded in the team, doing actual work with the program, raw and hacky as it may be. This way the feedback is immediate and accurate. Passively watching smoke and mirror demos once every sprint is a far cry from this.
Of course, this isn't applicable/possible for all types of software (you can't really iterate your way to an MVP nuclear reactor) but there's less of this than you'd think.
One key part of this that a lot of businesses miss is that this means that every member of the team shoul have direct contact with thw customer, not just a "point of contact"
This is a good point. However in practice we wind up with a number of gatekeepers between the developer and the actual users. These gatekeepers are both on the customer side and the developer side. For example on the developer side, sales people typically do not like being disintermediated since it reduces their relevance. On the customer side, managers often do not want outside developers bothering their workers.
As a developer I've had plenty of pointless and unpleasant customer interactions thrust upon me. It's not a good thing.
I have always appreciated product managers who effectively intermediated customers, had deep domain knowledge, managed stakeholder expectations, learned how to interpret what they said (and ignore what isnt relevant), asked the right questions, prioritize effectively and output to me a nice set of, de-noised, ordered, precise answers to the question "what do I do next?"
It's a rare skill. It boosts my productivity immensely when done right. It removes cognitive load from the developer.
Even when POs make mistakes and misinterpret requirements I still appreciate that being somebody else's problem. It quells my anxiety immensely and lets me focus on developing the thing right without having to worry about whether Im developing the right thing.
Because that isn't something their management levels will even consider a possibility, given security concerns, politics, and whatever might come up if the project goes south and a lawsuit is bound to happen.
These agile ideas only work in an ideal world of "we are all friends here".
The best "agile" experience I've had was with a team spread across the continent. Good communication & process != co-located. (And if your customer is external, it even puts them on a more equal footing)
Agile willfully closing eyes to skill mismatch is a wider problem. Complex projects have a need for specialization and I cringe every time when new teams or scrum ‚masters‘ ignore that.
We kind of successfully to that in my shop, the early stage product usually being graphic mock-ups (wireframes may not be enough when the client really lacks product vision) to iterate fast.
I disagree mildly all succesfull products are pure accidents.
Especially in B2B and technical realm it is feasible to actually plan in every sense of the word "plan" a new product - business, tech, etc. Of course the plan must be malleable on the facts on ground. And probably is incorrect on a few places. But never the less, a plan that will get a business from place a (no product, but strong understanding of customer needs and business plus strong technical savvy) to place b (final product, customers, revenue etc).
I've seen this many times, both in startups with a new product and new customers (automotive software) and established companies that just expand their existing portfolio (cad software).
I'd say the "not an accident" is feasible if these facts are in place:
- enough A-team players (tech,business,sales)
- healthy culture (that facilitates long term growth and can focus on the product without too much politics)
- understanding of customer business
- identified an OBVIOUS need for the customer
- strong engineering org (can be just a few coders that get things done or larger)
So I agree, you can't train for these requirements like you can train airplane pilots.
But I do claim you can have enough understanding that is the current org in possession of these qualities. And if it is, it's a very reasonable risky investment to try to create a product for the need.
The vast majority of software is not for flywheel type situations.
For internal customers or in B2B settings getting the actual users and outcome owners involved early is vital - but they are often poorly incentivized to get into the action as there are layers of business mangers etc in place that are supposed to stand in (but lack the detailed knowledge).
"Customers don't know what they want": this is something Agile specifically tries to address by releasing often and adapting to change. This is a quick feedback loop: the customer can quickly see a product and the development can quickly adapt.
What was the 'standard' way to develop systems when the Agile Manifesto was written: the same as for building a bridge.
You gather and freeze requirements. You write a massive plan and plenty of specs. You code accordingly. You deliver.
Time to working software is long and a lot of the effort that goes into specs is wasted, especially for design specs.
Your characterization is not true. The reality was quite the opposite.
Here's the introduction of Steve McConnell's "Rapid Development" from 1994 - well before the Agile Manifesto! - Chapter 1, page 1:
> The product manager told me he wanted to build a product right for a change. He wanted to pay attention to quality, prevent feature creep, control the schedule, and have a predictable ship date.
> When the time came to actually do the project, it became clear tha getting the product to market quickly was the only real priority. Usability? We don't have time. Performance? It can wait. Maintainability? Next project. Testing? Our users want the product now. Just get it out the door.
> This particular product manager wasn't the manager on just one product. He could have been almost any product manager I've worked for. This pattern is repeated day after day, state by state, all across the country. ...
This is as far from building a bridge as you can get. The next page of the book starts:
> [1.1] What is Rapid Development?
> To some people, rapid development consists of the application of a single pet tool or method. To the hacker, rapid development is coding for 36 hours at a stretch. To the information engineer, it's RAD - a combination of CASE tools, intensive user involvement, and tight timeboxes. To the vertical-market programmer, it's rapid prototyping using the latest version of Microsoft Visual Basic or Delphi. To the manager desperate to shorten a schedule, it's whatever practice was highlighted in the most recent issue of Business Week.
Agile drew from earlier methods ("intensive user involvement", "rapid prototyping") which were pretty common even before Agile.
> Steve McConnell's "Rapid Development" from 1994 - well before the Agile Manifesto!
> > To the vertical-market programmer, it's rapid prototyping using the latest version of Microsoft Visual Basic or Delphi.
Huh? Did you get the year wrong, or was he referring to a brand-new / not yet released / tool as a "standard" for some segment of his audience? AFAICR, Delphi was introduced in 1995, or at the very earliest, late 1994. Feels weird that he should mention it in a book published in 1994.
The 'standard' method is the waterfall model, which proceeds like you would for a bridge (of course this is just an approximate analogy) from specs, to architecture, detailed specs, implementation, and tests.
Of course the shortcomings of this model have been known for a long time to anyone building software and so a number of other models appeared.
From what I can tell, that assertion is common in Agile advocacy.
But from my experience as a professional software developer in the 1990s, and from reading stories about software development, waterfall was not used at Apple, Be, Commodore, Data General, Infocom, Microsoft, VisiCorp, and more.
That's not to say no one used a (modified) waterfall model. Simply that I haven't found evidence that it's meaningful to say it was the standard development model. [1]
[1] Technically, DOD-STD-2167A's apparent bias towards waterfall was a "standard", but I don't think that's what most people mean in this context, and in any case it was replaced by MIL-STD-498 in 1994, well before the Agile Manifesto.
I put 'standard' in quotes and meant that it (and its derivatives) was widespread. I'm sure not all companies used it, perhaps it also varied by domain. My experience is that it was indeed common, and still somewhat is. I read at my first job 20 years ago we had to take a training on the V model, which is derived from the waterfall model. It has also always been common in my experience to write plenty of detailed specs before writing any code, for instance.
I don't see much value in debating this. It seems clear to me that the people who wrote the Agile manifesto have experience in working in such, or similar environment and reacted to change it. And clearly that way of working was widespread enough and enough of a pain point to strike a cord. Certainly, when I first read the manifesto it struck a cord and I understood exactly where they were coming from. I think it is spot on.
Isn't Agile more or less gradient descent (well, approximating the gradient for an undifferentiable function), applied to software development?
The objective function is some function of the quality of the product, as measured by the customer, and the work put in. The gradient evaluation is then the process of determining which feature gives the most bang for the buck, implementing it, and repeating.
But gradient descent has problems with local minima. So if that's what Agile is, no surprise it doesn't do surprising projects - even if the customer does know what they want. If the programmers are too inexperienced and it's not just a CRUD, then you'll end up with something like Jeffries' TDD Sudoku solver.
> Isn’t Agile more or less gradient descent (well, approximating the gradient for an undifferentiable function), applied to software development?
Lean is.
Agile is “It would be nice to do what works for your team in your particular challenges, not some pre-packaged one-size-fits-all processes sold by consultants. Now, here’s a bunch of pre-packaged one-size-fits-all processes, and an army of consultants selling them.”
You’re right that customers don’t know what they want and that can make it a bad idea to include them in the dev process directly. But is that what Agile is about? I thought it was about iterative development. As a long time product dev I know that you want to follow your own vision when building your product. You let your vision be influenced by customer feedback for sure, but you should always second guess the feedback, never take it at face value, never just build something because a customer asks for it - that would be Henry Ford trying to breed faster horses.
It's probably better to phrase it being a development method that focuses on a tight feedback loop with all stakeholders.
You push decisions as far out as possible and gather feedback from individuals every step of the way.
This is what allows the greatest amount of flexibility.
The biggest problem with agile is that it assumes all problems can be put off to the last minute.
I'm frequently finding myself in situations where it is 100x better to hammock program it out for a few weeks before pushing any code. Those systems last ten years. Those systems are able to be modified simply and quickly when business needs change. Those systems do build up legacy code, but it's at a slower rate than other systems. Those systems have fewer hacks over time and fewer bugs as a result.
This isn't a dig at agile, it's a dig at using agile as a design process, for which it is utterly inept. Agile is great at pushing products, terrible at pushing thoughtful system design. (On average, sometimes working a problem works too but more often than not you don't get the chance to redo middle sprint 5.)
> The fundamental problem with Agile is the fundamental problem with all product development: The customer doesn't know what they want
I don't disagree, though I firmly believe Agile does a much better job of dealing with the problem you state than any other software development methodology that has been attempted before.
Is it perfect? of course not. As a methodology, is it better for building software than methodologies that have been used to build enormous physical structures for generations? Undoubtedly yes.
As far as I'm aware, there currently isn't anything better for building complex software with changing requirements (i.e. the real world).
> Agile assumes as a first principal that including the customer throughout the development process will align the building team and the customer to come to the same conclusion.
The only thing that is less likely to have the building team and customer come to the same conclusion is to add many more layers in between.
If that were true the customer never drop you for the competition. The customer will drop you in a heartbeat.
The customer cannot express what they want in a language you can articulate which is something amazingly different. As a product manager you need to account for that.
I'm not sure if Agile ever claimed to be a good process for coming up with unicorn startups though.
It's a way to meeting actual business software needs, much more suited to custom development for one customer than product development, which necessarily requires some additional insight into what the market wants.
Develop product engineers to be better. Have empathy and communicate with the target customer more clearly and understand the landscape better.
That's pretty much all you can do. How you organize it only matters insofar as it makes your team effective - sprints, waterfall, XP whatever... is kind of a toss up and context dependent.
Agile is a generic umbrella term that involves a vast array of complex, subtle knowledge and skills. It's like saying "Engineer", or "Chef". Each has a shared skillset, to be sure. But each category's members can't just work the same way at all jobs, and there's no book on how to be an Engineer or Chef everywhere.
The Agile Manifesto is a failure at trying to make Agile happen because it can't tell you how to make it happen, because it varies wildly. No manager can read a book on how to "Agile-ify" their org, they have to apply their brains and figure out how their specific version of "Agile" will work. But the skill-set required to do this is not a Managerial skill, it is a lower-level-worker skill. But it's also a very advanced lower-level-worker skill.
And that's why things like "Agile", "DevOps", etc will fail. People at the higher end have no clue how to make it happen, and people at the lower end who have an idea how to make it happen don't have the power to make the organizational changes to do so. You need a way for the lower-end people to tell the higher-end people what to do, and have the higher-end people listen to them, and make the changes happen. This is very hard in a traditional organizational hierarchy, because higher-end people have big egos and bigger concerns over things like politics.
The product and engineering managers I've had in the past have generally been humble, acting as a touchstone of coordination for the folks on the ground rather than a controlling force. And the engineering managers have all just been former engineers who decided they preferred doing this kind of facilitation work instead of writing code.
I do enterprise consulting for a couple of years, the kind of organisations that buy Oracle or MSDN licenses without thinking twice about it.
The best I have seen were mini-silos that managed to de-couple themselves from the org chart.
However I also have seen that it hardly lasts more than a couple of years, because as soon as someone noticed the success of the business unit they were re-integrated so that they could teach the reasons for their success to others.
You can imagine how well did they usually fare afterwards.
> And that's why things like "Agile", "DevOps", etc will fail.
I completely disagree. Most team leads and technical managers where I've worked get promoted up from within a highly technical position. I wouldn't have any respect for my team lead or my PM if they didn't know what they were talking about.
If my PM is going to try to tell me that I should work on this feature over this other feature or I should implement it in this way over this other way do you really think I'm going to listen to them if it's clear they have no idea what the implementation details are let alone the tools? Of course not.
I'm making DevOps happen and I do that by knowing the tools and practices. I'm being given the power I need to make it happen. I earn the respect every day I come in and write the code or identify the weaknesses we need to shore up to move faster.
One was a CEO who hadn't any technical background, but he knew what ICT could and could not do for his company.
One day we rewired all of our network, a massive weekend job. He was there, even if the only thing he could do was pulling network cables out of bags and straightening them. He saw who and what worked or not, he saw where we struggled even if he didn't understand a word of our technical mumbo jumbo.
I found out he was always there on the ground for every major operation in his company, not only ICT. The result was he knew the company inside out. Nobody ever tried bullshitting him. I still have massive respect for him, years later.
Then there is exhibit B, a manager from the 'you dont have to understand ICT to manage it' school. Everybody under him spends 3/4 of the time in meetings or filing useless forms. Nobody dares touching important things, so hard decisions get pushed in the future. It happens urgent work needs doing and the only person capable of doing it sits twiddling thumbs as the spreadsheet says maximum team capacity has already been reached. He redefined the words 'major incident' as there were to many under the old definition. His teams keep losing important members, everybody hates each other, work that should take 10 minutes takes months. But he always has a spreadsheet demonstrating it is not his fault.
That's not a CEO job. His job is to make sure the enterprise is funded and sets a vision.
The first example must be a small company.
2. This sounds like a manager in an enterprise level company
If you choose to work where a multi-level manager structure exists you should give that manager respect because he has to navigate a political landscape that takes certain skills.
Besides managing people and knowing what customers want have nothing to do with knowing your specific skills. Should the CEO know marketing, accounting, legal, etc as well as the experts in their positions?
And how many hours per day does it take to "set a vision"? How do you develop this vision if you know nothing about the company you're running? This is how you end up with these awful celebrity CEOs who wouldn't notice if you swapped the company they're running with one that produces toothpaste. They're too busy on CNBC and Fox Business talking about their amazing "vision".
1 was for a 500 people company. Not small not large. The company grw while others in the sector shrunk, so he did well.
Considering 2,this demonstrates what is wrong with big enterprise. If the politics are more important than the work, the work won't get done. Just like I don't have respect for Trump just because he managed to rule the most powerfull country in the world, I don't have to respect a manager who's team fails again and again, after which they get thrown under the bus just to save the face of a higher up.
Note how the CEO mentioned had no ICT knowledge, he just knew enough to knew where he stood. Same for marketing, accounting etc..
My PM does know more than me. And he's good at directing where the team should invest it's efforts. That's why he's my PM.
You seem to have completely missed my point, which is that technical leads and PMs should have domain knowledge and that this is why DevOps is not in danger of failing at competent companies.
I get your point that someone rose from your ranks and you respect them over someone who who has a background in pm but not your product.
That technical pm is a luxury and will move on at some point. You don't need him your team with a strong lead or more senior developers could work with a regular pm and get the job done.
> I get your point that someone rose from your ranks and you respect them over someone who who has a background in pm but not your product.
No, that is not the point your parent seems to be making. Your parent talks about "earning respect by learning on the job", but you are stuck at "having respect because of background".
Your parent leaves open the possibility that a PM without technical background can still become a good PM, and even lays out what they think is required for that to happen. You're stuck at "you don't respect them, got it".
----
I'd like to remind you of this point from the HN guidelines: Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.
> ... your team with a strong lead or more senior developers could work with a regular pm and get the job done.
Let me show you where this slippery slope ends: Teams with a strong lead or more senior developers could work without any PMs and still get the job done.
Oh. Wait a second. This happens all the time! Does this mean those teams achieved their success without any management happening? Or does it mean that technical people in those teams who did do the management work did it without the title?
If work activities is about titles, I hope yours is multiple lines long.
We are talking about what is the most efficient. One of the point of Agile was to attempt to lower the division of tasks (and I'm saying that even if I don't like the way it was attempted nor the overall effect 20 years later) because having a broader vision of things is more efficient than trying to communicate (to what I would add: IF the project scale is reasonable enough to do that...); thus: a little bit of PM tasks, a little bit of working with customer, etc -- at least more involvement than if crappy requirements were produced after crappy contracts were signed, and neither of them could be revised.
So if that means more people do "management", in a context where this is beneficial, then... good? What is exactly the problem? You think they are paid too little? Maybe, but then it switches from a work methodology to a salary negotiation problem.
It isn't, and I'm not going to go there. But discussion about work activities does need appropriate and accurate labels, for it to be effective.
> So if that means more people do "management", in a context where this is beneficial, then... good? What is exactly the problem?
Who said it's not good or that there's a problem? I didn't.
> You think they are paid too little? Maybe, but then it switches from a work methodology to a salary negotiation problem.
I don't know what I wrote that leads you to believe this, but I said nothing like this. You seem to be reading too far into things I wrote; or worse, things I never wrote.
----
To try and clarify what I meant and where I was going: I was talking about accurately identifying the work that actually happens. Specifically, I was trying to show my parent commenter, ipaddr, how their erasure of such work leads to poor results for everyone involved, including the people trying to even talk about it.
I'm not trying to argue for a better salary or title — I've already got too much and too many of those, as you hope. But I've seen this very discussion happen too many times with clients of mine, with the same devolution. People think their problems will be solved if they get a good "PM". If said PM lacks technical background, they think they can just pair them with a good senior engineer and all will be good. I've seen this fail enough to know that's not how it works; and not because the senior engineer wasn't "senior" enough or "good" enough. As I said elsewhere[1] in this thread: There does exist a big difference between "lead or senior developers" who are good at development and those who are also good at using their technical knowledge to manage a team's work. A non-technical PM lacks that essential latter part, and if they have to rely on a "developer" to step up and fill that role, they're still a PM, but they're not the sole person doing PM any more.
Failure to identify when there's more than one person fulfilling management responsibilities can and does lead to poor planning and hindered execution.
I ran my company like this (and have recommended to clients a similar approach). It still doesn't work the way you are thinking.
The "strong lead or senior developers" you're talking about: I call them TMs. Technical Managers. Because that's what their job becomes when the PM isn't technical enough. In the end, it's not the PM who "turns out fine" when paired with TMs; it's the combo of PM and TM who turn out fine.
There does exist a big difference between "lead or senior developers" who are good at development and those who are also good at using their technical knowledge to manage a team's work. A non-technical PM lacks that essential latter part, and if they have to rely on a "developer" to step up and fill that role, they're still a PM, but they're not the sole person doing PM any more.
Thank you! I could not put it into words, but yes this is pretty much what I observed.
They turned out fine if somebody else do that technical management work. Except that if not recognized as such, that someone else is not paid appropriately, does not have official authority nor ctual support of boss nor is he present at higher ups meetings to speak for himself. It makes the leading part much harder and is breathing ground for resentment or simply getting tired and giving up. And then it all starts failing.
It is kind of like saying that senior developer does not have to know all that much, if juniors are very good. Sure, but then your juniors are actually on underpaid senior positions. And it ki d of works, until junior senior figures and finds better place to work at.
For consultancy, the hourly rate the customer is paying to the employer versus what actually lands on the bank account at the end of the month.
For product development, the price of licenses and support deals per month, correlated to the hourly cost of everyone on the office, and then what actually lands on the bank account at the end of the month.
As for how much money it costs me an FTE to play around something outside the planned roadmap, their monthly salary divided by the amount of hours they are supposed to be working per month, correlated with the time spent on said activity.
Actually I have been in a couple of projects, where instead of sprint points or hours, we actually had euros as ticket efforts.
> For consultancy, the hourly rate the customer is paying to the employer versus what actually lands on the bank account at the end of the month.
No, that is just accounting of salaries. That doesn't calculate the value/worth of the work and hence can't be used to determine salaries. That's circular logic.
> For product development, the price of licenses and support deals per month, correlated to the hourly cost of everyone on the office, and then what actually lands on the bank account at the end of the month.
That is not really what I was asking for or my parent talking about. We were talking about specific salaries. Engineer X wants Y salary. justified or not? You are suggesting revenue/hours.
With that logic, everyone gets the same salary and you would also value the identical work differently depending on the revenue (which might or might not be justified)
Too many Java devs to chose from? Salaries going down.
Can't get hold of them? Salaries going up.
Whatever engineer wants is driven by market prices in land, and offshoring prices as well.
And yeah in countries with collective agreements across the industry, regardless of your actual job, everyone on the company building gets their tariff XYZ salary as per yearly industry agreement.
i might be missing something but you are still equating value of work with salaries for some reason. this is the context we are discussing, the original quote:
"How much of each dollar you make for the company with your hard work do you take home?"
i was asking how you calculate how much you make for the company. you specifically. not 'revenue/hours' or whatever. you and you only. salaries do not factor into this. how could they?
> And yeah in countries with collective agreements across the industry, regardless of your actual job, everyone on the company building gets their tariff XYZ salary as per yearly industry agreement.
that isn't true though. this might be the case in some countries (please provide a reference) but in europe with strong unions and collective agreements, it is wrong. it sets the minimum standard and companies pay over that agreement all the time.
The old Microsoft (the new one is much better at this), you couldn't just go around sharing department knowledge, if you on lets say Visual Basic team wanted the deep knowledge for a Windows feature as means to product improvement, it was easier to have a neutral contractor somehow get hold of the information across departments, than asking directly as Microsoft employee.
I'm not an expert on this subject, but I feel like "agile" could be summarized as "a process for actively incorporating feedback early and often".
That doesn't mean you need points or tshirt sizes or constant status meetings. You just need channels of communication with the right people and a chance to adapt to what they say.
And it’s something that good devs will already be trying to accomplish anyway. There’s also the part about breaking stuff down into small parts so that small cycles of meaningful dev can be accomplished. But that’s mainly to be able to release small and often - another thing you should already be doing to incrementally update your app avoiding big releases. It also stands in the face of waterfall development, though I see lots of teams doing test at the end still, making it waterfally.
I also see too many agile teams that have iterations that never finish, get feedback in prod, create half complete features that are weird or don’t gel - all in the name of agile.
I think the kids that get it were already doing it as it’s common sense. The rest end up sticking an agile badge on their practices when it’s all but.
You need <anything> because of the hostile nature between the creator and the patron of the creator.
The patron wants more, the creator doesn't want to create more, so you need to force a detente so the patron will continue to pay the creator, and the creator will continue to produce.
You get t-shirt sizes and points when the patron feels the creators aren't doing what they said they'd do, so in a way it's a communication problem, yes, but the cause of the communication problem is that there is almost never an alignment between the two groups, and so you need some kind of shared language where expectations can translate, and accountability can exist at all, usually in some flawed form.
That’s not a bad starting point. There’s more than one kind of feedback though! No matter how regularly you reflect on the process, if you’re ploughing through an unchanging backlog it’s still going to be a mediocre experience. Worse if the strategy keeps changing and you have no influence over it. Those unfortunately describe the experience of many - sometimes well-meant but an imbalanced and process-centric Agile with ironically little regard for the people doing the work.
This is how I see agile too. With it’s links to lean, it’s about minimising waste by minimising work in progress. Since the biggest waste is building something no-one wants, getting a small increment into the hands of a user/customer as soon as possible is key.
The problem, in my experience, is many development contracts are still structured in such a way that this becomes too difficult. Management fearing early exposure to the customer will lead to scope creep and cost growth.
I think the big divide here is between tech companies and non tech companies.
Tech companies can look at the agile manifesto and use it as a heuristic guide, because engineers are already kind of on the same page about it. You don't need heavyweight process etc.
Non tech-companies need the window dressing of tech companies to retain their best engineers, but ultimately agile is kinda telling them to turn everything upside down and also threatening to make them superfluous. Nobody is really up for that.
So agile in non-tech companies is Kabuki theater and engenders cynicism, and agile in tech companies is basically superfluous "water is wet" advice no one even bothers to comment about.
You'll notice a lot of these blogs about how agile has failed are coming from consultants, who are basically brought into traditional companies that are struggling with some part of this process, not tech companies.
This very much resonates with my experience. I've seen this very process take place when working at a small tech startup that ended up being bought by a non-tech giant keen on undergoing a "digitalization" initiative. Our prior processes were lightweight, goal-oriented and effective. No one bothered calling them "agile", they were just the natural way to deal with an ever changing landscape of customer and system requirements.
After the buy-out we were told to undergo a thorough transformation into this brand new unified top-down software development process the company had some consultants design for them. Complete with a baffling array of buzzword driven "agile" development practices and project/squad/team/chapter manager/lead/head roles to be filled. The more you kept inquiring what exactly those roles should entail, the more conflicting and vaguer the answers got until you realized that no one had the faintest idea how any of this was supposed to actually mesh together in practice. The license packages for the expensive project planning software we were to use where long paid however.
I totally agree, and I think another big reason Agile fails to cut through in companies is because anyone who wants to be Agile in a non tech company is fighting a crushing bureaucracy. So rather than innovating and climbing higher on innovation they leave due to the massive inertia that is encountered trying to change company culture.
I was at OOPLSA 1998 where it was going viral. Participated in the early C2 wiki. Participated in some of the early "workshops" on this upstart rebel movement.
Raised in a christian tradition, and somewhat a student of history of christianity, I was fascinated by parallels that unfolded in months` time what took place over centuries in christianity.
5 years after the movement began, I found that it felt as watered down, abstracted, and diverse as christianity spent 2000 years becoming. I could bond with a fellow programmer as an "agilist" and at a very vague level, there was some abstract similarity (e.g as christianity might be to "be kind", agile might be to "be lightweight"). Everyone took the parts they wanted and formulated what fit for them. Which was/is both a good thing and a bad thing.
We are unfortunately saddled with "religion" as the archetype of this behaviour.
Perhaps we could call it, "social virtue mythology".
What is a social virtue mythology? It answers the following questions:
* Why is there evil in the world? (ie., why arent things perfect)
* How do you overcome evil? (ie., become perfect)
* Who is good? Who is evil?
* In what or who should I place my trust?
* etc.
Today we can see many such competing virtue mythologies....
Why is there evil in the world? New Atheists: Religion; Feminism: Patriarchy; Socialists: Capitalism; Idenity-Woke: Essentialism.
Personally I regard this as wholely "mythological" because the questions these social-virtue systems are designed to answer "take place" in a utopian/dystopian reality.
Ie., many people eventually discover that there is no need of this type of mythology: reality is itself flawed. We aren't "owed" a utopia, and thus there is no question to answer.
Here, in agile then we see these patterns even in this thread. Some commenters are still trying to answer the question, "why isnt software design/construction perfect?" as-if there can be a virtue/vice answer, ie., "because we have failed to...".
Rather, no. These problems are irresolvable. The reality of software is intrinsically broken: there is no customer to give you the requirements, there is no habit which elicits them, there is no mechanism to build reliable software, and so on.
Many are extremely loath to confront this reality, especially as adolescents; ie., that they are powerless to build their utopia. The really-existing world has irresolvable contradictions that admit no virtuous resolution.
I've seen Agile at a handful of shops, a couple dozen projects. I've seen it implemented well just once...
The "scrum master" was a dedicated role, filled by a technically able person, who sometimes helped a little bit with the coding. This individual had read several books and taken a course on Agile. They were sincerely passionate about Agile and wanted to implement it effectively.
The "project manager", a DIFFERENT PERSON was part of the "business", and interfaced primarily with the scrum master, but they were with us for several hours of both planning and retro.
Our sprints were 2-3 weeks. At the end of the sprint, we spent AN ENTIRE DAY on retro. Before the next sprint started, we spent AN ENTIRE DAY on planning. We used a physical board which was matched by the tracker. They were kept in sync by individuals and validated by the DEDICATED DOCUMENTATION PERSON.
We broke down the tasks relentlessly, until there were almost no 3-point tasks, maybe one or two 5-point tasks, and everything else was 1-pointers. I think this one is the most bang for your buck, lowest hanging fruit, easiest to implement winner. Someone has to enforce it vigilantly until everyone is used to it.
Those three things are, IMNSHO, the keys to getting halfway decent Agile going.
Edit: Was one of the least soul-crushing and nicest experiences in professional software development. The planning meetings were a serious effort, but also a pleasure because I liked everyone on the team, and the large time windows made it not seem rushed, so we had time to joke around and shoot the shit.
How did this approach deal with difficult technical/algorithmic problems where someone needs to investigate something before further decisions can be made?
Example: You want to improve performance. Somebody will have to fire up a profiler and measure things, and then figure out which hotspots are worth optimizing.
I totally get breaking it down to "set up profiling tool", "do profiling runs for workflow X/Y/Z", and "identify low-hanging fruit". Presumably these tasks are not going to take the entire sprint.
How do you plan the next step in task format? Do you not do any further work on the topic until the next sprint, where you then plan out concrete "optimize function X" tasks?
If not, i.e. whoever does profiling also gets to optimize code during the same sprint, how do you account for that in planning? Three dummy tasks "optimize a hotspot" without any actual idea what it will involve? Maybe it requires rewriting a component to use different data structures? Maybe it's just a single JVM config tweak? "Could be a 1 or it could take my whole life?"
Maybe it's just less common in certain domains, but this kind of "we need to investigate this issue and then decide what changes to make based on the investigation (and good engineering judgement)" - which is bread and butter in my part of the org - does not seem to fit into the "tasks with points" concept at all. Well, unless you want to always spread the process of "investigate issue", "identify problem and solution(s)" and "implement solution" over a whole month. That seems soul-crushing to me.
To be clear, I'm very interested in seeing how to make this mesh with Agile. But it feels like trying to write a binary search in a language that has no indirection or conditionals.
I see. But that's still only the first, "plannable" part. If the research (or algo design) led to the conclusion that component X needed a rewrite, would it require waiting half a month to get started? Maybe that makes sense if it's a larger thing (so that detailed planning would be worthwhile), but would you be required to drop it and do something else in the meantime even for smaller ones (say, a man-day of work)?
> This sounds soul-crushing and I hope never to work in such an environment.
It isn't.
Soul-crushing is doing "Agile" where the "scrum master" tells you how long each ticket will take, where the client is invisible and never involved, and where retro is 1 hour at the end of the sprint and focused on blame.
I thought the idea was to focus on what is achievable in the sprint. Breaking tasks into separate steps or points exposes the complexity of a task and a task that is listed as 1 point should be fairly quick to implement.
For me I'd feel more engaged by seeing that I've contributed to completing distinct points on the board at the end of the sprint.
I'm a team of one and only recently started coding a large project. Sometimes I can work entire days only having achieved intangible progress. I'd love to be able to quantify this work as progress toward distinct tasks. Maybe I need to implement an Agile-like system for myself.
The "scrum master" is not telling you how long a ticket will take. They're asking you, can you break this ticket down any further?
I see that you have a task to implement validation in the phone number field, can we break that down into three tasks? Determining the format which needs to be applied and edge cases, adding validation to the field on the client side, and also on the server side?
Right away, thinking about it this way may reveal certain unknowns which you had not previously thought about. And all of it took an extra minute or two. While your team-mates are also engaged and "THERE" to help.
Later you can see which of the tasks took longer or less than expected, and use this to improve your future estimates (during the retro.)
This is only skimming the top of the types of benefits you can gain from a good Agile process.
No, in this case the "scrum master" did tell us how long the tickets would take, because the cost had already been agreed with the client before we were involved.
The time spent in those retrospectives and planning sessions are about the technical aspects - how talks should be broken down, how overall design of interacting components should look like. It's 100% actual work.
I'd take these over another bs "status sync" any day.
Some developers might love just mindlessly doing trivial tickets week after week, since it means they don't have to worry about anything since the job is so easy. But others will view that as soul crushing, you can't say it isn't soul crushing for them.
Being able to break down a complex technical problem into mostly one point tickets doesn't mean it is easy or mindless, just that you're good at planning and executing.
It means that the day to day job is easy and mindless, even if it is some ok work being done during those meetings. Doing all the real work in a meeting every other week does seem soul crushing.
There’s a difference between breaking down a complex technical problem in a few days (my approach) and doing it on the fly while doing a sprint planning. Most of Agile people want you to give estimates and simple dumb tasks that break down a complex one; this is fine... but hey, it will take me a week to do so! This is not OK for them (they want the estimate while doing the sprint planning).
If those two days out of every two weeks are critical to a team hitting their deadlines, then the team is already fucked. If you can't stop, think, talk, and relax for a moment, then you're already behind or will be behind and you'll probably never catch up without risking burnout of the team and mass quitting.
If your team is so dysfunctional that you need two days to stop, think, talk, and relax, then no amount of meetings are ever going to get you on track.
It’s not about dysfunction. It’s about deliberateness. Only idiots press forward without taking time to think and consider how everything is going. By making it part of the routine you help to ensure the absence of that kind of moronic behavior. Press forward and burn out your team with a lack of slack and forethought if you want. No one is forcing you to be intelligent.
It's not about deliberateness, it's about mindless ritual for rituals' sake. Only idiots would perform cargo-cult practices over a set time regardless of need or utility. By using your brain to take time only when necessary you help to ensure the absence of that kind of moronic behavior. Force time wasting meetings and burn out your team with a lack of respect. No one is forcing you to be intelligent.
I'd certainly like to be in an environment that has the dedicated people to those roles that so often are either combined or eschewed entirely, but 16+ hours of meetings per sprint sounds incredibly draining.
It wasn't particularly draining, because the large windows allowed a more relaxed pace, ensuring that nothing was missed, and a time for joking around.
And it was not "16+ hours of meetings", but two days of taking a break from coding to do more social work, also having a 2-hour lunch together in the middle :)
Even a two hour lunch break still leaves more than six hours for a retrospective, so, honest question, what do you talk about? I'm used to retrospectives taking about 15-30 minutes, and even then we usually have to scratch around for things to talk about. How can you have six hours of things to discuss after three weeks of work?
That doesn't answer my question :-) Are you all regularly having terrible problems that need in-depth discussion? Are you all celebrating every success with its own party? Are your processes so wildly off the mark that you have to change everything every sprint? Is there something else you do in your retrospectives that I don't? For my current team (also around 10-12 devs, 2 week sprints) it's:
- what went well? we completed most/all of our tasks, cracked a tricky problem, received good feedback from somewhere - let's say 5-10 minutes of celebration
- what didn't go well? maybe a task was more difficult than expected, some new requirement added unexpected difficulties, some third party something didn't perform as expected - 10-15 minutes of commiseration and discussion, maybe more if there's something complicated, perhaps that requires further action
- what would you do differently? unless there are some procedural problems, I would expect almost nothing here; maybe someone has some new ideas about how to improve something, perhaps some aspect of the project isn't running as smoothly as it could - 5-10 minutes maybe
So about thirty minutes max across the whole team, usually less. What secret magic are we missing out on? Six hours??
Six hours is longer than I would use for a regular retrospective, but 30 min is very short. The format you’ve described is fairly shallow. Check and Derby and Larsen’s Agile Retrospectives for ideas about what you might be missing.
The best version of Agile I've ever been part of didn't start great, started like what you describe. And everyone hated the day long retro and planning. So we iterated over it until we got people to come to those meetings with their homework done and tasks reasonably thought out and split instead of having to waste everyone's time for it. And in the end it worked quite well. Retro and planning down to ~1 hour.
I will fight, in any team I'm a part from now on, to avoid the interminable scrum rituals. They are soul crushing for most good engineers I know. I never ever want to do them again.
It’s a very nice article. I’ve not seen agile done as originally visioned. Usually because the VP Engineering (or equivalent) and down wants to do it but the rest of the business isn’t interested.
Also the pattern I’ve seen is over time businesses want more and more fine grained control over the engineering process, as if treating the team like replaceable workers doing well defined tasks (like Ray Croc I guess) leads to more efficiency.
This doesn’t work when the burger and chips has zero cost of replication and your staff are not frying and serving chips, they are inventing new cuisines every day.
Agile is not about "mean efficiency", this is a serious and widespread misunderstanding.
Agile is a risk management method.
You won't build things faster with agile in general. It's aim is to decrease the chances of spending 80 manyears on a project and then realising at the end that you've built the wrong thing.
Well, a fluidity thing. But yes that’s related to risk. Being able to change direction at the drop of a hat. Also working with poor requirements which is a fairly common working condition in a lot of shops.
I really enjoyed this read. I’ve been grinding for so long in the huge corporation version of agile that I don’t even know what is what anymore.
It was refreshing to hear their take on project managers, as it matches how I’ve been feeling recently. They schedule 7 checkpoint meetings per week and I’ve given up on attending, I just can’t do it anymore.
I hope that we can move past agile into a new world that is free of the baggage and process of yesteryear. Even if the core principles are the same, let’s call it something different so we can start fresh and impress upper management.
Then you might have an inexperienced manager or moderator. All it takes is "Hey John, I didn't hear you in the discussion yet. What are your thoughts?". "If there was 1 thing we should improve, what do you think it should be?". Stuff like that. I know even then it's sometimes hard, but at least you should try pulling things out of them.
> Then you might have an inexperienced manager or moderator.
More likely you have people who are paid to do some workload which they are generally happy with. They aren't going to be motivated into doing more by accident, especially through their own action. This is the vast majority of people in the world, so good luck countering that momentum over the long term.
Effective software project management is an interesting and hard problem, granted, so many people are interested in how to tackle it. I get it.
What I see is that "agile" criticisms are really criticisms of it's inefficacy in giving employers more for their dollar from the employee perspective. I don't see why I should get too invested in minimizing my relative value.
Agile assumes people are intrinsically motivated to do good work. (This is called “theory Y” management.) It doesn’t work if people have to be extrinsically motivated (“theory X”).
If you have a bunch of people who are just doing the minimum they’re paid to do, with no passion and excitement for the work itself or their team, you either need a different method or different people.
This is how revolutionary Marxism functions. Nobody knows what the hell Marx wrote in those books, or what any of it means, but it cannot be argued in communist regimes that there is a system in place, and that the vanguard knows whats best. Replace Marxism with Agile, communist regimes with corporation, and vanguard with management, and you have the recipe for soulless employment.
People (read: Twitter users)[0] have discussed the parallels between Maoist/Marxist theory and both Agile and extreme programming—albeit less fever-dreamy
Side note: I have never actually read anything written by Mao before. That stuff is a very unsettling combination of stone-cold and unhinged. Maybe it's just because we know the "full" history now, maybe it's just the phrasing of the translation. Yikes.
And here lies the difference: agile includes retrospectives. I
It's the only thing you need for agile. And if you don't have that, you don't have agile.
Well, it depends. I have seen many teams where retrospectives are basically a lot of personal mea culpas, people talking about what they did not do right, and it was mostly about how they should have done things differently rather than how the process or organisation could be adapted. The overall feeling is that agile works great, scrum works great, so if something went wrong it's because of the human factor and that's what should be fixed...
I don't know about communism, but at some places the implementation of agile sounds like a regime.
Agile got widespread adoptions because of the micromanagement undertone of it, starting with the daily scrum. It's a slippery slope, way to easy to over do. The risk is it starts something to be gamed/incentivized instead of actual progress.
> Agile got widespread adoptions because of the micromanagement undertone of it, starting with the daily scrum.
I would put things differently: micromanagers leveraged the agile and scrum buzzwords to justify and convey an aura of legitimacy to micromanaging.
I mean, how many orgs forced daily meetings where workers are forced to enumerate what they did and delivered in a short time frame, but mysteriously left out the part where a feedback cycle exists to revise plans other than performance evaluation plans?
Agreed completely. I was (and still are) on couple of different companies and teams practicing "Agile" and those daily standups are more like daily blamefests. God forbid you get stuck somewhere and need someone's help. Then you have to apologize because everyone thinks that you're lazy or incompetent and holding everyone down. Also if people wanted to know what I did yesterday, they could have a peek at the tickets they want us to keep up to date but no, they want us to say it anyway. Also that stupid "do you have any blockers" question. No I don't have any blockers, it is this bullshit technology/service everyone wants to use today, and discard tomorrow which I somehow need to be an expert of with 30 min of looking at some incoherent manuals.
It seems to me, that all these buzzwords and meetings are just a way to always keep you "busy" (or at least looking busy), to always have some kind of fire below your feet so you don't "slack off" (or have a bit of free time to actually gain or sharpen the skills you need for the same company...). I'm just tired of this. In a way, good teams will be good, and bad teams will be bad, doesn't really depend on whatever process they have.
I think the fuss about the daily scrum is a perfect example of what is wrong with many Agile transformations.
Often it seems that people talk about the 'micromanagement' and 'wasted time' as if they would not enjoy the daily. To me this is a warning, that something within the setup is not right. In general, micromanagement requires hierarchy, but I don't recall from the Scrum Guide [1] that a manager should be present or that directions should be given. So who is managing who?
If done right, there should be absolutely no reason why there should be negative emotions involved: The devs get together and talk about their work and the challenges they want to share. It is about fostering communication.
I'd say the much more common negative emotion is when you didn't manage to get the work done you had planned to do/spending way too long on a task and having to justify that in front of the team.
One of the problems with Scrum is that it describes something close to a process (Plan > Dailys > Review > Retro > Repeat), while the Agile Manifesto states 'Individuals and interactions over processes and tools'.
On the one hand, it is the reason why Scrum is so successful in corporate environments, on the other hand it is also somewhat non-agile. That is why I tend to call Scrum the least agile Agile Methodology and a good starting point for Agile transformations.
Just don't forget to keep moving on as your Retros lead you the way.
Agile and Scrum isn't the same thing. Even if Scrum in someways are agile. The "original" agile process, or the first videspread variant XP didn't mention any dailies. Scrum as such is much a way to adopt XP into a large cooperate environment.
The problem I see with various flavors of Agile is that they don't fit in particularly well with how things actually get done at companies.
For example, teams running Agile are very reluctant to give both a delivery date and a fixed set of features. They're willing to promise one or the other, but not both. And that's a problem, because the whole rest of the organization really wants to know when they can announce the release to customers. Planning for releases tends to be a really big deal, the pressure to make promises of both functionality and delivery dates is very strong.
Also, Agile methodologies tend to assume you are in close contact with the customer, who can tell you what they actually want and decide how things should work. But this is rarely the case; typically you have a PM or something like that who is in touch with the customers, and is supposed to understand what they want. But this person is rarely senior enough to actually make decisions; important decisions are made by a dev manager or a project lead or someone like that, with the PM just providing input and perspective.
Finally, Agile has this notion that everything is supposed to be handled informally, verbally, person to person. And that's fine for small tweaks to the product. But as soon as you start building something big enough that it takes months and crosses team boundaries, it gets really useful to have an actual document explaining how something is supposed to work. Such a document is an invaluable record on what has actually been decided, and anyone joining the project or wanting to contribute to it absolutely should read it. But Agile tends to discourage creating such documents in the first place.
Given that Agile clashes so hard with how actual organizations get things done, it rarely gets adopted in anything approaching a pure form. The practices that tend to get picked up might be called Agile-light: sprints, daily meetings, and task estimation in points.
The fundamental insight behind what became agile is that it isn't actually possible to have both a guaranteed delivery date and a guaranteed set of delivered features. The reality of software development just doesn't allow it.
Businesses don't "get things done" by operating as if they can have both. That's why projects fail, businesses cut corners, and then inevitably ship broken products or don't ship at all.
Most of the "agile methodologies" are nonsense dreamt up by borderline con artists attempting to sell their services. The fact that it's an either / or choice - and that nothing can get around that choice - is inherent in the nature of the work.
I agree with you that it is not possible to both fix the feature set and fix the delivery date and expect to consistently succeed. But it is also not possibly to tell upper management, who are dealing with a whole other set of difficulties, that they have to pick a feature set or a delivery date and that's all there is to it. If you do that, they'll reject your advice, and find someone else who'll give them a more palatable message.
The best I can come up with is the notion of a double contingency plan. Engineering agrees to a set of functionality to be delivered and a delivery date. This is inevitably going to be a bit optimistic, because people consistently overestimate themselves.
To deal with that, the first contingency plan addresses the question of what should be done if things are not converging to the ship date. The plan here is to keep the ship date, but ask hard questions about what bits of functionality actually need to be kept. What are the actual P0 - MUST HAVE features?
The second contingency plan addresses what is to be done if the first one fails. At this point engineering has already done all they can. They have pushed as hard as they can, and they have deferred every feature that is deferrable. They are down to the actual MUST HAVEs. Now the rest of the organization has to figure out what to do with a product that is inevitably going to be late. What is the alternate ship date? What customers are going to be really unhappy. And so on.
It seems to me any large engineering project should think out these contingency plans in advance. What will they do if making the deadline starts to look daunting? And what will they do if making the deadline turns out to be impossible?
> Also, Agile methodologies tend to assume you are in close contact with the customer, who can tell you what they actually want and decide how things should work.
Yes. Kinda :) But the issue isn't want. The friction is actual make-an-impact business needs.
It's easy to sit around a conference table and spitball wants. But trying to bin that person or group down to specifics as well as resolve disconnect and inconsistencies between the ideas and faces go blank.
Customers want the luxury to spit out wants without having to take the time to knuckle down and do the hard work of defining needs. They have a "you figure it out" attitude. That leads to assumptions. And assumptions lead to dysfunctional product / features, for which the engineers get blamed. Again.
Agile is a worthy solution to this problem, but when IT is treated as a service provider and not an equal partner the tool (i.e., agile) gets mutated to a point it's not truly agile anymore.
> We have found that the role of the project manager is counterproductive in complex, creative work. The project manager’s thinking, as represented by the project plan, constrains the creativity and intelligence of everyone else on the project to that of the plan, rather than engaging everyone’s intelligence to best solve the problems.
Pretty much wish this was a defined part of agile, most of the time all my boss/pm is good for is maybe reminding me of meetings. They never understand what I’m working on to help, but they have power to make giant decisions and elevate problems I have been waiting for the client on for some time. Idk if this is a common theme.
I read a comment here a while back I agree with: your project manager, a good one, should remove obstacles that could slow you down, and anticipate them. They will only really interact when they notice bad patterns; like you being too slow. And most of the time let you be unless you introduce to new team members or elevate issues. Focus on your major tasks, allow them to manager the small mundane.
I hate being micro managed as much as the next guy, but I've also had way too many coworkers over the past decade who can't seem to just sit down and get the job done. They fiddle and tinker and explore way too much. It's helpful to do that at times but many lack the discipline to produce software without a PM to answer to. I wish it were different, but it isn't.
My current PM is great and if I found out the management wanted to get rid of him, I'd vouch him and go to war if I had to. Good PMs are indispensable, in my opinion.
This is why Agile has a love hate relationship with the engineering public. For some engineers its a hindrance to dedicated work. For other engineers, they have the realism to see that many programmers need direction and direct feedback to be profitable for their companies.
The thing is, some people needed direction should not imply everyone get punished and loose any semblance of autonomy. Which is literally agile approach. Some people are issue, therefore everyone is subject to elaborate system of autonomy and individuality removal.
Plus minus subtle intra team politics that allows you to circumvent the above.
If your team is led by a manager, then it is solving a management problem, and if your team is lead by an engineer, then it is solving an engineering problem. Managers are not good at solving engineering problems, and managers can and will fill management-shaped holes with engineers until everyone is either burnt out or checked out.
In my opinion and experience, the best functioning and delivering teams are the one doing Agile without even thinking or saying that they are doing Agile.
It is team that are working intelligently with trust between members. Each member does it job, feels responsible and autonomous. Enough to do by itself everything needed for the project to succeed and with other members trusting him to be able to do what he needs to do without micro management.
The tough part for me has been experiencing a team like that, then moving and having no idea how to help create a similar environment with my new team. Any tips?
In my opinion, to start with, you need to have "senior"/experienced members. Most junior still need to be taken care of before they could be blindly trusted on some topics.
Also, in my experience, most of cases like this happened in places were the management was kind of "absent" or "defective" in some way. For example when you have the next level of management hierarchy in another place/country.
In such a case, often, the dev/engineers are considered autonomous and they are just trusted and expected to "take care" of all the technical things, with little supervision.
If you are already inside a team, I think that there is little to do to create a similar environment, except trying to get the maximum "power"/"position"/"space" from the company, and using that to organize yourself with the persons you are interacting with in your team.
Trust is the key element. But other members have to earn your trust, and on the other side, you should also ensure to worth the trust of your company by being reliable and deliver. Most of the time, even management will let you a lot of "space" if you are use to reliabily take over "loads" off of their shoulders.
The worst case scenario is when there are persons in management that have "bullshit" jobs like "scrum masters" where they have to do "something" to justify their work.
Otherwise, if you are in the lucky position of creating a team, the best thing is to try to have a multi disciplinary team with most of the people with a specific responsibility on some components of your system.
This is the exact opposite of saying that you have a an agile pizza team with all members that should be equal on all subjects and easily be interchangeable at will on whatever subject...
I've been giving this some thought recently. Ultimately I blame Scrum, it is so poorly aligned with sustainable software engineering and so widely open to interpretation that its no wonder that every project seems to inevitably end in big rewrites. Scrum gives all the godly power to a product owner, invents a baby sitter in the scrum master and leaves everyone else to be the "dev team". I know there will be statements about it should be collaborative blah blah, but the fact is the named roles have gravitas and the amount of responsibly in the product owner individual is untenable.
There is also then the wildly misunderstood aspect of estimation. In my experience the only value beyond saying a feature is easy or hard is that it does spark discussion among engineers, the irony being if said discussion goes on for too long it usually gets shut down. Adding estimates to work you are going to do within the next 2 weeks seems of limited value, it changes no behaviour you will still do the work.
I feel we would be better served by reinforcing the principle that all of our purposes within the organisation is to deliver a quality product for the customer.
Product development is responsible for taking ideas and generating specifications for product features while software engineering are responsible for taking specifications and implementing them within a software product. This simple process should be monitored and systematically improved to deliver better on the core principle.
Here we are 20 years later and we still can’t agree what agile even means. That is where it failed. It’s not concrete enough, and maybe it was never meant to be.
I feel like they had a great idea, gave birth to something, but then failed to nurture it and we are still evolving a solution. Ok we got scrum but we all know that’s a complete shit show.
What agile is really missing is that it doesn’t touch on leadership. We like to blame management and say they should let us do what we know, but we don’t lead. Decentralised control only works when everyone leads.
Agile taught me about refactoring but in reality I get less opportunity to refactor bad code than I've had under Waterfall-type process. My understanding of our evolution into Agile has always been like:
1. Big Ball of Mud: work without a plan
2. Waterfall and alike: make a very elaborate plan and stick to it
3. Agile: work without a plan, but promptly refactor issues caused by lack of foresight
Waterfall worked well but is too slow to respond to change, so Agile replaces one-off planning with iterative refining. So far, great idea.
However, if the backlog is never short of business requests, and business requests are always higher priority than refactoring, then when will refactoring ever be done?
If we don't have architects anymore, but also don't designate time to refactor, we are de-facto doing Big Ball of Mud with stand-ups.
Agile != "work without a plan". Only morons and the misguided take it to mean that. Of course, many companies seem to be run by morons so I suppose it's reasonable to interpret it this way because it's become a common experience for many.
Interestingly, one of the point in the manifesto says "Individuals and interactions over processes and tools", yet there are all sorts of processes and tools that now exists for Agile. What an irony.
I've been implementing "agile" at my new company, and while we do use Jira, I've made it abundantly clear that it's just for my own sanity to track what we're up to.
I could just as easily do this in a notebook, but it wouldn't be indexable or searchable, is all.
I never really understood the hype around (f)ragile (as one famous google engineer called it in a small closed circle a few years ago). I think the main problem is that in the past 7-8 years it has become more of an evangelism effort rather than anything.
> The important piece that gets forgotten is that Agile was openly, militantly anti-management in the beginning.
Yet here we are: The process just became an endless rabbit hole of filling jira tickets, workday schedules, and a bunch of other systems(including a shared google sheets table as it was in a company I used to work for with 5000+ employees) which easily eat up a day of your week. Detrimental if you are aiming for a deadline. And while I embraced wfh and felt insanely comfortable with it, it was used as an excuse for management to further push those things further down everyone's throats. The end result was that, at least from an engineering prespective, work became more of a marketing team meeting, filled with absurd abbreviations and processes which hold no value and only drag you down. Another problem is when you get an email from jira that someone assigned you a ticket called "Implement X in Y" with no further explanation when you click the link. It's absurd that in large companies(think 250+ people) your value is determined by how many tickets you've ticked off. "Implement X in Y" seems like just another one, but in many case those 4 words end up being 8 separate things, each of which can take several days but no one cares even if you described those in detail in the comments. You might think that story points solve that but they often don't. Imagine the following scenario: you are tasked to hook up a system to an s3 bucket to store data but you have restricted access to the aws console so you can't even create a bucket on your own. Then it turns out that the vpn is set up wrong and you can't even resolve the host if you are connected to the vpn. Then it turns out that the library you use has some bug in it or it's incompatible with some of the other libraries you use so you end up upgrading a bunch of libraries, patch up a large codebase and only then be able to get on with the s3 bucket thing. At first glance what you would assume is a 2 hour task tops ends up being a week and a half of your life. And it can be insanely demotivating when you have the same thing to report that you are working on the s3 thing in your daily scrum for a week and a half. Which is even worse when your managers have little to no tech skills beyond excel for instance. The point of my rant is that agile became the thing it was supposed to destroy - a time tracking system for the assembly line.
Edit: those things don't seem to apply for small companies/startups because... Well they are small and you get to know everyone on day one.
I think spending too much time in a large company is damaging, possibly permanently, to a developer's ability to connect value to work.
On a basic level, Story Points are there because if you can't tell me how long something will take, I don't want to give you money to go do it.
Everyone has to deal with this, at every level. CEOs think about this, janitors think about this, literally everyone is constantly calculating estimated time to complete a task as a key metric about whether or not they should do the task.
All a Story Point should do is make that a conversation, not an isolated person's random guess. That's it. I don't see what's harmful about that.
I spent around 11 years in large companies(anywhere between 300 and 6000 employees). It highly depend on what you work on and what's your work ethic. In all honesty beyond circumstances which were outside my control, I ended up in a small company and just now I realize how much the idiotic bureaucracy truly bothered me. And I'm acknowledging that precisely agile facilitated this hell.
I think you are looking at it from an r&d (still evangelistic) prospective, but now picture rewriting a truly ancient system still operating on mainframes(and the original developers and maintainers are no longer among the living) in a modern language where it's not a question if something is worth doing or who will do it-it has to be done. Figuring out how the old system works is a combination of reverse engineering and brute forcing. I've been there and trust me, in those circumstances story point is a synonym for a random number. This is a real life example and in those conditions agile doesn't only crack, it collapses and it mentally crushes on top of you cause you are still forced to stick to everything agile.
What I'm saying is that agile and by implications sorry points work in some extremely specific circumstances but in the vast majority of cases it only adds multiple layers of complexity which does nothing but waste valuable time.
There are nearly zero "must spend, at any cost" situations in business, so no I don't agree with you assertion that "it's not a question if something is worth doing". It's always a question if something is worth doing.
I've seen your argument many, many times before, and it comes from people who have divorced their understanding of value from their understanding of work.
You don't get paid to work, you get paid to provide value, and I'm not saying that's right or how it should be, but that's how it currently is. If, through your labor, you can't provide value above your cost to a company, the work you're doing is not worth the cost. One way to get an idea of how much what you're doing will cost is to ask you and your peers what you think it'll cost, and one way of measuring that cost is a Story Point.
This means you were lucky and got to work in those isolated environments where you never had to migrate such an ancient system without compromise and 100.00% identical operation or dealing with "we must have/support x, no matter what, cost is off the table". I've been through that countless times. Migrating ancient systems, writing drivers for hardware with close to 0 documentation or specification, "ads absolutely immune to ad blockers in our apps", just 3 personal examples where any value for a story point is an arbitrary number and a wild guess at best and where the only thing I got from agile was countless sleepless nights, no weekends or holidays and still barely making it in time. Not because I was locked to a desk but because of my personal working ethic.
Even when a company is facing an existential crisis, your estimation is important to help decide if they need to provide additional resources or even replace you if you're not able to do the job (among many other things). They're not going to throw money at you forever, and demanding blind trust is completely unreasonable, especially so in an existential crisis.
There is simply never a situation where not having a sense of when work will be completed is acceptable. You cannot concoct a scenario where that's okay, and the fact that you're trying to kind of reinforces my point about work vs. value. There is no "infinite value" scenario, that doesn't exist.
Pretty sure I just gave you 3 examples where no one cared how much X would cost. "We want it by Q3, figure it out". Where is the documentation? "¯\_(ツ)_/¯". Who built the old system? "Last one died in 98". Who knows how X works? "¯\_(ツ)_/¯, you're smart, you'll figure it out, just remember, Q3". As I said you're either lucky or speaking from the so called "top management" perspective. Things look very different for average Joe.
Yeah, average Joe in your examples here isn’t being given the whole picture. I’m not sure what your point actually is; are you saying that since Story Points don’t help you specifically, they’re a waste? Don’t you get how myopic that is?
My point is that they are often as relevant to reality as the flying spaghetti monster to spaghetti. Read my previous comments dump whatever you have in memory in an s3 bucket? Story point 0-give me 10 minutes. Then why did it take a week and a half? Cause someone from another team across the world has to grant permissions which was 3 days of discussions, then the VPN was messed up, which took another 2 teams on the other end of the planet 4 days to fix, 10 minutes to code it and 10 minutes for the cicd pipeline to deploy it. 0 story points, right. That's my entire problem with evangelistic crap like (fr)agile, story points, sprints, epics and so on: they do not reflect reality in any shape or form.
I don't think there is an understanding of why agile works, and why it is (essentially) impossible to implement in most places.
One subtle, but necessary, effect of the original scrum sprint planning is that it splits accountability between product owner, team, and master.
The effect is that, upon failures, there is a way that developers can rightfully blame the product owner or master. Part of the point of time-boxing increments is checkpoints of accountability, so that once the "contract" of a sprint has been fulfilled, the devs can not be held accountable for its product value.
If this mechanism is not in place, it means the product owner/master (or whatever title) is just another name for plain old manager with mandate to overrule anything, and in the worst cases with influence over careers of the devs. This is the high entropy state most organizations converge to. In these cases, all product failures will be blamed on the devs (in effect, if not verbally.)
In an effective agile organization, there can't exist mechanisms where blame/consequences for failures can be shifted downwards postfact. But this is also the basis for most old organizations. Hence, implementing agile in older organizations will never work.
I believe agile fails for the same reason devops fails. The people who did ops or waterfall project management didn’t go anywhere. They just got told they’re using a new buzzword with the same responsibilities. Try telling a classically trained project manager that we should have less process and watch their head explode. Of course they revert to what they know the moment there is a breakdown.
I did agile back in the late 1980s, in the days of MS-DOS and Turbo Pascal.
The customer had a problem, he knew he wanted a computer in the solution. The first person he contacted to solve the problem hired me to write the solution. He hated the hardware chosen, and went off to make is own choices.
Having chosen acceptable hardware, he hired a different person to solve the problem. They also hired me, we pitched a solution. It took about 2 months to code.
The program worked as promised, met all the requirements. Up to this point, it was essentially waterfall. We agreed that a wider sale/deployment would be contingent on me working directly with the customer on-site in an agile fashion.
I wrote code, he brought a random power plant worker in to try it out (in the days before everyone knew how to run a PC), and we iterated. Everyone was quite happy with the product for years, until networks, Windows and other reporting systems made it obsolete.
Nobody knows the details of what is useful until there is a prototype to work with, and get the feel of. Agile is the way people have been solving problems forever.
There seem to be a lot of "No True Scotsman" threads here. Since I did this before "agile" was a thing, I don't have to worry about it. 8)
The basic premise of Agile is that it is a part of an adversarial system. The adversaries are "devs" on one hand and "business" on the other. While the purpose of the devs is to be an executive arm of the business, the actual goals of each are coined in different languages to the point that they are frequently not aligned.
It is important to recognise this, and carefully manage the necessary give and take. Finding the right balance is tricky and higly context-specific.
Could it be that firms are simply claiming to be "Agile" irrespective of how they actually work because "Agile" has good PR?
Customers may think that "Agile" teams are stacked with experts all working in a state of grace, effortlessly pulling off technological miracles.
Behind the scenes, however, most of the work may have to be delivered by junior devs under the supervision of stressed-out micromanagers who use top-down bureaucratic control to progress the work.
If nobody does something there is a chance it doesn't work. The most problematic point to me seems to be point 3 'customer collaboration'. Does anybody know how to do that in real life? What does the sales team sell then? And more important how do you prevent feature creep from the customers side wanting more and more things during the process? To me I only see this working if you sell working time instead of a product.
> To me I only see this working if you sell working time instead of a product.
This is what we do at the consultancy I work at - billing is simply based on time & materials. We work from our customer's premises (when there isn't a global pandemic) and we have people from the customer integrated into our team, so customer collaboration is constant and continuous. Feature creep doesn't really happen, because all parties know what the budget is and how much our time costs.
The sales team sells what has already been delivered.
In my experience, the customer collaboration happens through a proxy called the product manager. It is their job to hold meetings with customers to figure out priorities.
You don’t “prevent” feature creep ever. It is part and parcel of development. You can, however, manage it by restricting when the goalposts change. In Scrum, that’s at sprint boundaries. The most important bit is that the customer chooses priority but the developers choose velocity.
Except most customers only pay when it goes live, or reaches major milestones, and then you are out of budget, struggling to find another parallel project to somehow keep the team in place, before management states it is time to move on.
It’s been a long while since I read the manifesto last time.
> Responding to change over following a plan
“Responding to change” is treated as a right to bust WIP at any moment in time. All engineers I have worked with want a roadmap and a plan that has enough room and flexibility to be changed due to some external circumstances (bespoke “change”).
> Working software over comprehensive documentation
This statement puts two characteristics of a software product (be it SDK, library, source code package, binary, whatever) into contradiction. Working software is accompanied with comprehensive documentation.
> Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.
Late requirements change is what all engineers hate… And as stated in a number of comments here customers want no more than a faster horse. Best products ever made were not made based upon focus group feedback.
> The best architectures, requirements, and designs
emerge from self-organizing teams.
Are scrum masters an antipattern then or just a sign that the team in question is not self organized and immature?
Bottom line: any “agile” methodology I’ve come across and experienced myself for the last several years is a mix of cargo cults, religious ceremonies and abusing the word “agile” to justify chaos, incompetence, ignorance and arrogance.
What in essence all the agile methodologies are meant to be is the domain specific extension of the PDCA cycle.
In my opinion the “problem” (what problem?) is not Agile but the mismatch between what tech companies want and what technical people usually want:
- tech companies want to push decent features live every 2 weeks (the usual sprint duration). They follow the mantra “move fast and break things”. Technical debt is fine for them as long as money flows. They want to beat their competitors. This makes totally sense from a business perspective, of course
- certain tech people (in my experience) don’t want to move fast and break things. They don’t want to break things, they want to produce products of quality, stable, with minimal defects... if that comes fast that’s fine, but usually it takes time to produce something of quality (at least for average developers—-I am one, and the vast majority of developers are). This makes sense from the point of view of someone who cares about their craft
That’s the mismatch. Companies love Agile (even if it’s done wrongly); tech employees usually hate the very notion of estimates, sprints (are we even in a rush?l, story points, etc.
A lot of time, especially with Scrum, team communication is now formalized and non-team members participate and evaluate "the process" (indirectly). This can extinguish direct,non-formal-communication and can lead to CYA attitudes in teams...
"A Process" can never be about "the people".
Let's say someone would implement Scrum for football teams. Every team could follow the process to the T, n times training, 2 times weight lifting per week, daily meetings, n times cardio work, mobility training, strategy planning/training etc etc.. At the end, in the game there would still be good or bad teams. And the good team would probably be p*** off because they have to do so much formal stuffs just to "do the process right" and ensure "every checkbox in the process list has been ticked off".
So yeah, I guess it is up to agile teams .. let's deliver in increments and let's ensure it is what the customer needs. Everything else is secondary.
Agile both succeeded and failed because it's defined as "not waterfall."
Since no one does pure waterfall, everyone does Agile.
Even this essay encourages that interpretation: "Everyone in this group had deep experience writing software, and they were all looking for an alternative to documentation-driven, heavyweight software development processes that ruled the day."
Did that "everyone" include Mac development in the 1980s? Or Amiga development? Not from what I've read of the history.
Did it rule the day for the development of gcc, the Linux kernel, Perl, or CPython? No.
I pulled out my 1996 copy of Steve McConnell's "Rapid Development." Page 271 says:
> In addition to providing explicit support for morale, Microsoft gladly trades other factors to keep morale high, sometimes trading theme in ways that would make other companies shudder (Zachary 1994). I've seen then trade methodological purity, programming discipline, control over the product specification, control over the schedule, management visibility -- almost anything to benefit morale.
The Zachary 1994 citation is the book "Show-stopper! : the breakneck race to create Windows NT and the next generation at Microsoft" at https://archive.org/details/showstopperbreak00zach . A quick read (search for 'documentation') shows Windows NT development did not use a 'documentation-driven, heavyweight software development processes'.
And of course oodles of small software projects in the microcomputer and early web era were written with no formal software development processes at all.
This "rule the day" statement must therefore be interpreted within a narrow context.
Anecdotally, as someone who was doing software development in the late 1990s, yes we were doing it wrong, and Agile spoke truth to that. Getting this message out was an important change. And if that took "a few consultants gathered at a ski resort" issuing a manifesto, then so be it.
Was "Everyone" doing it wrong? Mathematically improbable. Were the vast majority, the mainstream, stuck in a dysfunctional waterfall system? Oh hell yes.
And the usual answer to the failure of up-front planning was "Clearly we didn't plan up-front enough, we need plan even longer". It's a self-reinforcing pathology. So is the use of JIRA, but that's another story, post-agile, not pre-agile.
> They were developers, programmers, scientists, and engineers. They were still slingin’ code* and working with their stakeholders to solve problems. This is important.
Utter nonsense. They were consultants looking to sell consulting services. Just in the next paragraph:
> Many of these people already had a methodology they had created and/or were proselytizing.
When “Agile” ideas are applied poorly, they often lead to more interference with developers, less time to do the work, higher pressure, and demands to “go faster”. This is bad for the developers, and, ultimately, bad for the enterprise as well, because doing “Agile” poorly will result, more often than not, in far more defects and much slower progress than could be attained. Often, good developers leave such organizations, resulting in a less effective enterprise than prior to installing “Agile”.
I can totally relate with this experience in a previous company I've worked with. They effectively starting the transition to Agile, but the execution was so poor and the general culture was so immature with a lot of chain of command and top-down that it ended up being a total toxic nightmare. I end up blaming Agile for this at first, but now i'm realizing that was not the tool.
My experience at Amazon Google and now Pixielabs tell a different story, all the points proclaimed in the agile manifesto are the desired states of daily work. People are speaking in the same or similar mental framework of building software, which is fully embodiment of the manifesto, or at least it's spirit.
That is too bad. When I first read the Manifesto, I said “These folks got it!”
I tend to work that way, now.
Myself.
Things get difficult in teams. Especially cross-disciplinary teams, and aggregate efforts.
Much as we like to denigrate managers (DISCLAIMER: I was one), they are necessary; and not as a “necessary evil.” Good managers can be amazingly effective and well worth it.
Unfortunately, like in any vocation, the good ones are rare. The same goes for good software developers.
The Agile Manifesto was written by a group of working software engineers, with decades of experience, at the top of their game.
Precisely the type of engineer that today’s hiring process tends to filter out. They don’t really represent the current field of practitioners.
Like so many “perfect world” scenarios, the Agile Manifesto was designed for a “perfect audience.” As the article points out, when the manifesto hit the real (imperfect) world, the wheels fell off. To make matters worse, the designers tend to get huffy, and blame the people making a hash of it; which doesn’t make friends. They may be technically correct, but humans are messy, chaotic beings, that tend to have highly individual worldviews, abilities, intelligence, education, experience, workflows, and motivations. Most folks expected to actually implement an objective bear little resemblance to the ones that developed the plan. If the planner fails to account for this, then (in my opinion, as a planner) it’s the planner’s fault.
That kind of sums up human history. Groups of elite thinkers develop a Grand Plan, then it gets bloodied and bruised, once it hits the proletariat. Sometimes, with horrendous results (Cultural Revolution, anyone?).
As someone that actually designed a successful system for the proles[0], I can report that designing real-world solutions for a distributed, heterodox, self-driven, target audience is difficult, messy, unintuitive, humbling, frustrating, and, quite often, absolutely infuriating. Not the kind of work that folks at the top of their game like to do. Frankly, it sucks, but I think that it’s also the best way to make something that actually has a chance.
I wanted to add that follow-through is also important. When I designed the system I referenced, I did it with an understanding that it would be a years-long commitment. It's like having children: Making them is fun. Having them is easy. Raising them, however, is not fun, and not easy.
But we need to do it. For myself, I spent ten years, traveling around, giving presentations, classes, gladhanding, answering questions that I thought "should have been obvious," suffering some withering attacks, and fine-tuning the system, as I realized I screwed something up. I also went around, looking for successors. I wanted to become obsolete (which I have).
> Good managers can be amazingly effective and well worth it.
Good Xs (where X = developers, managers, designers, etc.) can be amazingly effective and well worth it. This is obvious. The vast majority of managers out there are average, and so they are a necessary evil. Compare this to the situation: the vast majority of developers out there are average (I include myself in this group )... and this is fine, they are not seen as a “necessary evil”.
Three months ago I found myself writing a proposal for work that would take several times the budget that was available. A manager had an idea: why not do it 'agile'? We would have two-week sprints, and at the end of each sprint a meeting with the customer to present work and define the direction of the next sprint. Great idea, right?
So my next task, obviously, was to define the content of all the sprints and write them down in the proposal. I was well aware of the absurdity of the whole thing but did it anyway, carefully planning out what would be done in each sprint. Sure, it sounds stupid, but just look at how cute it is! It's like a whole bunch of little waterfalls! People pay good money to see such nice waterfalls, you know!
Last office had a team with 5-years of well planned out sprints. I could never dissuade them from the notion that this was "agile". They didn't use the end of each sprint to change direction if a problem was coming up, sticking to the plan for months after things started going wrong. Then they sat down and redid the next 4 years or so of sprints. Repeated after the next year. I guess it was more agile than making a 5-year plan and never changing it, but changing the plan annually is hardly responsive either.
In my case, the proposal is contractually binding, so the contents of the sprints are fixed. Also, the customer won't be available during the period when the work takes place (holidays in Europe, you know), so they wouldn't be able to provide input anyway.
Of course I'm assuming that they'll kick us off next week. Right now the project is in the "let's delay starting until missing the deadline is guaranteed" stage. One more week, and then my careful planning will have become officially impossible and it will be panic all around, and demands that I work days, nights, and weekends to make up for the delay they themselves caused.
Do you want to guess who isn't allowed to go on holiday because of this incredibly urgent project? :-(
The Finance department never bought into it. They needed to provide funding to product owner initiatives that aligned with the business and then just let go of the process. C-suite and finance people will never do that.
Agile is (maybe a bit oversimplified) about releasing as often often as possible.
Delivering sooner, not faster.
To do this, decision makers must be close to the team, and ideally a part of the team. Either managers are part of the team, or the team a given the authority to make product decisions.
Full time managers lose power and influence either way, and I think this is the real reason Big Corp never really bought into it except on paper.
I think one piece of the Agile origin story that’s missing is that it was heavily influenced by software contractors - people who worked on software that had a definitive “end”: either because it was feature-complete, it was time sensitive, or the client had a fixed budget.
Many of Agile’s problems arise when you begin to apply them to long-running products that undergo continuous cycles of improvements - stretching years rather than months.
Okay, so agile was a very nice and principled idea.
And what we got from that through corporate senior management involvement is some sort of “scalable agile framework” or a minimal surrogate of “agile scrum”.
Might not be ideal, but it still generously beats the waterfall with quarterly “slave galley-style” weeks of overtime to make it to “the release” and to be able to deploy things that actually already became irrelevant 5 weeks into the release cycle.
Senior management in a lot of places is by now trained and groomed to see everything as a process, so principles don't cut it.
Similarly, consultancies need to sell "products", i.e. implementable processes and change, so again principles are a problem.
Lastly, in a lot of places the actual users or product owners from the business side are only involved via representatives, so there is no closed loop to run.
The biggest problem I have with agile is the absoluteness of its proponents. “There is no other truth than agile, and if you don’t agree you’re old/immoral/…”.
It’s the sad combination of not being open to test other approaches and condemnation of people questioning it.
I think one of the biggest indications of failure (because it’s been morphed into something shit by all these business manager types, and not because it’s fundamentally flawed) is the fact that we have dedicated “scrum masters” that never rotate.
I’m the only one who find the role (and the name) “scrum master” shocking? First and foremost anyone’s can become a “scrum master” in a few weeks and get a certificate that proves it. I don’t take it seriously because of this. Secondly, we don’t have “linux masters” or “python masters” or whatever; why do we need the silly title of “x master”? Imho, it makes a disservice to the people who actually hold such role.
Agile is like a perfect example of a lot of things. Publishing a "manifesto" makes the revolution analogy on-the-nose.
Dissident manifestos tend to share a the same failure point. They're heavy on critique of the system that they want to overthrow, hand-wavy on the system that they want to enact.
The Communist Manifesto, to pick on the obvious example, is mostly about capitalism, other (wrong) versions of socialism.. notably reactionary socialism. It's also about the struggle to bring about revolution. There's surprisingly few paragraphs about what communism will do differently, once the revolution takes place. Liberal revolutionary manifestos was similar, with French and american revolutionaries settling (or not) on a system of government only after overthrowing monarchy.
The agile manifesto does outline a lot of how agile works, but the most compelling part was its description of "waterfall" and all its ills.
Liberalism and communism, in their idyllic literature, never really contended with the fact that these were alternative methods of "ruling over a population." Agile never contented with Agile was as a people management system. Well... Agile is a way of telling developers what to do. It is a people management system.
Where its completely unlike the political analogy is that agile was derived from working systems. It wasn't just an idealization. Ironically though, it ends up in the same place. What worked well for particular teams became the ideals.
I think the ultimate stinker though, was the "political economy" of agile. A company where everything works great isn't going to tear out their process and bring in consultants to implement a new management system. It's companies that are failing to produce software well that do this.
> The Agile movement is not anti-methodology, in fact many of us want to restore credibility to the word methodology. We want to restore a balance. We embrace modeling, but not in order to file some diagram in a dusty corporate repository. We embrace documentation, but not hundreds of pages of never-maintained and rarely-used tomes. [...]
The problem is: the manifesto states clear dichotomous preferences without nuance, and it certainly not for example states that it embraces well-maintained and useful documentation but that "[we value] working software over comprehensive documentation".
See? It is written "comprehensive".
Not "shitty".
And I even agree that maybe "comprehensive documentation" can be a dangerous concept if taken too far, but that's pretty much true for anything taken too far, and actually I have never seen a problem in this direction, but pretty much all the time and extremely often in the opposite way (I could say : a comprehensive lack of documentation...). So maybe de-emphasizing "documentation" was not that smart...
Either it was very poorly written or there is an attempt at rewriting history. At the end of the day, you can't just hand wave the shortcomings originating directly from the text by just stating "oh but we did not mean that, wasn't it obvious?" -- well... no! it was not!
Likewise for the other "values". They seem to have been written because of a perceived lack of balance (and maybe there are even again some adjustments to be made and they are not exactly intended to mean what is written...) in the personal experiences of the signatories, however there is no provision against balancing too much in the other direction, or against inappropriate applications in specific contexts (the "preferred values" are actually extremely context and project dependent)
So maybe people actually got what was written, or maybe the whole thing was so vague that they got random outcome from a mostly cargo cult application. And in a few case, intelligent practice in a good context, so good outcomes; but when that happens, would the successful team have done poorly with other preferences of "values" or with other stereotypical day-to-day practices (weird btw when processes are to be deemphased)?
> What do you mean you’re going to start building the software before you’ve gathered all of the requirements and estimated every piece of functionality? That’s insane!
Like, the significant software from the 80 or 90 was written like that (in inappropriate contexts)?
And when it was (again, in inappropriate cases), was the solution to settle on the four stated value preferences? Why? From where does that even come from? Where is the evidence? How can it be applied? Why can't I write precisely the opposite and say "see? here is my solution!" -- if not just because of the obviousness of some outcome: yeah not valuing working software enough will probably not lead to better working software. My point, however, is that stating that you value working software more cannot yield to actionable things in not completely dysfunctional environment, because whatever their current practices are everybody will say they want that and what they are currently doing has value to achieve that goal. And the other value preferences are highly contextual.
There is no silver bullet. Not in technical areas. Not in project management. Especially not when project management is not interested in the technic; that is: in the project, if the project is of a technical nature...
Badly done agile made me lose interest in software development. Daily scrums that amounted to one upsmanship and lasted entirely too long. Planning meetings that were mired in politics. I went from wanting to learn the deepest minutiae of languages and practices to only coding the bare minimum at work. Only now (8 years later) am I just finding some joy in coding again, mainly because coding is not a large part of my day job. My dev jobs made me feel like I chose a path of arbitrarily short deadlines and stress while the non development folks largely coasted. I ended up blaming agile practices for a lot of it. I think it still deserves some blame because pushing back on bad practice implementation should be a bigger part of the manifesto.
The customer doesn't know what they want
Agile assumes as a first principal that including the customer throughout the development process will align the building team and the customer to come to the same conclusion.
This is almost never actually true. Having built and managed a lot of products I can state fairly confidently that the amount of time the customer has, and clarity about the problem they want solved is orders of magnitude more ambiguous than is required to actually build and deliver something to their satisfaction.
In my opinion successful products, and I mean ones with significant flywheels with customers and viral growth and stickiness are with few exceptions - accidents. It was someone who had an interesting thought and a lot of people for whom the product was good enough for their desire that they often didn't even know they had
You can't write down how to do that, it's like asking a nobel prize winner how they came up with their discovery. It's not repeatable. Some people have better intuitions than others and these are the people who are repeatably successful with products. But it doesn't generalize.
That said, the fundamental problem isn't wrong in theory, it's just naiive in practice.