Hacker News Comments on
Agile is Dead • Pragmatic Dave Thomas • GOTO 2015
GOTO Conferences
·
Youtube
·
151
HN points
·
31
HN comments
- This course is unranked · view top recommended courses
Hacker News Stories and Comments
All the comments and stories posted to Hacker News that reference this video.This reminds me of Dave Thomas' "Agile is Dead" talk:
In his talk "Agile is Dead", Dave Thomas (one of the creators of the Agile Manifesto) speaks about how distorted and perverted the manifesto's intentions have been by the "Agile" industry.Striving to be agile, flexible, adaptable is a very valid and useful principle.
"Agile" as a noun, the cult-ish process-training-industrial-complex is not at all agile.
Link to the part where he recalls the creation of the Manifesto https://youtu.be/a-BOSpxYJ9M?t=384
It is immediately followed by the difference between agile (adjective) and Agile (noun).
Agile IMO has been perverted by business and middle management to facilitate bean-counting.
"Agile is Dead": https://www.youtube.com/watch?v=a-BOSpxYJ9M. Good talk about Agile if you havn't seen :)
⬐ andrei_says_This is a talk by Dave Thomas whose name is on the Agile Manifesto.I highly recommend giving it a watch.
In short, “Agile” with capital A is a cult-like training and process-defining industry gone out of control, causing more harm than good and the opposite of agile.
agile development, as defined in the manifesto is simple and productive - make a step forward, look around, adjust, make another small step.
There’s a wonderful talk by Dave Thomas, one of the creators of the Agile Manifesto, about the perversion of its original intents by the “Agile Industrial Complex”.Basically, Agile with capital A is ridiculous. But needs to exist in order to sell the industry behind it.
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.Agile is Dead - https://m.youtube.com/watch?v=a-BOSpxYJ9M
Here’s a blog post by him: https://pragdave.me/blog/2014/03/04/time-to-kill-agile.html
https://jaymeedwards.com/ provides some good content on his Youtube channelhttps://www.amazon.ca/Elegant-Puzzle-Systems-Engineering-Man... helps to understand managing from an engineering perspective
To understand some of the history and context: https://www.youtube.com/watch?v=a-BOSpxYJ9M
A bit dated but still useful book: https://www.tablegroup.com/topics-and-resources/teamwork-5-d...
Best of all, for surviving at a difficult organization, invest in yourself and get a good therapist. I can't recommend this enough. Burnout is the worst but you can manage if you have solid, professional support to aid you.
⬐ ornornorI’ve been watching Jayme Edwards videos for the last couple of weeks and they’ve been very helpful. Just wanted to say thanks for recommending!
The difference between what mainstream agile is and what the original authors of the agile manifesto were trying to achieve is vast.This talk from one of the authors is an amazing rebuttal of what agile has become and clarification of what it is supposed to be https://m.youtube.com/watch?v=a-BOSpxYJ9M
> What do I have to doTo answer the question:
0. Before starting, accept that some stranger on the internet can only give you a direction or mental framework -- I cannot answer this question. Answering it requires building a relationship with someone you trust to be a sounding board. Talk out the situations and your emotions and your thoughts with them and your brain will likely find a way to make sense of it.
1. First, accept that there will always be things that you do not know. It is thermodynamically impossible to learn enough that you'll be able to understand the every product at-a-glance. There are many product-builders and only one you. The world is deep and fractal in its complexity. Terry Pratchett phrases this well[1].
2. Second, accept that there will always be decisions to be made under conditions of imperfect information. Do not try to make an optimal decision in a complex situation. Neural networks which try too hard to optimize things create disasters[2]. Instead: choose what you care about, strive to think in a way you can be proud of, and then chill. The dice will fall where they fall. . Kenny Rogers phrases this well[3].
3. Third, be mindful that things rarely end with a mission accomplished. Instead, they usually start or change feedback loops that need to be attended-to. So be ready to notice and respond. It may be that Agile is Dead[4], but to notice and respond is the living heart of building products with a spirit of agility.
4.Fourth, build relationships with other engineers and talk with them about the problems they face in their jobs. This will enable you to practice understanding the way people phrase and mis-phrase things. It will also improve the quality of your code as you'll have a mind more well-trained to foresee the frustrations of your fellow engineers.
[1]
> “I told her we were going to get married, and all she could talk about was frogs. She said there's these hills where it's hot and rains all the time, and in the rainforests there are these very tall trees and right in the top branches of the trees there are these like great big flowers called . . . bromeliads, I think, and water gets into the flowers and makes little pools and there's a type of frog that lays eggs in the pools and tadpoles hatch and grow into new frogs and these little frogs live their whole lives in the flowers right at the top of the trees and don't even know about the ground, and once you know the world is full of things like that, your life is never the same.” -- Wings, Terry Pratchett
[2] https://www.youtube.com/watch?v=Ao4jwLwT36M
> if you're not making an active effort to bill as much as humanly possible for the minimum amount of actual work, you are bad at business.Deep Neural Networks who try too hard to maximize or minimize things will take weird misaligned actions. https://www.youtube.com/watch?v=Ao4jwLwT36M
I won't go into details, but my experience from the past year of trying to minimize the chances of losing my home and work visa has provided ample evidence that this also applies to human mental health.
> There is no way to know ahead of time what kind of contractor you are.
Which is why any strategy that resembles "fire and forget" is a poor one for anything that hasn't been repeatedly tested before with mostly the same components.
It's better to have a process where you repeatedly get visibility into a risk than to imagine that you can wall yourself off from it.
Knowing Ben, following this advice would probably lead him to join a Quaker meeting house in his area. While that would probably lead to some interesting discussions about Agile[1][2], I think it would have the same problem.
If you aren't leaning on the English Language at large, then you should ask the community of people who will use your software. Who are your stakeholders?If you don't have a relationship with your stakeholders because your company has paid lots of money to become Agile[1][2], then you are indeed in trouble.
[1] https://www.youtube.com/watch?v=a-BOSpxYJ9M
[2] https://www.fgcquaker.org/resources/form-without-substance
I used to work for a company that used a process mostly like the following:1. Hit 'copy' on a Dropbox Paper template of usually-important questions.
2 Write the name of the project at the top.
3. Collaboratively write whom (we think) it matters to, what systems (we think) it touches, and why (we think) it matters.
4. Go talk to the people in ops/support/api support/sales/legal/etc, whom it mattered to and ask them. Collaboratively edit the Dropbox Paper document with the updated understanding.
5. Think some more about the systems it touched. Read code. Maybe write a 1-day spike. Maybe write psuedocode. Maybe draw diagrams. Ask questions. Update the Dropbox Paper document. Delete irrelevant questions or sections.
6. Come up with a few design options, starting with some crappy ideas. Maybe talk with other teams. Maybe go back and talk with stakeholders. Eavaluate trade-offs. Pick the option[s] that made the most sense. Put the others at the end underneath an <hr>.
7. Meet with the stakeholders again to double-check that everyone's on the same page and they'll have capacity for us to ask Qs when we run into the unexpected. Send out a concise project-kickoff email so people know what we're doing.
8. Break work into trello cards. Sequence them to try to deliver incremental wins along the way.
9. Write tests. Write code. Ask Questions. Write queries. Get stuck. Get clarity. Make changes easy, then make the easy change. Do hallway usability tests. Update the Dropbox Paper document as you learn important things, so it stays an organized source of project truth.
10. Succeed.
11. Have a project retro among engineers and stakeholders to collect learnings, usually scheduled by the PM.
12. Send around project complete email with a link to the Dropbox Paper document, which now becomes a historical reference.
Projects were generally 2-4ish weeks. Longer effort would be broken up into conceptually-coherent phases of that size.
--------
Causes of success:
1. Insist on written clarity -- We put a lot of thought into the Dropbox Paper document because it was actually our means of communicating with each other (and our post-vacation selves) about the results of our a conversations. It is astounding how much faster you can work when you're on the same page and know what you're doing.
2. Start With Why -- We strove to always keep in mind the actual impact we were trying to have
Sometimes we would get to step 4.5ish and realize that the project had insufficient "why". This observation enabled us to deliver (earlier than expected!) the most high-performance snippet of code that any company can deploy:
3. "Take what is useful, discard what is useless, add what is specifically your own." -- either Bruce Lee or a weird guy from Mostar``` ```The template was a useful reminder, but we cut any section that didn't serve to create clarity.
4. Being able to talk to stakeholders, to know what their goals are, and talk through what UX matters to them....sure that probably helps the business... but the real reason it is great is that it is just so damn personally rewarding.
5. Technical Investment -- Our PM wanted us to keep the codebase clean and well-tested so that we'd be able to deliver with more speed and sureness.
6. Do not 'be Agile'. Move _with agility_ -- https://www.youtube.com/watch?v=a-BOSpxYJ9M
(Looking back on that company, their normal development process was full of accidental Reasonable Accommodations for my ADHD)
Here is the talk by Dave Thomas https://en.m.wikipedia.org/wiki/Dave_Thomas_%28programmer%29...
I think most of the people who wrote the agile manifesto said "Agile" been warped into something they don't agree with. Its supposed to empower teams, not enforced from on high to increase pressure on teams.Heres's a good one by Dave Thomas. A quote: "Agile is an adjective not a noun". https://www.youtube.com/watch?v=a-BOSpxYJ9M
I love this talk by Dave Thomas, one of the people whose names are on the original Agile Manifesto.Among other things he speaks about the simplicity of the Manifesto, about the cultish movement and consulting services which rose around it and the cultish, distorted, complex vortex of BS that has formed around a super simple concept.
Reminds me of this goto conference talk from one of the original Agile developers "pragmatic" Dave Thomas.Speaks a lot bout what agile truly is and how scrum is a very large mismatch.
Dave Thomas himself declared Agile dead a few years ago, but offers up what I think is a better definition
1) Do not attempt to live code. change your code via version control, build small videos, copy and paste... whatever you do... do not try and live code2) Read "The presentation secrets of Steve Jobs" ... its not really about Steve Jobs so much as its about how to be a great presenter.
3) building or writing a talk is significantly less important than the delivery... which means that more of your time should be spent on how to deliver the speech (recording I find is the best way to practice)
4) Pick a single thing and do it well, do not attempt to put too much into a talk or tackle something massively complex.
5) Make sure that everyone is walking away with something they can actually use. This doesn't require it be a hard skill... "Soft" or philosophical utilities are just as good
6) Have Fun and be funny... Speakers have a tendency to want to show off the size of their intellect, and the level their competency- having a speech be entertaining is way way more important.
7) DO NOT READ FROM YOUR SLIDES. know your shit. slides are supplementary
Extra Credit. Here's a collection of some fantastic technical speeches:
* https://vimeo.com/9270320 * https://www.destroyallsoftware.com/talks/wat * https://youtu.be/o_TH-Y78tt4 * https://www.youtube.com/watch?v=csyL9EC0S0c * https://youtu.be/a-BOSpxYJ9M * https://youtu.be/kb-m2fasdDY
Dave has an interesting talk about it.https://m.youtube.com/watch?v=a-BOSpxYJ9M
My personal experience is any project where scrum actually works is a boring project, no interesting problem is predictable.
Fortunately I see mostly frustrated scrum masters, not understanding why planning fails :)
I highly recommend this video of a Dave Thomas talk about what agile was supposed to be vs what it has become. Most of us are probably stuck working with some sort of Agile methodology regardless of whether or not we'd like to, but it can still be nudged in the direction that Dave talks about.
⬐ erikbI think the big part of every movement is that initially it's done by people who like to do things, and who want the doing part to be more fun for people like them.But the huge public success comes through people who lead huge businesses or countries, and who are faced with the situation where they have a set of mostly unmotivated, unskilled people who should do something for mostly unmotivated, unskilled customers/citizen. So for them it's not at all about making it more fun for people who love to do it and who have skills, but about making it simple, controllable, and most importantly look successful although they already know BEFORE they start that it won't be successful at all, due to the lack of motivation and skill in their general userbase.
So that "The values have been totally lost behind the implementation" is neither a coincidence, i.e. it doesn't just happen in software dev, nor a surprise, i.e. it was known before it became popular that it couldn't become popular and keep its values.
Sometimes when I watch/listen/read about people explaining this as a surprising and undesired result, I wonder whether they really are so naive, or if they are looking for a way to profit from a younger audience who hasn't experience such a complete popularity loop yet.
Agile is an adjective; The values of the manifesto for agile software development are lost, this is the original idea of The Manifesto: https://youtu.be/a-BOSpxYJ9M?t=406
⬐ FiahilDo you think we could draw a parallel between agile software development and the communist movement ?⬐ quetzthecoatlwhy/how? Agile is based on decentralized decision making and is not very big on hierarchy - the exact opposite of communism. Not everything that has a manifesto is communist related.⬐ gaius⬐ pi-squaredYou should look up the original meaning of “soviet”.wat⬐ gaiusAbsolutely. Both claim to be about empowering the Workers but in fact disenfranchise them.⬐ mjburgessAll roles are equal, but some are more equal than others.
⬐ maxxxxxAgile is a good case study for how good ideas get perverted quickly by consultants and companies. Object orientation also got changed from message passing to elaborate inheritance schemes. People always get confused when I tell that you can do OOP without inheritance besides a few cases.⬐ borplk⬐ curtisIt's perverted by the companies first and secondarily by the consultants as the enablers.Most companies have never cared and do not care for anything agile or anything manifesto.
For them Agile™ is nothing but a brand name and a weapon that legitimises the way they want to exert power over their employees.
They cherry pick elements from the methodology. Change it to their liking and slap the professionally accepted label on it.
That's how the pointy-haired manager turns daily standup to daily micro management meeting and daily beatings with a stick.
Basically no development methodology survives the conflicts of interest at play in the long run.
⬐ greenrd⬐ ythnI don't think that's necessarily a case of conflict of interest, but merely misunderstanding what agile methodologies are really about. They're really quite radical.⬐ borplkThe reason the methodologies get butchered is partially and substantially because different forces try to pull it to their own side for their own benefit.The behaviour is too sophisticated for it to be merely an innocent misunderstanding. On some level it is being knowingly manipulated and weaponised.
It's inevitable because essentially every methodology is a very fuzzy description of a set of ideas and practices so people and groups will interpret it in a way that benefits them.
⬐ greenrdYes, too little attention is paid to the motivations for doing it, and the political obstacles that can be placed in the way - the founders of agile were quite naive about office politics and sociology, in my estimation.How do you write polymorphic code without inheritance?⬐ AdieuToLogic⬐ noarchyYou mentioned being "an embedded C++ shop" in another comment, so I'll frame this in C/C++.One way is to assign function pointers within a struct which is shared across top level functions. This is very common in C, such as in the standard i/o library. It is also very handy in dynamic module initialization in both C and C++, such what Apache httpd supports.
In-process C++ polymorphism of course can be done the same way, but using classes is the idiomatic approach. An interesting and highly useful form of polymorphism in C++ is tag dispatching[0] in templates. This can be complemented with usage of traits to achieve very flexible implementations.
A book I highly recommend which discusses these techniques as well as C++ templates in detail is "C++ Templates The Complete Guide"[1].
0 - http://www.boost.org/community/generic_programming.html#tag_...
⬐ mitchtyYou need to quantify what you mean by polymorphic. Do you mean sub typing, ad-hoc, or parametric polymorphism? The latter requires no inheritance.⬐ dragonwriterWhat is done in a typical OOP language with inheritance you can also do with interfaces (assuming the language has them) with more implementation duplication, and/or with mixins (like Ruby modules) without that kind of duplication (the latter can be seen as a kind of inheritance and may be ruled out by some objections to inheritance.)⬐ falcolasYou use a language that lets you use methods and members of objects without requiring a specific class. Java does this via interfaces, Ruby and Python by not typing the parameters.⬐ ythn⬐ BetadelSometimes "use another language" is not a viable option. We are mainly an embedded c++ shop and switching to Java is not an option.⬐ tomeThen you inherit from a virtual class, which is not actually inheritance in anything but name.⬐ bmm6oThis is often expressed as "interface inheritance" vs "implementation inheritance".In addition to what others have already mentions, you can use tagged unions as an alternative of subtype polymorphism., for example with std::variant.⬐ maxxxxxIs polymorphism really needed for OOP?⬐ kcmastrpcwith interfaces?example: see golang
⬐ frou_dhInterfaces give polymorphism. Implementation inheritance gives method reuse.If you think about the term polymorph ("many shapes"), that describes the world of differing objects that have the opportunity to satisfy an interface.
⬐ ahartmetzThat's a nice way to think about it.One of the things that still slow me down sometimes when designing something in C++ is its somewhat muddled concepts. The overlapping concepts make it harder to divide and conquer the problem to solve.
Rust is quite different regarding interfaces and benefits from many more years of research and experience, so I have reason to assume it does better.
⬐ sanderjdFWIW: Java is a language that is more of a contemporary of C++ but gets this much more right. While earlier Java code I've seen seems more like most C++ in the muddiness of the lines between polymorphism and code re-use, most newer Java code I see these days has very flat inheritance hierarchies (if any at all), and makes far more broad use of interfaces and composition.My point is just that it's not only "modern" languages like Rust that have better support than C++ for this distinction.
⬐ marcosdumayJava is a decade younger than C++.Also, I haven't ever seen deep C++ hierarchies. That seems to be invented for Java.
⬐ sanderjd> Java is a decade younger than C++.I meant "more of a contemporary" as more so than Rust (which my parent comment was talking about). Certainly the design decisions (especially when it comes to object orientation) appear to me to be driven by thinking more contemporaneous with C++ than Rust's do.
⬐ HelloNurseProbably you have only seen good and/or recent C++ code.Deep inheritance hierarchies are easy and cheap in Java (in fact, Java is deliberately designed to be good at them), but their popularity is older and wider; historically the early development of complicated OOP took place mostly in C++, with Java attempting to facilitate further complication with more modern tools.
For a well-known (and not too unreasonable) example of C++ deep class hierarchy, see the streams in the standard library of 20 years ago. The Java standard library copies them as closely as possible.
⬐ marcosdumayIn retrospect, it's indeed very likely that I have only seen good C++ hierarchies.>Agile is a good case study for how good ideas get perverted quickly by consultants and companies.The points made in the Agile Manifesto having me nodding my head in agreement more often than not. But the implementations, like Scrum, are another matter entirely. It has become a management methodology, further and further removed from the developers. And that comes complete with all of the trappings you'd expect: process for the sake of process, empty metrics (like "velocity") that can be passed up the management chain, and so on.
⬐ tootieScrum is perfectly fine. In fact, it's a great way to achieve agility. But it only works if everyone understands both the process and the goals. For all the "scrum sucks" posts I've seen, I've yet to see anyone offer anything better.⬐ sanderjd⬐ hashkbWhat is better is coming up with a process that is right for your team, based on evaluating what has worked and what hasn't worked.For the teams I've been on, daily stand-ups have been a drag, and it has been a major improvement to eliminate them. Similarly, 100% pair programming has been unpleasant for the majority of the team, and it has been an improvement to stop feeling guilty about doing a lot of solitary programming. The criticism that scrum tries to get you to run a marathon as a series of sprints also resonates with me. It never seemed to allow time for more complex and vaguely defined projects to flourish, but rather we would look back and see an accumulation of short-term thoughts, but little cohesive whole.
What has worked for me: code reviews code reviews code reviews, copious automated testing, a prioritized backlog, estimating size of work in some sort of abstract unit, burn downs, demos and retrospectives, short meetings with defined agendas, ignoring anything that makes up terminology, especially if any use of that made-up terminology includes a (TM) superscript.
⬐ UK-Al05Simple kanban and communication.Religiously following the 'process' is the opposite of agile.
Being able to use your judgement to decide to do something is agile. In scrum you always do the same thing regardless if it's needed. Well in the implementations I've been in.
Can you say more about how velocity is an empty metric? I'm an IC, sometimes tech lead, (e.g. not management) and j have always found it indispensable.⬐ maxxxxx⬐ OnlyRepliesToBSOnce some managers get hold of velocity numbers they use them as the main metric. "How can increase the number of story points per sprint?" or "Why does dev A finish more story points than dev B?". Then you get all kinds of perverse incentives to game the system.Or: They start comparing story points between teams which in reality is a totally meaningless thing.
⬐ another-daveVelocity is too often used as a stick to beat people with — "Team B is doing 15 more points that you"; "Last month, we were doing an extra 5 points every sprint, but now we've stagnated — what happened?"The only worthwhile external measure of value is features that the team deliver (i.e. broadly counting improvements to non-functional requirements as features too). Velocity is meant to be constant (in an ideal world) to allow the Product Owner (i.e. someone _inside_ the team) a broad brush to provide estimates on when things may be ready — even used in this way, they depend on a stable team with a velocity that's not too volatile. They shouldn't be shared externally to try and show how productive the team are.
For example, I've previously had management ask if our team can try a bit harder & deliver another 30 points per sprint. As points are meaningless outside of the team though, that's a false economy: I think they got the picture when I said our team could deliver another 1,000 points per sprint if they wanted us to.
⬐ srtjstjsjBad management can fail using any methodology. No process will make bad people do good things -- at best it can stop them bad things. The goal for a productivity process is to help good people to great things.⬐ another-daveSure, but the parent was asking for an example of how it could become an empty metric — from my experience, this can happen when it goes outside the control of the team and "Goodhart's law" comes into play — When a measure becomes a target, it ceases to be a good measure.I'm not against meausring velocity, but I think it is a tool best used from within the team rather than from a management level
> Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
It's a religion and all negative implements are always at the fault of the implementer.That is called unfalsifiability.
⬐ ryandrakeIs there an example of a company that has implemented the philosophy in the Agile Manifesto in a way that actually meets the needs of developers and managers?I read this all the time: The agile folks were right about software development, but Scrum/consultants/managers/process sucks! Everyone likes the Agile philosophy but then they all say it's never been implemented right. Reminds me of the "communism is the way--it's just that every time it's implemented it's done wrong!" argument.
My criticisms of Agile are: 1. It doesn't scale to team sizes beyond the point where "individuals and interactions" can drive progress; and 2. it addresses developer needs but does not sufficiently address the requirements of the rest of the organization, including management. Developers gotta develop, but the rest of the business needs things like measurements, reports, status, ETA, sometimes proposals, change requests, etc. A methodology that does not address these artifacts is going to have a hard time fitting in.
⬐ oceanghostThe problem with agile is it is naive. It assumes everyone is acting in good faith and thus it can easily be turned against developers. What I've seen consistently is managers are willing to turn responsibility over to developers but not control, and yet that's the core tenant of agile, developers are in control. I have never seen a company that practiced agile that did not have deadlines."Sprints" alone are toxic. To sprint is to exhaust all of one's resources, and rest. When was the last time you were allowed to rest as a developer? Most companies just say, "Sprints start every other Monday".
"Respond to changing markets" becomes "managers don't have to plan."
"Developers are in control" becomes "all jobs now belong to developers."
And finally, the most toxic element of all is the misapplication of agile. Agile works for websites and mobile, THAT'S IT.
You cannot plan infrastructure in 2-week increments (yes I've seen this attempted).
⬐ kpil⬐ jacques_chesterFirst, I think there is no other reasonable way to run a company than to assume that everyone is acting in good faith. Most people are. Weed out those that consistently are not. Trust but verify.The other remarks are all good responses to "cargo cult" Scrum.
No, it's not about death-marching the teams, it's about keeping a sustainable and realistic pace by time boxing activities, and constantly assess the velocity. The end goal is to increase predictability and reduce the number of concurrent activities in all stages of the "delivery pipe". Limiting the Work In Progress is a "Lean" thing.
Managers should have a goal and identified the needs, but premature detailed planning should be avoided. (Also a "Lean" thing)
"All jobs now belong to developers" is clearly not ideal but probably a reaction to a high ratio of non-developers which is typically not a good thing if the main product or services are software or produced by software.
I'll give you that dividing complex deliveries with many dependencies can be very hard - you probably can't plan or replace infrastructure in 3-week increments, but measuring and possibly delivering some sort of value in 3-week time-boxes is most likely doable, although realistically you'd probably go live in larger chunks. You still need a plan and most important a goal though.
One reason to be a bit fundamentalist here is to challenge the structures within a product or a company - maybe the bottlenecks just get more visible? Is it possible to divide complex behemoths into smaller parts, for instance? Maybe centralized solutions drives down fixed costs while increasing dynamic costs - those are typically much harder to understand.
⬐ oceanghost⬐ jacques_chesterWherever you work, are they hiring? :-)> Agile works for websites and mobile, THAT'S IT.From your experience.
This is a kind of No True Scotsman. If agile is working on massive multi-team, multi-site, multi-timezone, multi-company projects, then apparently it ain't agile.
My experience is different. I've seen it work and not work. Right now I'm seeing it work. It works well; the core of which is asking what's sucking and how we can fix it.
⬐ oceanghost⬐ NomentatusNo, not just from my experience. Logically.The biggest risk in engineering is always the "dealbreaker." Some fundamental philosophical incongruity in the project. Usually, they take the form of a broken invariant.
When I was an architect, it was my job to front run my team, management and plan for every conceivable scenario such that I would never have to utter the phrase, "That is not possible."
You cannot plan a multi-year project in 2-week increments if I spoke metaphorically about websites / mobile apps-- what I meant was, you cannot design anything that really matters in weekly increments.
Imagine trying to design the space shuttle two weeks at a time.
⬐ jacques_chester⬐ maxxxxxAgain, you're creating a No True Scotsman.Cloud Foundry is a multi-million SLOC distributed system developed by dozens of teams over many years, one week at a time. Yet it has an architecture that evolves on a multi-year scale.
Nothing in agile precludes architecture. What's precluded is ignoring change.
I don't know what else to tell you. A counterexample to your universal claim exists. So it's not universal.
⬐ oceanghost...pivotal... :)⬐ NoneNone"the core of which is asking what's sucking and how we can fix it."This seems to be a taboo for a lot of managers. They'll do almost anything to avoid listening to their own people and fixing the problems they mention. Only outside consultants or management further up can be listened to but not the people they manage.
⬐ jacques_chesterI think you're right."Sprint" is such a wonderful example of how Agile can (and has often) been perverted (and in this case, inverted.)What is a sprint in RL? It's a race in which you only go a very short distance. As in: "Wanna run a few miles?", "Nah, let's just do a sprint and leave it at that."
But stick-management willfully misinterprets Sprint as a very fast speed implying you should get an immense amount done in a short time by magical means.
Which has led to the Agile guys backing off from the word, officially, I do believe. You won't find it in the Alliance Glossary, just "iteration": https://www.agilealliance.org/agile101/agile-glossary/
If overtime by software engineers were not exempted by law in many jurisdictions from being paid, I don't think this willful misinterpretation would happen so often.
⬐ oceanghostThank you for your thoughtful reply.> Is there an example of a company that has implemented the philosophy in the Agile Manifesto in a way that actually meets the needs of developers and managers?I work for Pivotal, so I'm going with "yes".
> It doesn't scale to team sizes beyond the point where "individuals and interactions" can drive progress
It says "over processes and tools", not "strictly instead of". If anything, good tooling lifts a lot of overhead out of the way so you can go back to individuals and interactions.
Of course, scaling this stuff is hard hard hard. But that doesn't make agile irrelevant, it just means you need to keep thinking and rethinking what you're doing.
> it addresses developer needs but does not sufficiently address the requirements of the rest of the organization, including management. Developers gotta develop, but the rest of the business needs things like measurements, reports, status, ETA, sometimes proposals, change requests, etc.
Evolved XP+Lean is pretty much where Pivotal starts from. Engineers asking product and design questions is taken as status quo.
Sure, it's hard, but it's not about "agile can't scale". We've scaled it and doing so is painful and difficult. But any organisation passing the Dunbar limit is hard to keep on track. The classic methods work, we're surrounded by their fruits. But we're also surrounded by their waste. It's always worth questioning yourself and why you do a thing.
⬐ dragonwriter> Is there an example of a company that has implemented the philosophy in the Agile Manifesto in a way that actually meets the needs of developers and managers?As far as I can tell the best implementations lean heavily on the Lean rather than Agile tradition; Lean has very similar values, but much better early operationalization of those into high-level practices which helps resist cargo culting low-level processes.
⬐ chris11> Is there an example of a company that has implemented the philosophy in the Agile Manifesto in a way that actually meets the needs of developers and managers?I'd guess most companies that call themselves Agile or decide to try Agile won't do that, but great companies can implement the Agile Manifesto in ways that make both developers and managers happy. It seems like a lot of agile consultants sell Agile by trying to convince management of it's benefits. That top-down approach conflicts with the Agile Manifesto's bottom up approach.
I'd think developers would generally be happier with Agile implementations that were led by developers, not management. I'm not quite sure how that would meet specific business needs, but I think that a lot of developer complaints come from management decisions. I agree that a lot of problems can occur when trying to let "individuals and interactions" drive progress. Of course, a lot of these thoughts are because I've worked at places with really corporate versions of agile, like SAFe.
⬐ marcosdumay> It doesn't scale to team sizes beyond the point where "individuals and interactions" can drive progress;Is there any methodology that scales that way beyond the fuzzy and personal "get somebody competent divide the work into small independent chunks"?
Any methodology that treats developers as replaceable gears will have the same failure cases. It's not Agile that is the problem.
⬐ kpil⬐ maxxxxxSpot on.If the captain and the navigators are incompetent, and the shipping company send you to the wrong port, then no crew can save the company.
The places were "Agile" goes bad, are the places where just about every management process goes bad. If too many don't know how how the sausage is made you get "list guys" running around with lists and metrics that don't make sense, reporting to committees filled with other "list guys", an ever increasing admin-per-developer ratio, and a productivity that slowly falls down to zero.
Faking process and order is much, much easier than actually managing the semi-chaos that a large development process is.
" Is there an example of a company that has implemented the philosophy in the Agile Manifesto in a way that actually meets the needs of developers and managers?"I have worked at two startups and there I think we implemented the Agile Manifesto. We talked to each other and got things done. There were no pure management types whose only job it is to report further up the chain. But these were teams with a max of 20 people so I am not sure how well this will scale up.
⬐ zdragnarThe agile manifesto was never intended to be a value proposition for the business per se, it was intended to be a promise of professional discipline.You don't ask the business if a refactor is okay, because the business doesn't know how to value or risk it. You refactor because that's what a disciplined professional does, in the course of their work.
Think of another profession, if that helps. Teachers don't ask students or administrators if a test would be valuable after a given lesson. Builders don't ask if a hammer would be appropriate for a nail, or if they should use an air gun. There's a certain expectation that they should know and do these things.
Scrum works if the scrum master functions as a mediator for the team to collaboratively prioritize work- ideally, this would be a role, not a job title. Scrum fails if the scrum master is just a project manager tasked with making sure the whole backlog entered by the product owner is done on time.
⬐ sanderjdI think I agree with you, but I find your analogies quite lacking, which makes me question our shared premise. Teachers absolutely do have the cadence of tests after lessons dictated to them by administrators. Builders absolutely do negotiate with their customers over whether their "implementation" is sufficient or whether it should be "refactored" (ie. partially or completely torn out and re-done to improve the quality).I'm not sure where this leaves things, but it seems to me that the differing incentives and negotiation between stakeholders is perhaps inevitable.
⬐ zdragnarI realized as I wrote it that the analogies were flawed, but I rushed myself a bit to finish writing.The teacher analogy depends entirely on the school district, and perhaps might apply more to a university setting than a grade school one.
As for the builder, of course there's a discussion between the builder and the client... On the desired results. What a disciplined builder won't do is ask "can we" when they know that the current status is structurally unsound or flawed. There's some substantial differences in cost / financing and risk between the professions, so it's a bit of a stretch no matter what, I'll grant you that.
If we can at least agree that there is a certain amount of discipline that embodies a profession, and that the agile manifesto emphasises priorities characteristic of that discipline (correctly or incorrectly) rather than a "business process" or "project management" scheme, then I think we're agreeing on the important points.
In the software development field (and I'm sure other fields as well), we have this notion of "ownership" that means something more specific than lay people would expect. If someone "owns" a subsystem, they are not just responsible for it, they also have the authority to modify it, and they understand it well enough that they can modify it. Most often (at least in startups) the owner of a subsystem either implemented it or implemented substantial portions of it.OK, this is on topic, I swear. This notion of ownership can apply not just just to individual contributors but scales up to teams and even larger organizations. A team can own an entire major system for example.
Software organizations of any size at all need a process in order to ship usable software. Well-run software organizations don't just have a process, they own that process as in the sense above. The organization has the responsibility for the process, they have the authority to change it, and they understand it well enough that they can. Obviously such an organization can respond to deficiencies in the process and adjust it to work better. They can even revamp it completely if they need to.
Your Agile software development process isn't going to work well if you organization doesn't fully own it.
⬐ greenrd⬐ baneSometimes code ownership means something slightly stronger, i.e. that no-one else has the authority to change the code. It's fine for a team to own code in this sense, but it's really bad news if an individual owns code. This is one of the things that Scrum tries to prevent, by not pre-assigning tickets/cards.⬐ curtisThere is an alternative problem where there is no strong ownership in place, but code that should be changed doesn't get fixed or updated because nobody owns it.To get back to the point that I was trying to emphasize, a big problem with software development organizations is that often they do not own their software development process, making it essentially out of anybody's control.
I guess in a scenario like that upper-level management (e.g. the CEO) could try to take ownership of the process, but that's unlikely to ever work out well.
⬐ wolcoBut having one person own a certain forces resposibility and when the team grows you have two people own that piece or 10 as budget permits.⬐ closeparenThis kind of dilution of respnsibility essentially guarantees mediocrity and low satisfaction. It’s bad news if an individual doesn’t own code and/or large projects over that code. Treating engineers as interchangeable cogs who can be reallocated between bite-sized tasks on a whim misunderstands the nature of software development and is employee-hostile in a way that you’re unlikely to get away with in this labor market.Whenever we hire a new Agile practitioner, as part of the interview I ask them to discuss the Agile Manifesto [1]. And then we run through some basic program design and I ask them what tools they bring to help support various program needs. They usually bring out various ceremonies and processes and what not.I then ask them to justify what they've offered against the Manifesto. If they're thoughtful about it (the Manifesto isn't always correct, and if you read it carefully leaves open the need for some of this stuff). If they simply insist it's correct they're cargo culting and we can move on.
What I've found is that the ceremonies are appropriately named in that many of the practitioners seem to not know what they're for or why they're done. The teams that seem to really excel are the ones that seem to have thoughtful managers that shape the practices of their dev group to the specifics of their work. The ones that seem to always be bogged down and require huge numbers of staff to get even small amounts of work done seem to be the ones that follow a checklist of getting as many of the agile practice "things" jammed into their work processes as possible.
I don't think Agile is dead, but I think it requires smarter team leads who look at what's come out of it as a set of tools to be employed against specific development challenges rather than a religion that needs worshiping.
⬐ auxbussThe issue I’ve always had with Agile – with a capital A – is that the manifesto itself is not agile; it’s been cast in stone – or, at least, embedded in a static web page. (That’s why I’ve never “signed” the manifesto.)I’ve been in this game for enough decades to know that you have to reinvent yourself every five years or so. Some things remain the same over time, of course, but a great deal changes. These changes must at some point affect the assertions laid down in the Agile Manifesto. Where is the mechanism for change?
I must at this point point out that I consider myself agile. I absolutely have skin in the game.
Now, to the language of managers.
I work at CTO/Head of Tech level. That involves a bunch of strategic, operational, and financial stuff that doesn’t pertain to tech matters (tangentially sometimes), but my role at the tech level I regard as supportive not <air quotes> managerial. I usually describe my role as “looking after” not managing – I actively remove the terms manager and management from that part of my role. I expect – nay demand – that the teams responsible for delivery drive development/maintenance. My role is to provide them with what they need – to support, to look after, and so on – individuals and interactions. For me, that’s agile.
That’s a dynamic process that’s enabled by tooling and that tooling changes rapidly. No set of pronouncements or practices can remain relevant in such a dynamic environment; unquestioningly following a static text is dangerously close to religious practice – I don’t regard this as a good thing, ymmv.
So, while I believe that the Agile Manifesto is an excellent baseline, it is flawed and somewhat contradictory in operation. But, like democracy, it’s the best we’ve got.
⬐ arbieYour comment makes me think your workflow has become dogma. Does expecting new hires to hew so closely to existing principles give your team room to evolve?⬐ borplkI've noticed the same thing.I think it comes from a lack of experience which further creates fear and lack of self-confidence to challenge the practices of the cult.
It's also similar to the "nobody got fired for buying IBM" issue.
It's "nobody got fired for sticking to the established cult ceremonies".
They are people who are afraid and don't care about the team or the company. They are only concerned about their own job security and paycheck. So they never risk trying something that is not in the book.
The only way to get them to do something else is to make that thing the "new best practice".
Give it a tacky name. Send them to some conferences and get them a "Senior Lingo Bingo Dingo master practitioner" certificate for the new cult ceremony and they will do it with their eyes closed.
Or maybe ... just fire them.
I think Dave Thomas[0] made some great points recently [1] about what Agile (as a noun) has become and I think it addresses some of your complaints. Note this isn't just a repeat of the agile manifesto, it is him discussing why he hates what Agile has come to mean to a lot of people and it sounds like his grump-level closely matches yours.The jist I get from it is that agile has become an Enantiodromia[2] and has in some ways simply replaced the problems it was there to fix. That doesn't mean it has to be that way, but thats what happens when people take something and create a religion around it.
In my company we call our process "agile", but what that really means to us is to do the minimum amount of analysis we can to develop the features that the customer actually wants, and when they realize what they thought that they wanted was not really what they wanted, we can change it without wasting massive amounts of time. If we find that our process is causing problems for the devs, we tweak it. When we find we're not doing enough analysis in some situations, we try to improve those situations. No buzz words really, just what is best for us and what is best for the customers.
[0] https://en.wikipedia.org/wiki/Dave_Thomas_(programmer)
Usually, the more a team advertise itself as Agile, the less agility it actually has.I myself have never seen Agile work well, not even close. I saw plenty of make-believe and head-in-the-sand and as mentioned in earlier comments, insane amounts of cargo culting.
I really like the way Dave Thomas put it: https://pragdave.me/blog/2014/03/04/time-to-kill-agile/
He also made a talk about it: https://www.youtube.com/watch?v=a-BOSpxYJ9M
These days this is the only methodology I follow and it works wonders, anything more I feel is just noise. At the end of the day nothing replaces actual engineering and understanding what you're doing.
⬐ flukus> Usually, the more a team advertise itself as Agile, the less agility it actually has.Bingo. Usually when you ask them what agile processes they are following they just mumble something about daily stand ups (which I'd argue are not agile at all).
I've seen agile work. But it's more about automating builds, having continuous (or near continuous) deployments, having database migrations to easily integrate others changes, etc.
My evaluation of how agile a company consists of "When a trivial bug is reported, how long until the fix is in production?". If the answer is greater than a day then they aren't agile.
⬐ jeremiep⬐ at-fates-handsI feel like "agile processes" is an oxymoron. Real, actual agility requires a lot of thinking; something usually prevented by having processes in the first place.A better question to ask an "Agile" team would be: "what problems are you trying to solve?" - most of the time they haven't taken the time to properly analyze the problem in the first place, even when the project is near completion. They just run with dumb user-stories and start piling up Jira tasks with no clear vision.
At this point I don't believe Agile can work whatsoever. A success rate of one in a thousand projects, which usually happens to be a dead-simple CRUD app anyways, means absolutely nothing, other than it has failed in a spectacular way. If software development was an actual science instead of a pop culture, the scientific method would've thrown Agile out the window decades ago.
Your last two sentences almost exclusively applies to web services, which is a tiny fraction of what software engineering can do.
For me real agility is how much effort you're willing to spend upfront to properly analyze problems before attacking them, how quickly do you adapt your solution when new facts become known.
Its dead-easy to have agility at the beginning of a project, what matters is still having it 2 years down the road and more. Continuous deployments, database migrations, automated builds and whatnot do absolutely nothing to help you reason about the simplicity of your codebase - which is what yields true agility.
⬐ wpietri> Continuous deployments, database migrations, automated builds and whatnot do absolutely nothing to help you reason about the simplicity of your codebaseI pretty strongly disagree with this. Simplicity in agile projects is achieve through continuous improvement of the code. All of those things make refactoring cheaper and easier, which means you can keep your code base in good shape as domain and business needs change.
Without those supporting practices, people get scared to change anything. And once they get scared, bit rot sets in.
⬐ jeremiep⬐ flukus> Simplicity in agile projects is achieve through continuous improvement of the code.This is also called "emergent architecture" and its a big lie. You'll at best reach a fraction of the quality you'd have by thinking about said architecture upfront with twice the development time - it works for CRUD projects simply because such projects are dead-simple to begin with.
How are these practices helping us reason about the simplicity of the codebase? How are the people dependent on your code going to handle all of your frequent refactors? What does continuous deployment even mean outside of the web? How do you refactor something as big as a game engine with 10+ projects built on top of it?
More importantly, how are you going to add proper abstractions to an existing project? No refactoring tool will ever do that, it cant be automated and the more advanced a project becomes the harder they become to introduce in the codebase. I've seen plenty of "best practices" projects that were just huge hairy balls of indirections. Yet everyone on the team felt good about it because none knew any better.
You can't judge practices based on how they work for one particular area of software development. Especially when said area is one of the simplest out there.
⬐ wpietri> You can't judge practices based on how they work for one particular area of software development. Especially when said area is one of the simplest out there.You know exactly nothing about what I've based my opinion on. Because all you've done is jump in and rant about your beliefs.
> thinking about said architecture upfront with twice the development time
Design quality is limited by the information you have, and no amount of thinking creates information. The beginning of the project is when you have the least information about everything: domain, users, user needs, business needs, technology, team. Everything.
You mostly get information by trying things in the world. And actually trying things in the world is the only real test of ideas that come from thinking.
If your methodology requires understanding everything up front, then it's basically useless in the real world. Even if you could perfectly understand your intended market and use case, that will change over time. But you can't, because your competitors are always plotting to beat you, and they will not share their plans with you.
Amazon, for example, has been in operation 20 years, and could easily be going for decades more. If in the early days they had tried to write code capable of dealing with their current needs, let alone their needs from 2050, they would have been idiots. Pure up-front design is an unworkable fantasy.
> More importantly, how are you going to add proper abstractions to an existing project? No refactoring tool will ever do that [...]
Refactoring existed before automated tools, and mostly exists beyond it. Tools help, but it's mostly a human activity. Try reading Fowler's book on this, and his subsequent writing. You can't effectively criticize something you don't even understand.
The last two sentences don't only apply to web based projects, they can apply to any application development from web to desktop to mobile. I think that would cover the vast majority of software developers.> Continuous deployments, database migrations, automated builds and whatnot do absolutely nothing to help you reason about the simplicity of your codebase - which is what yields true agility.
The help in the sense that you can make and deploy changes seamlessly. For understanding code the unit tests that go along with them also help tremendously, if they are well written unit tests anyway.
⬐ jeremiepOh yeah, but you could be spending 10 times the required amount of efforts because of accidental complexity and none of these tool will point that out for you. I've seen it happen way too often to trust a team relying heavily on processes and tools anymore.Besides, you set them up once and then forget about them, happy with your day to day use. But actually fighting complexity and making sure you're still solving the problem at hand and not bloating things up requires near constant critical thinking, something no tools or processes will ever be a replacement for.
That's what I meant :)
>> I myself have never seen Agile work well, not even close.My main gripe is most organizations I've worked in were usually in the transition between waterfall and some form of agile. The #1 issue was the people who sold the corporate execs on agile being faster and more efficient than waterfall have set unrealistic expectations as to deadlines and release dates.
Suddenly taking 12 months to build that app you were thinking of developing via waterfall, just got cut in half because everybody thought agile is so much faster, when in reality, it really isn't that much faster at all - just a different methodology, which a lot of people forget.
I have yet to work at a place that has released anything any faster than how it could be done using traditional waterfall methodology.
My last point about agile is that I've found it doesn't scale well. When I used agile in smaller teams (10-15 people, 3-5 devs) it was very effective. As you scale up (50+ people, 15+ devs) things slow down, inefficiencies are created because instead of several devs working on larger chunks, you have several dozen devs working on really small parts that get coded completely differently, then sometimes don't work together and it causes multiple iterations of design that wouldn't happen in waterfall. There is an advantage with us devs seeing the larger picture and coding to that, instead of this little component that gets coded 10 different ways.
⬐ wpietriYeah, I definitely agree that a popular reason for adoption was "go faster", which was poisonous to the actual attempt.Honestly, I think you eventually can get substantial speed gains. But you mostly get them by cutting out waste. Doing that takes a fair bit of time and work. And not just work, but commitment to personal and cultural change. People don't do that under strong time pressure; instead they are inclined to revert to previous behavior.
⬐ UK-ALI find if you define the way things must integrate(REST) with defined versioned interfaces. Then you can have small teams working on different services, without that much overhead.⬐ jeremiep⬐ BurningFrogThere are way, way, way more uses of programming than simple CRUD services. Operating systems, game engines and browsers are only 3 examples where that doesn't apply, at all :)Besides, what's to say there wont be overlap in these newly separated services that will generate work in double because teams dont talk to each other? Or maybe you'll generate two average solutions instead of a better unified one.
Even with multiple teams working on different aspects of a project, you still need yet another team to maintain the global vision of the thing. To make sure everything is consistent, to avoid work duplication, to consolidate solutions and abstractions and whatnot.
Its fair to say the larger a development team is, the harder it will be to manage. Its even more true with large teams of average developers, which really is the norm when you think of it.
At the end of the day, communication is key.
I think all methodologies slow down when the teams get larger.In the XP teams I've been on, everybody rotates between stories and swap pairs daily, just to avoid the individual code ownership and fragmented coding styles you mention. Works really well.
> unrealistic expectations as to deadlines and release dates.
Also, one of the core agile ideas in my world is that there are no deadlines or release dates for specific features.
⬐ wpietri> Also, one of the core agile ideas in my world is that there are no deadlines or release dates for specific features.100% agreed. This is one of those things that so many companies can't even conceive of. But once you get people converted, it works so much better.
⬐ jeremiepThats usually not possible. We're not doing pure science, we're doing engineering - which happens to mix science AND economics.This means the "no deadlines" wet dream is usually a recipe for "oh shit, we ran out of money" for most projects. Also programmers are usually big babies; give them unlimited time and they'll give you unlimited bloat. Other than doing R&D it usually is impossible to have no deadlines.
Most people are not doing R&D, but when you really do your government usually has programs to finance it. That's precisely how you can afford to not have deadlines because your company is paid to advance the state of the art. And even then you usually get paid after the project is over and after you've filled a bunch of forms to clearly state the problem, your solution as well as existing work in the area and why it did not apply to your case.
Or if you're doing servicing work you get paid by shipping at predetermined milestones. Building software is a LOT more complex than just writing down the code and too many developers are clueless when it comes to politics, economics or management.
I used to think the same when I was still new to the software industry. It took me years to understand theres a whole world around programming required for programming to happen in the first place.
⬐ wpietriThanks, but I understand the economics of software reasonably well.Note that we are discussing "no deadlines or release dates for specific features", not just a magical world without consequences.
If you are looking for how this works, Poppendieck's books on Lean Software Development go into both the theory and practice. But the basic notion is that you control costs via scope control, waste reduction, minimizing WIP, and continuous improvement. One still delivers things quickly and efficiently; it's just that deadlines are not used as a control mechanism.
Once you're through Poppendieck's work, I recommend "Priniciples of Product Development Flow": https://www.amazon.com/dp/B007TKU0O0/
⬐ BurningFrogPeople can use "we have no deadlines" as an excuse to never do anything useful.This is why one part of the Agile Manifesto that isn't talked about as much as it maybe should be is about how you need to build trust with your customer by constantly delivering value. Demanding that trust from strangers is hard sell, and it probably should be.
The big problem with deadlines is that it's impossible to predict how long something will take, so you end up in a game of lies and bluffs to create and take away buffers to account for the uncertainty, which leads to horrible relations between the dev team and it's customers. Also, it falls apart, when priorities change.
⬐ jeremiepThis only applies to servicing contracts, when you're the customer constant delivery is very well overrated. Even with servicing contracts shipping every week or two is a definite recipe for mediocrity. You're wasting all that upfront analysis for the sake of early delivery and then suffer from all the bad technical decisions made to build it in a rush. Expect insane amounts of overtime to reach the last milestone on time for such projects.Deadlines are not that hard when you properly plan to reach them and give yourself a large buffer of time for debugging and QA. You just need to properly analyse the requirements, the existing solutions in your problem's domain, what is known and unknown (keeping meta-ignorance in mind - you dont know what you dont know) and then re-analysing it all every time the requirements change, even slightly.
This means you're going to spend a lot of time upfront before coding starts, and the first deliverable will be months away. Solid foundations yield by far the most agility to any project I've ever seen, and continuous delivery prevents these foundations from being built in the first place. You definitely won't see any proper abstractions at such a pace, what you're most likely to see is an endless sea of indirections.
Same for testing, I've seen many teams starting to write tests for requirements that weren't well understood yet. Then they start piling code up until the tests passes, and finally wonder why there's tons of new bugs in Jira every week. All the tests passed! The type checker passed! But now there's no time left for debugging and the project gets over time and over budget.
The smoothest servicing projects I've ever done were with customers understanding the nature of our work and not minding a long time window before the first delivery, not interfering with the work. The worst servicing projects were having two weeks sprints where the managers would bend over to every single customer demand for fear of losing the contract at the cost of burning out the team and having no quality whatsoever in the finished product.
You get trust with new customers based on your own track record of successfully shipped projects, not continuous delivery over arbitrary milestones. And then you can manage the customer, instead of being managed by them. They pay you because they can't do the work in the first place after all.
Interesting. I was actually JUST watching this on Youtube, which says somewhat the same thing: https://www.youtube.com/watch?v=a-BOSpxYJ9M&t
Agile Is Dead: By Dave Thomas https://www.youtube.com/watch?v=a-BOSpxYJ9MI love his talks for a few reasons:
Often times...
1. He's anti-hype 2. He's contriversal 3. He's right.
by Dave Thomas (PragDave)"LoneStarRuby 2015 - My Dog Taught Me to Code by Dave Thomas" - https://www.youtube.com/watch?v=yCBUsd52a3s
and
"GOTO 2015 • Agile is Dead • Pragmatic Dave Thomas" - https://www.youtube.com/watch?v=a-BOSpxYJ9M
Listen to one of the authors of the manifesto itself: https://www.youtube.com/watch?v=a-BOSpxYJ9M(BTW, he is very opposed to the use of Agile as a noun ;).
This appears to be an uncredited summary of Dave Thomas's talk, "Agile is Dead"
⬐ askyourmotherAgile may be dead, but the books flogging it remain on Dave's website (the so-called pragmatic programmer).⬐ dghfFrom the article:> This post merely a reminder of the actual values mentioned in the Manifesto. I was inspired by this great talk: Agile is Dead (Long Live Agility) — Dave Thomas
The talk's title is hyperlinked to the same URL you give.
No, the grievances against Agile are just too voluminous and wide-spread, consider even Dave Thomas's presentation about how Agile is dead due to the ease with which it is subverted for political manipulation [0].If someone as key to software productivity as Dave Thomas is saying this, it's clearly not just because of a vocal minority.
Your suggestion that we should check whether it's just a vocal minority is a good one. We should check that.
Unfortunately, it's extremely obvious that it's not the case, and the dysfunction / failure mode of Agile is extremely common, by far the majority of Agile implementations.
⬐ jeremiepI've seen that talk last year, great talk! I really like how he makes the distinction between Agile and agility and compares the values of the manifesto with the consultancy industry which spawned around it.But I have yet to find a manager deeply believing into Agile who'll questions those beliefs after watching the video. I feel the problem with Agile is that a lot of the people who enforce it are either not programmers or terrible, terrible ones.
I have also yet to find an Agile project with actual agility, but that's just my own personal experience :)
⬐ spydumAs with anything, I think folks are trying to sell you tools for the "how" part. The trouble is always in the implementation. His point is very valid about poor architecture is hard to change... And I think over investment in tools/process for agile is precisely that.. When you spend more time and money filling out JIRA tickets and staring at Kanban boards and attended SCRUM of SCRUMs and hours long standups, you need to reevaluate if your process is doing more harm than good.⬐ jamisteven⬐ nathanaldensrSo true. Im not a developer but work in production, so much paperwork bogging down productivity.⬐ EvanPlaiceThe question that should be asked in that case is what purpose does excessive paperwork cover?In my experience, it's usually poor management looking to cover their own ass when deadlines are missed and/or establishing a track record so if they need to fire people they have a legally justifiable reason.
Agile principles, in an academic sense, are great. However, for agile to work best, it's my belief that the team needs to be of a similar skill level, trust each other implicitly, and have the same value system (i.e., "we believe in writing software for the long-term", "we believe in being disciplined", etc.) Too often this is not the case. Many things are good in theory but once applied to real human systems, fail.⬐ squeaky-clean⬐ riprowanI tried out Scrum at my company on a small team that matches these conditions, and it was incredible. I think the biggest points are the same value system, we all had the same standards for quality, and we were excited to try a new way of managing ourselves that we were open to adapting and being flexible about. And the trust to allow that to happen, and criticize the process without feeling like we were criticizing each other.The Sprint Review sections were most beneficial, because we were all quick to say what we felt needed changing, and everyone was excited to try. If we did something radical, we could call a 1-week sprint instead, or plan the sprint that we could easily adjust it and start a new one if that method didn't work, just in case the new method ended up sucking.
The first month of it was weird, and eventually a few months in we were an extremely well-oiled machine running a system that was nothing like the original Scrum plan we followed, because we learned which parts worked best for us, and which didn't, and experimented with adding a few methods of our own to the system.
The rest of the company moved onto Agile/Scrum after seeing our small team, but I don't think the majority of them are handling it well at all. The process isn't adaptable, if devs speak up about things they don't like, the managers tell them to "trust the process" and give it time (BUT THE PROCESS IS ALL ABOUT CHANGING THE PROCESS AND NOT BLINDLY TRUSTING THE ORIGINAL PROCESS!!!), and many of them would rather not work in a management system that should adapt like that. I'll get asked for advice on why their daily standups aren't working, give feedback, "Well that would involve changing things, and we'd rather not do that..."
Really, they're just doing waterfall but with daily standups and a bi-weekly planning session which is mostly meaningless. Whatever, at least the team I'm on now is willing to play it the dynamic way (myself and another member of that original scrum team are in it), and we're enjoying it very much.
⬐ natec425I disagree with one of your three conditions; I don't think all team members need to be of similar skill. Particularly, I think agile practices can be very good for knowledge sharing between senior and junior developers.As for trust and values, I might combine the two and say that members have to trust in each others values. For example, I don't want to bother to get my code reviewed by someone who doesn't care about its quality, and I don't want to put in the effort to review someone's code if they are only having it reviewed to satisfy the process. These differences in values can really suck the energy out of the process.
The problem I have always had with agile is that it's held up as an "alternative" to waterfall, when in reality it's orthogonal to the two areas where waterfall excels: top-down project planning and contracting / expectation-setting with stakeholders.Agile is something that team programmers really love for its team-building qualities, but stakeholders / project sponsors / angel investors will always think in terms of deliverables and timeline.
Waterfall project management is useful because it provides a framework that stakeholders understand. It is also a requirement any time you are dealing with a bureaucracy of any sort, where deliverables and dates will be required.
TL;DR don't use waterfall to break down tasks and assign work, use agile for that. Use waterfall to understand and communicate your project from your stakeholder's / customer's point of view.
⬐ sbuttgereit⬐ ebbvI can definitely endorse this point of view. I've had success with it a number of times now. I think part of the key here is to recognize that you are working on a project (including managing it) in service of those that will consume the results.The mistake I often times see is that people forget that and end up in service of one methodology or another. Too many times I see a project manager types that can't reason out the distinction between the mechanics of a given project management process and the goal that process is setting out to achieve through the mechanics. Once you focus on what you're trying to achieve in any process, rather than how you're trying to achieve it, you can adjust your process to be optimal to the team/customer/etc. It's not all mutually exclusive and there are rarely benefits for being loyal to a methodology for purity's sake.
⬐ ap22213Until recently, 'Waterfall' was used to describe a process anti-pattern. At least, it was prior to 2010 or so.Software engineers have known for decades that iterative and incremental processes (spiral, UP, etc.) work best to manage risk, to prioritize important requirements, and to align with user goals. I'm not sure exactly when people started to use 'waterfall' as a real process.Recently, I've started educating my team on OpenUP (a simplified RUP), and they were surprised by it. I guess they imagined that software management didn't exist before SCRUM.
⬐ collyw⬐ UK-ALThere were plenty of successful projects written using waterfall. Not a great fit for all, but not an anti-pattern.⬐ ap22213You're just making things up now. Proof?⬐ collywYou really think there were no successful software before Agile came along?https://www.quora.com/What-are-names-of-successful-projects-...
⬐ riprowanYour proof is found in the entire canon of software engineering prior to the late 1980s, when the concepts of "prototyping" and "RAD" became feasible.When code was written by hand with pencil and paper, then translated to punch cards, "prototyping" was an exorbitant amount of work. Moreover it added little value, as the first two entire generations of information systems were little more than electronic implementations of very-well-understood business processes.
I studied systems analysis / engineering in the late 1980s. At the time, the entire paradigm of software engineering was waterfall, with the exception that the idea of prototyping was just getting started as something you could do iteratively in the "design / build" boundary.
If your team uses agile, but you report using waterfall. Your reports are not mapping reality. It's just lies to keep people happy.Quite simply the order you do things is radically different.
⬐ riprowanThe idea that waterfall and agile paradigms aren't compatible is incorrect in my opinion. They are orthogonal.Waterfall is just a paradigm that people comprehend because it maps to reality:
1. First you have to initiate something and define some sort of scope, otherwise, why are you even here?
2. Then you have to refine your understanding with more design
3. Sooner or later you have to actually build something, otherwise
4. Eventually you will have to deliver and implement it with humans in front of it
5. Someone will have to live with it for a while.
That's reality, on any project. How you choose to step through these phases - rigidly or fluidly, linearly or spiral-y, or linearly but recursively, doesn't mean that they don't exist in reality.
Likewise, agile is a paradigm that developers comprehend because it maps to their reality.
If you build software for customers, how you do it is your business, but you will be best off if you can frame it in a way that makes sense to the customer. Especially if that customer is the Department of Defense or some other customer who will demand deliverables on a timeline.
I've been building software professionally since the 1990s. As someone who learned programming at a young age, prototyping is my natural way of problem solving, and I think it's intuitive for most "natural programmers." So while I was taught "waterfall" in school and have always used it with my customers, I have always built by prototyping. My customers love it, because on the surface they see a software design process that they expect, and I can communicate my progress with pretty Gantt charts and familiar terminology.
YMMV, but it has worked great for me for decades.
⬐ douche> It's just lies to keep people happy.That's like 99% of business, anyway. There's a difference between what people think they need to know, and what they actually need to know. Unfortunately, just doing the work isn't enough, most of the time you have to play the game and tick the boxes. The key is not letting that bullshit consume your time.
⬐ ssmootIt's not though. This is why Agile is such a failure. Because people don't actually read the Manifesto.It doesn't say planning is unimportant. It doesn't say contract negotiation is unimportant. It doesn't say timelines and knowing what you're doing is unimportant.
You can and should do all these things. It's amazing to me that Software Developers seem to believe their job is somehow unique and it's just not possible to do simple things General Contractors and real Engineers do every day.
Agile is just a set of values that amount to "be pragmatic and flexible".
You can totally do that without Scrum and avoiding any sort of planning until the last possible moment.
IME actual requirements almost never change in software. They're just frequently not surfaced until code hits the page because little to no due diligence was done on them. And I very very rarely see a case where an issue with fulfilling the client's desires as given couldn't have been surfaced and resolved very early on if someone had just sat down and thought about it for a few minutes before going off and promising something that couldn't be delivered in the time or budget allowed.
⬐ kodIt's amazing to me that people compare a job that we have 7,000 years of experience with (making buildings) to a job that we have 70 years of experience with (making software).⬐ dasil003⬐ UK-ALAlso the construction of physical objects obeys unchanging physical laws. The construction of software is the coalescence of arbitrary logic.Real engineers decry the lack of discipline in software engineering, but I don't think it's possible to impose anything approaching the discipline of physical engineering without radically more constraints, but to do that would require subdividing software into a large number of much more focused domains, and even then, the divisions would be somewhat arbitrary.
Oh don't get me wrong, you have planning. You just do everything in a different order.It is radically different because waterfall has distinct phases at a "global" level.
Planning(All planning upfront) Implementation(Implement all the plan), Testing(test it all) UAT.
Agile has these but does them at a feature level. So the order is radically different. Planning(Plan feature or small groups of features) Implementation(implement feature), Testing(test the feature).
You do this over and over again for each feature or little iterations. You may have more loosely defined global plan, but it is not ridged and is expected change as the world changes.
Waterfall also encourages to complete parts of the website in distinct phases. Either horizontally or vertically. Complete all the Data access layer, or complete all of the "account functionality".
Agile takes small vertical slices. You may want to implement just the login for the account management, but leave the user profile pages until after some other more important vertical slice in some other area like checkout.
I think the problem is that people think Agile is a magic potion to fix dysfunctional teams and it isn't. Agile only works if your team works well together. There's any of number of ways for the team or the PO or the customers to make sure a project fails, whether you're operating in an Agile way or not.We switched to SCRUM last year at work and things have been amazing. My tune may change over time, but when we stick to the system we've developed things are great. 80% of our time is about getting work done. We focus on one project at a time and we deliver high quality code.
But there's more ways to make things fail than there are to make it succeed, and Agile is not a solution to people being terrible.
⬐ JoeAltmaier⬐ inanutshellusI was under the impression Agile was just the opposite - used to give structure to dysfunctional teams so they could learn to work together? Old established teams don't need more structure - they have grown processes that work for them.⬐ UK-ALAgile has a lot less structure compared to traditional project management.Decisions are made by developers, peers review each other instead of managers etc
Agile is about letting go of the traditional command and control thinking(Managers controlling employees, managers approving work, managers setting deadlines), and into trusting your developers to make good decisions, trust that they are not slacking and peer review.
⬐ jschwartziPeople don't get dysfunctional just because they have no structure.When people talk about dysfunctional teams, they're referring to behavior similar to that found in a dysfunctional family.
⬐ ebbvAgile doesn't give structure when compared with Waterfall (traditional project management), usually an Agile system is less structured (at least IMHO), and will have less meetings, shorter planning discussions, etc.If your team is dysfunctional Agile will not fix that. Agile requires a functioning team that can communicate together and invested in working together.
As a counter--FWIW--Agile works really well for me and my team. We work with 8 people in a "pod", we dogpile onto backlog items and destroy them. We pivot when the needs change. We trust each other but review the commits anyway. We don't do scrum-of-scrums (they're a symptom of a problem IMO), we minimize and mitigate any effects of external dependencies (e.g. our very first task in a project requiring them is to mock their expected/future implementation)...
We also eschew software solutions to sprint management, which matters. We also don't bother with morning stand-ups. ("Wait, you don't do morning stand-ups?!" - Yep. Morning stand-ups are training wheels for effective teams, and are necessary for folks that aren't co-located.)
Anyway. I know that "wait, no, this actually works" doesn't sell books or tools or get clicks, but just know that folks proclaiming its death are probably selling you something. Like... video clicks for ad revenue.
⬐ vonmoltke⬐ character0> Morning stand-ups are training wheels for effective teams, and are necessary for folks that aren't co-located.They're also necessary for teams where people are working on multiple projects at once. All the happy stories I hear about Agile come from people in your situation, where you have a team of X all concentrating on a single project. I'd love to be in that situation for once in my career.
⬐ inanutshellusAgile does not work well for service teams like tech-ops and stand-alone qa teams. Strict kanban works better for those.It still does work well for us even when we have multiple projects. Those multiple projects are time-sliced rather than resource-sliced whenever possible. In other words, keep your team focus on one thing for a given day. It's harder to get buy-in from your team to try it than it is to actually do and see succeed.
⬐ inanutshellus⬐ pbrbI can't edit it now, but, instead of saying "Agile (sic) doesn't work well for service teams" I should've said "Choose your own flavor of Agile Methodology to suit your needs".⬐ UK-ALKanban is an Agile Methodology.⬐ dragonwriterYou seem to be using "Agile" to mean some particular methodology, probably (at least, this is usual when this mistake is made), Scrum.But Agile isn't a methodology; it is a set of principles and priorities for use in determining (and adapting over time) the right methodology for a particular operation.
There are a number of methodologies that have been described as a result of (in theory, at least) applying Agile principles in particular environments. Scrum is one of those, but so is Kanban (and so are hybrids of the two, sometimes called "ScrumBan".)
This is so true. I see Agile be incredibly effective for teams with a single focus, and no (or very minimal) matrixing of team members across other teams. Once you start matrixing team members or adding additional focus, you start getting the 45 minute long stand ups. It's nuts.One insanely massive benefit I've seen from agile for any team is time blocking via sprints. Getting 2 weeks of effort without changing priorities is a huge win in our company.
⬐ douche2 weeks? I'd kill for two non-multiplexed days...⬐ pbrbYeah, it's a constant fight to keep things that way.For teams that need to be more reactive/responsive to constant change (like my own), scrumban has actually been a pretty good fit. We're a small 3 person team who is expected to turn high priority items around quickly, while also running longer term projects at the same time. Scrumban let's us track both needs pretty well, and we even pull tickets from other team's boards that we get matrixed into, onto our own internal board. Highly recommend trying it if you're in a similar position.
I've definitely seen the benefits of agile for my teams, but where it starts to fall apart is when the focus is velocity. This means management doesn't really have a clear goal, only that they are getting somewhere quickly. This leads to burn-out and typically those dev teams have no connection to their customer either.⬐ NoneNone⬐ lanestpThat was a fantastic talk, well worth the time. If I can summarize my takeaway it would be that Agile or agility is a holistic thought process to guide all your software decisions. The way people have implemented it is to have rigid guidelines that lets middle managers micromanage us to death. Sounds about right!⬐ p4wnc6This is very related to a comment [0] I made on another post yesterday, and some of the follow-up comments there.⬐ perseusprime11Agile is dead from day 1 as you can never be truly agile by simply changing the software development process to agile. What about financial processes like setting annual budgets. This is what happens when you put a bunch of white guys in a Lodge in Utah.⬐ p4wnc6One of the main ideas put forward by Thomas is that the generic agile principles are basically a reflection of gradient descent: take a small step in the direction you think you should go, evaluate the value of doing so and the error generated, then repeat. For a well-posed problem, you'll converge without taking huge steps generating tons of short term inefficiency.Real world Agile is effectively like taking this gradient descent idealization espoused by the agile creators and turning it into simulated annealing instead -- a vastly slower, dumber optimization method with no guarantees about avoiding local extrema.
This analogy carries you pretty far. It's all the extra political, bureaucratic, micromanagerial stuff that creates the effect of random displacements, as in simulated annealing, instead of calculated, deterministic displacements as in real gradient descent. (And hooking up user and customer feedback as a major driver for the displacements is one of the worst failure modes for this.)
For me, the trouble is that "real agile" (i.e. the "good" and "not manipulated" principles) doesn't provide any mechanism for explicitly preventing this kind of political subversion. It's just too easy for middle managers and bureaucrats to subvert for their own purposes, while shoving all the negative externalities of doing so onto lowly developers.
I don't particularly like Agile because I don't think one-size-fits-all approaches will ever work (e.g. every sprint must be 2 weeks long, every workflow must involve story points, etc.).
But if I had to think about a way to vindicate Agile and protect it from subversion, I would suggest it needs some kind of explicit statement that short-term business concerns are not valid excuses for modifying the process. Of course, then managers won't like it ... because they only like things that give them metric surface area with which to politically manipulate the situation for their changing agenda, and so Agile would become impossible to sell to huge companies.
It's a Catch-22. Actually good software dev practices that make money, make customers happy, and live up to quality standards instead of just paying lip service to them are completely at odds with executives and managers who want to torch the commons for the sake of short term bonuses and couldn't give two shits about whether it makes customers unhappy, etc. (because they will have secured blame insurance against that anyway, and may even make more money from endless irrational tech re-orgs).
⬐ matdrewinJust like in software development, a framework/methodology is not a replacement for competence. People apply idioms blindly without putting things into context.⬐ daxfohlI agree with the view on testing. I mostly use testing as an excuse to shape up bad old code when starting work on existing products, then delete the tests afterwards.⬐ mrharrisonAgile works fine. I find that people are broken and don't want to change, or they want to adopt some magic formula by talking about it a lot but don't actually practice it and when they run into problems they blame the process they weren't practicing correctly. If somebody has a process to change people's bad attitudes I would love to learn that.⬐ CypherI saw this a year ago too, its was a good watch.⬐ forloop⬐ brightballIt was on /r/programming 4 months ago[0]. As far as I can tell, HN is behind the times, these days.Not only with stories, but also world view.
[0] https://www.reddit.com/submit?url=https%3A%2F%2Fwww.youtube....
Very much worth watching. Agile is not a noun. :-)⬐ ljw1001if only.⬐ kabdibManagement: "You mean there's a software development methodology that lets us track dev progress with a microscope, and that eschews planning (which we hate and suck at anyway)? And bonus it makes us look hip and with-it? Sign us up!"I knew Agile was dead the moment that Microsoft managers started to "implement" it.
⬐ kpsCapital-A Agile is essentially collectivized micromanagement, and brings together all the well-known advantages of collectivization and micromanagement.⬐ UK-ALWhy? Microsoft consistently develops some of the most popular products.⬐ na85⬐ simonswords82Microsoft's products are popular due to excellent marketing, not because of their technical merits.Most of their products are mediocre at best, and many of them seriously suck. Particularly their operating system.
IMHO the only thing MS has produced that's actually good is Excel.
⬐ ankoVisual Studio is awesomeHmmm....I understand what you're saying but we still use agile at my software company and as one of its managers that's not my take. Here's my view on the points you've raised:It does allow us to track dev progress, but with great power comes great responsibility. We don't micromanage our devs but we do use the data this produces to keep clients up to speed on development progress. This allows us to be mega transparent, generates trust and this makes clients happy and less prone to worrying.
We still plan, but we don't try to plan the full project ahead of time, we all know that never ends well. We work with our clients to plan 2 x two week sprints. When those sprints are complete we pull them back in to get their feedback and decide what needs to be done in the upcoming sprints. This gives clients flexibility as they often need to change their minds when they see the finished sprint. It works for them and us.
Agile in and of itself doesn't make us look hip unfortunately. Trello, the tool we use to map out sprints and report on progress does though. Our clients love it and it's revolutionised our relationships with them. In fact, a major reason we won another big contract just last week was due to the approach I've outlined above.
I really don't like velocity as a metric. It's about as useful as counting lines of code to judge a project's completion.I don't think I could explain it as well as Dave Thomas says it, so here's a link to his fantastic keynote: https://www.youtube.com/watch?v=a-BOSpxYJ9M
⬐ mikekcharUnfortunately the link is a little longer than I have time to view today, but I will put it on my to-watch list ;-)As you say, velocity is a poor metric. But before I explain what I mean by that, I should define "metric". The dictionary defines it to be simply a measurement, but in software process engineering, "metric" is often a special term. It means a measurement that you use to modify your process.
The problem with velocity is that it is a measurement that is highly dependent upon your process. It simply divides an amount of work by an amount of time. However, the amount of work is actually a random variable with a certain distribution. When you change your process, the amount of work changes (as does it's distribution). So the end result is that if you have 2 processes, P1 and P2, with velocities, V1 and V2, V1 is almost completely unrelated to V2. This means that you can't use it to measure the success of process changes.
However, velocity is not useless. It is an excellent measure (not metric). Before, I mentioned that you are dividing an amount of work (a random variable with a certain distribution) by an amount of time. You may not know what the distribution is for the amount of work done, but if you take the mean of a sufficient number of these random variables, then that mean is roughly normally distributed (as per the central limit theorem).
In plain terms, this means that if you have enough small stories, the average amount of work for each story will be roughly normally distributed. As long as you don't change your process/programmers/etc the amount of time it takes will also be roughly normally distributed. So by taking some measurements, you can estimate (with error bars!) how long a given set of stories will take -- as long as nothing changes.
That last bit is important and is why velocity makes a poor metric. In fact, it is such a poor metric that IMHO you should never publish your velocity. Work in story points and leave calculating the overall estimated time of completion to someone who is not doing the work. Otherwise someone will start asking questions like, "How can we get our velocity higher?" (it has happened on every team I've worked on).
Incidentally, I have experimented with modelling requirements discovery during development -- i.e., trying to predict how much extra work will be added to a project from any given point until you ship. It seems to follow a curve that is very similar to Littlewood's defect discovery model (which is probably not so surprising). Again, by estimating the average rate at which requirements are added, one can probably estimate how much extra work will be required in addition to that already planned.
⬐ jeremiepI hear you, I've also heard "How can we get our velocity higher?" more times than I can count.What I don't like about velocity is that it encourages the gamification of the process. Developers start caring more about their velocity than the quality of their code and before long nobody has any clue of the big picture and the project starts going down the drain.
Working in the video game industry, I see the striking difference between playing games and developing games first hand, every day :)