8 ms·

Agile is people, the rest is commentary

94 points by BerislavLopac 3y ago

breckenedge 3y ago
A whole blog post about it, yet not one link to the original? https://agilemanifesto.org/ https://agilemanifesto.org/
- BLKNSLVR 3y ago
  They quote it in the article. And it's easier to read in the article because there isn't awful contrast between text and background like on the site you linked to.
  - StellarScience 3y ago
    In 2001, having a background image was cool. It's the original "agile" site; I guess they haven't touched it since then. I also enjoy the 2010 version: https://www.halfarsedagilemanifesto.org/ https://www.halfarsedagilemanifesto.org/ .
  - petepete 3y ago
    The original was meant to be printed out and hung as a poster rather than read on the web. I made a more accessible version of it a couple of years ago. https://accessible-agile-manifesto.netlify.app/ https://accessible-agile-manifesto.netlify.app/
deleted 3y ago
[deleted]
solraph 3y ago
I don't disagree with the general take of the post, but I feel I can answer this particular point. > What if you’re working with a major language barrier in the team, and misunderstandings can be mitigated with processes? Process is communication. It's a way of doing mass communication. Instead of explicitly communicating everything to everyone, a process is way of saying "when X happens, you can assume Y". For example, if a card is in the Done column, you can assume the code is in version control, deployed to production and checked to make sure it didn't explode on impact. Then, instead of explicitly communicating every single deployment, you only need to communicate the exceptions. (ie; the things that don't fit neatly into an existing process) If you're working in a team that has a major language barrier, I don't see how having a process can mitigate the need to explain that process, nor how the exceptions can be communicated effectively.
- zimbu668 3y ago
  > if a card is in the Done column, you can assume the > code is in version control, deployed to production > and checked to make sure it didn't explode on impact. I guess you've never seen a team argue over "Definition of Done" for months.
  - rukuu001 3y ago
    Yes, this is tricky, but ideally the definition of done is decided before the card gets into the 'in progress' column.
  - solraph 3y ago
    > I guess you've never seen a team argue over "Definition of Done" for months. Unfortunately, I have had that conversation plenty of times. The point is to have that conversation/argument once, make a decision on what it means for the team, and then move on.
h0l0cube 3y ago
The better critique is from one of the authors of the agile manifesto, who recommends a shift in language: > I don’t think anyone could object to a ban on the word when it is used as a noun. That’s just plain wrong. “Do Agile Right” and “Agile for Dummies” are just two of the innumerable attacks on the English language featuring the word. They are meaningless. Agile is not a noun, it’s an adjective, and it must qualify something else. “Do Agile Right” is like saying “Do Orange Right.” > But, beyond the grammar problem, there’s a bigger issue. Once the Manifesto became popular, the word agile became a magnet for anyone with points to espouse, hours to bill, or products to sell. It became a marketing term, coopted to improve sales in the same way that words such as eco and natural are. A word that is abused in this way becomes useless—it stops having meaning as it transitions into a brand. ... > Let’s develop with agility > You aren’t an agile programmer—you’re a programmer who programs with agility. > You don’t work on an agile team—your team exhibits agility. > You don’t use agile tools—you use tools that enhance your agility. https://pragdave.me/thoughts/active/2014-03-04-time-to-kill-agile.html https://pragdave.me/thoughts/active/2014-03-04-time-to-kill-...
- steveBK123 3y ago
  Precisely. I worked in a dev org with under 100 devs/dev managers, which had 0 budget for project managers, QA, (or a DR plan for that matter) but did have budget for no less than an entire team of 3 fulltime "agile" coaches/consultants for upwards of 4 years or more. The word has been stolen by the worst charlatans who are enriching themselves on the back of our industry.
  - rightbyte 3y ago
    Ye why is this. How can it be so easy for management to get permission to hire a Scrum Lord but not a designated QA dev? Like, in big projects I would like one QA for every 5 programmers to keep us from building backwards.
    - steveBK123 3y ago
      Precisely. Incentives. CTO can pitch "going agile" and how its the latest & greatest, and they are going to get more output out of the dev org more quickly. "Hiring some QA" is not nearly as sexy.
doctor_eval 3y ago
Well in addition to the four values there are also 12 principles of the agile manifesto. And agile leaves plenty of room to deal with the issues mentioned. The actual problem with agile, as I’ve seen first hand, is that teams adopt Scrum as if it’s some Agile Silver Bullet. If you just do what you’re told by the CSM, then projects will go better. This is especially true when there is a power imbalance, developer problems are swept under the carpet, and retros are discouraged or non existent. It’s nonsense. Like all practices, there are all sorts of problems intrinsic to Scrum that need to be considered carefully and resolved. How do you manage a large backlog? How do you deal with unexpected complexity discovered at the very start of a sprint? Where are the overall project goals documented - and how do we measure against them? This is not to say that these problems can’t be dealt with in scrum. The Agile Manifesto leaves plenty of room for resolving them, but Scrum is being taught by many as the One True Way, and if you dare suggest changes or deficiencies in the process then you just Don’t Get It. It’s the rigidity of these practices that has become the problem - the way I’ve seen Scrum implemented in several large projects is effectively waterfall with a scrum veneer. When you’ve been shipping software for more than the length of your adult life, it gets tiresome to have someone with a dodgy certification in agile project management explain how to ship.
- calvinmorrison 3y ago
  The backlog helps solve problems above my team not for my team. I tick tok between sprint planning and kickoffs with developers. My superiors need to prioritize and literally rank the stuff they need done. Otherwise everything is a priority and nothing gets done.
  - doctor_eval 3y ago
    Well, as the Manifesto says, "Business people and developers must work together daily throughout the project." But Scrum's approach to this is overly simplistic (product owners?), backlog reprioritisation is not part of Scrum, and in any case you really ought to have some control over priorities because doing certain stories in the wrong order will reduce productivity. The problem that I'm pointing out is that Scrum has become synonymous with Agile in many quarters, and yet it is far from a complete solution to software project management. It's not that Scrum is no good, it's that it's not enough (or, in some cases, too much). When I've been forced to use some BigCo's rigid version of "Scrum", it's always been a nightmare. Of course it was, because rigid is the opposite of agile.
nathants 3y ago
[flagged]
pdntspa 3y ago
Is there a software methodology that does away with all the ceremony and standups and meetings and trusts me to receive a task and see it to completion without management interference? I am still very pissed that the job of an SWE has become this pastiche of different business fucks telling me how to make stuff and hectoring me with random JIRA bullshit. Tell me what you want, put me in touch with my stakeholders, give me a POC for progress updates, and stand the hell back. LEAN seems to be about as close as we can get. Otherwise, to this antisocial developer that just wants to be left alone, agile sucks.
- solraph 3y ago
  Agile can be this, but it requires finding a company that trusts it's SWE people. Once you have that trust, the rest of it just flows from there. But - it requires everyone to actually be willing to work this way. I work in a company/team that has this, and while we use Jira[0], it's effectively there to remember what we need to do for a given task/bug and ensure that two people don't work on the same thing. The use of Epics lets management & stakeholders see what is happening with a given feature without bugging us. We don't have estimations, retros, or any of the other usual rituals, and it's amazing. If there's a mismatch of expectations or we need to hash something out there's Slack and Zoom. Someone volunteers to write up a card, and we're done. The corollary is that we've had a couple of hires come and go who just did not have the skills and/or interest in being part of those conversations, and they did not last. I'm in two minds if this is the damage inflicted on them by years of managerial Taylorism, or that they just could not keep up with the rest of the team. I expect (but hope to be wrong) that once we expand enough to have actual juniors we might have to embrace some of the more ritual parts of agile. [0] We use Jira in Kanban mode with a couple of text templates for the different card types (epic, story, bug), and none of the usual rules about what can be moved in and out of what column. EDIT: complete->couple
  - pdntspa 3y ago
    That sounds like paradise compared to the last couple of companies I worked for.
  - yCombLinks 3y ago
black_13 3y ago
[dead]
mojo74 3y ago
I don't think even employers know what it is anymore. The amount of posts for jobs I have seen where experience of 'agile and waterfall is desirable' is mentioned in the same breath. You think 'what sh!t show am I letting myself in for if the business doesn't know how they operate?'
- Hexigonz 3y ago
  To be fair, my org (very good org, I’ve worked at several) just posted a job position with this exact sentence in it. We need a PM who can work in a more agile manner while helping us to interface with teams who use waterfall due to the nature of the work. It’s not unheard of.
- wildrhythms 3y ago
  It's MBAs telling engineers how to effectively do a job that they themselves have no idea how to do.
- 9659 3y ago
  fundamental advantage of waterfall: "Done" is defined.
  - bluGill 3y ago
    Not just done, also the end date. If your customers have a specific date where things must be done you dare not lose track of the end date. In some fields congress has said things by some date, and things are bad if you fail to meet that date. If you are targeting mars, then if you are not ready for launch month your next opportunity is over a year latter. On large projects all the parts need to come together at the same time, if software is going to be late the mechanical engineers get more time.
mkarliner 3y ago
I wish I could give this 2 upvotes. And you are right about the Talmud.
caseymarquis 3y ago
Since the word agile has become so loaded, you can instead explain why a waterfall practice is linked to predictable problems and avoid buzzwords entirely: It takes 6 months to act on customer feedback with our current release strategy, and a full year to fix the bugs related to that feedback. We should be rapidly iterating on feedback quickly to avoid churn. Let's try xyz...
- makeitdouble 3y ago
  With that approach, the discussion would more look like "Our current cycle takes a full year to complete, let's reduce our projets' scopes by 10 to get down to a month or two at most" That's even simpler, and you can even keep waterfalling and still benefit from shorter iterations.
harimau777 3y ago
I don't think that Agile can work outside of a workplace that is unionized or doesn't have at will employment. Otherwise what you end up with is Agile rules being applied only when they serve management. Agile effectively becomes a weapon to bludgeon engineers with.
Stranger43 3y ago
The problem with "The Agile Manifesto" and the cargo cult that arose around it, is that while the manifesto pretty accurately described what a lot of people felt was wrong with the "Civil Engineering" approach to software development it never represented an reliable methodology for how to actually fix those problems. This is why we keep seeing those "no true scotsman argument" against any real world attempt to "be agile" where no failure can ever be seen as an argument against the usefulness of "The Agile Manifesto", and it's not really a new or surprising process but something that happens to most movements created around a loose manifesto. What will change things for the better is pragmatism based on observations and currently thats not the way the Agile movement seems to be moving.
- exitb 3y ago
  What if there is no methodology to Agile? What if the whole attempt is akin to finding a methodology for becoming a rockstar, or a famous painter? It kind of seems like the manifesto points out that the best way to create software is to get the right people and don't disturb them. And, if fact, if I try to think of examples of good software, this is usually how it came about, doesn't it? A small, talented, motivated group of people just working passionately on a problem. Obviously, though, this does not scale at all.
  - jasonwatkinspdx 3y ago
    Yeah, I worked with one of the authors and their perspective was that conversations between developers and subject matter experts were what was primary, and methodology was just whatever helped a team enable that. They were quite disappointed with the consulting industry that sprung up and its many variations of "the one true way to do agile."
- SAI_Peregrinus 3y ago
  The other issue is that it was written by contractors, as advice for other contractors. It's not as applicable to long-term work for entire companies. "Customer collaboration over contract negotiation" doesn't apply at all for most engineers; they're not the ones negotiating the contracts!
nerdjon 3y ago
There was always something that really bothered me about the Agile movement and I am glad that it seems to have gone away. People would say it is flexible and meant to be guidelines that can be changed to fit your team. And then we would go and do a bunch of training, hire scrum masters, etc that would all tell us we were doing "Agile" wrong. Those 2 statements don't work together. I also cannot understand how we convinced companies that hiring full time agile coaches, scrum masters, etc were at all not a waste of money. I also felt like we had way too many meetings with very little value. Meetings that were really just focused on the process. I know some people think that meetings are being productive but I strongly do not feel that way. Obviously there are some valuable meetings, but most of the agile ones I felt were a waste of time. There are pieces of Agile that have continued, like standup, but largely I have not been "agile" for several years and I feel like I am more productive because of it.
- lisasays 3y ago
  Those 2 statements don't work together. They sure don't. But they work another way. By getting people to go along with patently contradictory belief systems (or glaring conflicts between what it said and what actually happens in reality), so as to break down psychological barriers, and make them more pliant to authority generally. As with any functioning cult operation. I also felt like we had way too many meetings with very little value. Well yeah, but only in the superficial sense related to, you know, the company's business and the actual work to be done. But in terms of their true purpose: keeping the Agile cult running, and helping legions of undertalented managers keep their jobs (along with the SCMs they inevitably hire in place of actual engineering or management talent) -- these meetings are beautifully effective, indeed.

94 points by BerislavLopac 3y ago

breckenedge 3y ago

A whole blog post about it, yet not one link to the original? https://agilemanifesto.org/ https://agilemanifesto.org/

BLKNSLVR 3y ago
They quote it in the article. And it's easier to read in the article because there isn't awful contrast between text and background like on the site you linked to.
- StellarScience 3y ago
  In 2001, having a background image was cool. It's the original "agile" site; I guess they haven't touched it since then. I also enjoy the 2010 version: https://www.halfarsedagilemanifesto.org/ https://www.halfarsedagilemanifesto.org/ .
- petepete 3y ago
  The original was meant to be printed out and hung as a poster rather than read on the web. I made a more accessible version of it a couple of years ago. https://accessible-agile-manifesto.netlify.app/ https://accessible-agile-manifesto.netlify.app/

deleted 3y ago

[deleted]

solraph 3y ago

I don't disagree with the general take of the post, but I feel I can answer this particular point. > What if you’re working with a major language barrier in the team, and misunderstandings can be mitigated with processes? Process is communication. It's a way of doing mass communication. Instead of explicitly communicating everything to everyone, a process is way of saying "when X happens, you can assume Y". For example, if a card is in the Done column, you can assume the code is in version control, deployed to production and checked to make sure it didn't explode on impact. Then, instead of explicitly communicating every single deployment, you only need to communicate the exceptions. (ie; the things that don't fit neatly into an existing process) If you're working in a team that has a major language barrier, I don't see how having a process can mitigate the need to explain that process, nor how the exceptions can be communicated effectively.

zimbu668 3y ago
> if a card is in the Done column, you can assume the > code is in version control, deployed to production > and checked to make sure it didn't explode on impact. I guess you've never seen a team argue over "Definition of Done" for months.
- rukuu001 3y ago
  Yes, this is tricky, but ideally the definition of done is decided before the card gets into the 'in progress' column.
- solraph 3y ago
  > I guess you've never seen a team argue over "Definition of Done" for months. Unfortunately, I have had that conversation plenty of times. The point is to have that conversation/argument once, make a decision on what it means for the team, and then move on.

h0l0cube 3y ago

The better critique is from one of the authors of the agile manifesto, who recommends a shift in language: > I don’t think anyone could object to a ban on the word when it is used as a noun. That’s just plain wrong. “Do Agile Right” and “Agile for Dummies” are just two of the innumerable attacks on the English language featuring the word. They are meaningless. Agile is not a noun, it’s an adjective, and it must qualify something else. “Do Agile Right” is like saying “Do Orange Right.” > But, beyond the grammar problem, there’s a bigger issue. Once the Manifesto became popular, the word agile became a magnet for anyone with points to espouse, hours to bill, or products to sell. It became a marketing term, coopted to improve sales in the same way that words such as eco and natural are. A word that is abused in this way becomes useless—it stops having meaning as it transitions into a brand. ... > Let’s develop with agility > You aren’t an agile programmer—you’re a programmer who programs with agility. > You don’t work on an agile team—your team exhibits agility. > You don’t use agile tools—you use tools that enhance your agility. https://pragdave.me/thoughts/active/2014-03-04-time-to-kill-agile.html https://pragdave.me/thoughts/active/2014-03-04-time-to-kill-...

steveBK123 3y ago
Precisely. I worked in a dev org with under 100 devs/dev managers, which had 0 budget for project managers, QA, (or a DR plan for that matter) but did have budget for no less than an entire team of 3 fulltime "agile" coaches/consultants for upwards of 4 years or more. The word has been stolen by the worst charlatans who are enriching themselves on the back of our industry.
- rightbyte 3y ago
  Ye why is this. How can it be so easy for management to get permission to hire a Scrum Lord but not a designated QA dev? Like, in big projects I would like one QA for every 5 programmers to keep us from building backwards.
  - steveBK123 3y ago
    Precisely. Incentives. CTO can pitch "going agile" and how its the latest & greatest, and they are going to get more output out of the dev org more quickly. "Hiring some QA" is not nearly as sexy.

doctor_eval 3y ago

Well in addition to the four values there are also 12 principles of the agile manifesto. And agile leaves plenty of room to deal with the issues mentioned. The actual problem with agile, as I’ve seen first hand, is that teams adopt Scrum as if it’s some Agile Silver Bullet. If you just do what you’re told by the CSM, then projects will go better. This is especially true when there is a power imbalance, developer problems are swept under the carpet, and retros are discouraged or non existent. It’s nonsense. Like all practices, there are all sorts of problems intrinsic to Scrum that need to be considered carefully and resolved. How do you manage a large backlog? How do you deal with unexpected complexity discovered at the very start of a sprint? Where are the overall project goals documented - and how do we measure against them? This is not to say that these problems can’t be dealt with in scrum. The Agile Manifesto leaves plenty of room for resolving them, but Scrum is being taught by many as the One True Way, and if you dare suggest changes or deficiencies in the process then you just Don’t Get It. It’s the rigidity of these practices that has become the problem - the way I’ve seen Scrum implemented in several large projects is effectively waterfall with a scrum veneer. When you’ve been shipping software for more than the length of your adult life, it gets tiresome to have someone with a dodgy certification in agile project management explain how to ship.

calvinmorrison 3y ago
The backlog helps solve problems above my team not for my team. I tick tok between sprint planning and kickoffs with developers. My superiors need to prioritize and literally rank the stuff they need done. Otherwise everything is a priority and nothing gets done.
- doctor_eval 3y ago
  Well, as the Manifesto says, "Business people and developers must work together daily throughout the project." But Scrum's approach to this is overly simplistic (product owners?), backlog reprioritisation is not part of Scrum, and in any case you really ought to have some control over priorities because doing certain stories in the wrong order will reduce productivity. The problem that I'm pointing out is that Scrum has become synonymous with Agile in many quarters, and yet it is far from a complete solution to software project management. It's not that Scrum is no good, it's that it's not enough (or, in some cases, too much). When I've been forced to use some BigCo's rigid version of "Scrum", it's always been a nightmare. Of course it was, because rigid is the opposite of agile.

nathants 3y ago

[flagged]

pdntspa 3y ago

Is there a software methodology that does away with all the ceremony and standups and meetings and trusts me to receive a task and see it to completion without management interference? I am still very pissed that the job of an SWE has become this pastiche of different business fucks telling me how to make stuff and hectoring me with random JIRA bullshit. Tell me what you want, put me in touch with my stakeholders, give me a POC for progress updates, and stand the hell back. LEAN seems to be about as close as we can get. Otherwise, to this antisocial developer that just wants to be left alone, agile sucks.

solraph 3y ago
Agile can be this, but it requires finding a company that trusts it's SWE people. Once you have that trust, the rest of it just flows from there. But - it requires everyone to actually be willing to work this way. I work in a company/team that has this, and while we use Jira[0], it's effectively there to remember what we need to do for a given task/bug and ensure that two people don't work on the same thing. The use of Epics lets management & stakeholders see what is happening with a given feature without bugging us. We don't have estimations, retros, or any of the other usual rituals, and it's amazing. If there's a mismatch of expectations or we need to hash something out there's Slack and Zoom. Someone volunteers to write up a card, and we're done. The corollary is that we've had a couple of hires come and go who just did not have the skills and/or interest in being part of those conversations, and they did not last. I'm in two minds if this is the damage inflicted on them by years of managerial Taylorism, or that they just could not keep up with the rest of the team. I expect (but hope to be wrong) that once we expand enough to have actual juniors we might have to embrace some of the more ritual parts of agile. [0] We use Jira in Kanban mode with a couple of text templates for the different card types (epic, story, bug), and none of the usual rules about what can be moved in and out of what column. EDIT: complete->couple
- pdntspa 3y ago
  That sounds like paradise compared to the last couple of companies I worked for.
- yCombLinks 3y ago

black_13 3y ago

[dead]

mojo74 3y ago

I don't think even employers know what it is anymore. The amount of posts for jobs I have seen where experience of 'agile and waterfall is desirable' is mentioned in the same breath. You think 'what sh!t show am I letting myself in for if the business doesn't know how they operate?'

Hexigonz 3y ago
To be fair, my org (very good org, I’ve worked at several) just posted a job position with this exact sentence in it. We need a PM who can work in a more agile manner while helping us to interface with teams who use waterfall due to the nature of the work. It’s not unheard of.
wildrhythms 3y ago
It's MBAs telling engineers how to effectively do a job that they themselves have no idea how to do.
9659 3y ago
fundamental advantage of waterfall: "Done" is defined.
- bluGill 3y ago
  Not just done, also the end date. If your customers have a specific date where things must be done you dare not lose track of the end date. In some fields congress has said things by some date, and things are bad if you fail to meet that date. If you are targeting mars, then if you are not ready for launch month your next opportunity is over a year latter. On large projects all the parts need to come together at the same time, if software is going to be late the mechanical engineers get more time.

mkarliner 3y ago

I wish I could give this 2 upvotes. And you are right about the Talmud.

caseymarquis 3y ago

Since the word agile has become so loaded, you can instead explain why a waterfall practice is linked to predictable problems and avoid buzzwords entirely: It takes 6 months to act on customer feedback with our current release strategy, and a full year to fix the bugs related to that feedback. We should be rapidly iterating on feedback quickly to avoid churn. Let's try xyz...

makeitdouble 3y ago
With that approach, the discussion would more look like "Our current cycle takes a full year to complete, let's reduce our projets' scopes by 10 to get down to a month or two at most" That's even simpler, and you can even keep waterfalling and still benefit from shorter iterations.

harimau777 3y ago

I don't think that Agile can work outside of a workplace that is unionized or doesn't have at will employment. Otherwise what you end up with is Agile rules being applied only when they serve management. Agile effectively becomes a weapon to bludgeon engineers with.

Stranger43 3y ago

The problem with "The Agile Manifesto" and the cargo cult that arose around it, is that while the manifesto pretty accurately described what a lot of people felt was wrong with the "Civil Engineering" approach to software development it never represented an reliable methodology for how to actually fix those problems. This is why we keep seeing those "no true scotsman argument" against any real world attempt to "be agile" where no failure can ever be seen as an argument against the usefulness of "The Agile Manifesto", and it's not really a new or surprising process but something that happens to most movements created around a loose manifesto. What will change things for the better is pragmatism based on observations and currently thats not the way the Agile movement seems to be moving.

exitb 3y ago
What if there is no methodology to Agile? What if the whole attempt is akin to finding a methodology for becoming a rockstar, or a famous painter? It kind of seems like the manifesto points out that the best way to create software is to get the right people and don't disturb them. And, if fact, if I try to think of examples of good software, this is usually how it came about, doesn't it? A small, talented, motivated group of people just working passionately on a problem. Obviously, though, this does not scale at all.
- jasonwatkinspdx 3y ago
  Yeah, I worked with one of the authors and their perspective was that conversations between developers and subject matter experts were what was primary, and methodology was just whatever helped a team enable that. They were quite disappointed with the consulting industry that sprung up and its many variations of "the one true way to do agile."
SAI_Peregrinus 3y ago
The other issue is that it was written by contractors, as advice for other contractors. It's not as applicable to long-term work for entire companies. "Customer collaboration over contract negotiation" doesn't apply at all for most engineers; they're not the ones negotiating the contracts!

nerdjon 3y ago

There was always something that really bothered me about the Agile movement and I am glad that it seems to have gone away. People would say it is flexible and meant to be guidelines that can be changed to fit your team. And then we would go and do a bunch of training, hire scrum masters, etc that would all tell us we were doing "Agile" wrong. Those 2 statements don't work together. I also cannot understand how we convinced companies that hiring full time agile coaches, scrum masters, etc were at all not a waste of money. I also felt like we had way too many meetings with very little value. Meetings that were really just focused on the process. I know some people think that meetings are being productive but I strongly do not feel that way. Obviously there are some valuable meetings, but most of the agile ones I felt were a waste of time. There are pieces of Agile that have continued, like standup, but largely I have not been "agile" for several years and I feel like I am more productive because of it.

lisasays 3y ago
Those 2 statements don't work together. They sure don't. But they work another way. By getting people to go along with patently contradictory belief systems (or glaring conflicts between what it said and what actually happens in reality), so as to break down psychological barriers, and make them more pliant to authority generally. As with any functioning cult operation. I also felt like we had way too many meetings with very little value. Well yeah, but only in the superficial sense related to, you know, the company's business and the actual work to be done. But in terms of their true purpose: keeping the Agile cult running, and helping legions of undertalented managers keep their jobs (along with the SCMs they inevitably hire in place of actual engineering or management talent) -- these meetings are beautifully effective, indeed.