Retros: Retros are about being more effective. That usually means talking about and solving problems. If too many problems are beyond the team's control, that's indicative of a "faux agile" or "dark agile" environment. If your "CEO being a dickhead" is the biggest problem in anything but the smallest organizations, your CEO is not pushing decisions down to the lowest possible level where they can be made and isn't trusting and respecting the people with the knowledge and skills to get the work done. This is the kind of cultural shift needed to make agility work. If most decisions are made two or three (or more) levels above the team, then agility falls apart. When it comes to successes, it's not about patting yourselves on the back, but about finding ways to repeat those successes again and again in the future.
Standups: Even a "quick morning briefing'" isn't the intent of a standup. It's a planning session. If you have a bunch of people who barely work together, you won't get value from a daily standup. But when you have highly collaborative teams and are planning things like who is going to pair or mob today, what work will be integrated and would be ready for review, what unexpected problems came up, how to account for someone's unplanned time off, or how to plan for someone's upcoming time off, then you're getting value. In some cases, daily is even a bit much. Two or three times a week could work, especially if the team communicates regularly and well outside of this meeting.
Agile coaches: Unfortunately, companies hiring unqualified coaches has turned this role into nothing more than a team secretary or admin. Looking at Lyssa Adkins and Michael Spayd's Agile Coach Competency Framework shows that an effective agile coach needs many skills: lean and agile practice, teaching and mentoring, coaching and facilitating, and mastery in at least one of technical, business/product, or organizational development and transformation. Instead of hiring people who could actually teach and coach their teams and organizations on how to reorganize themselves and apply new practices, they hired people who took a two-day course without any practical experience in a lean or agile organization and who can't teach the people doing the work. Even if you do get someone with the right skills, the organization needs to trust and respect this person and be willing to make the changes needed to support agility.
Sprint / cycle planning: There are many models that emphasize continuous flow. However, it's not so much about the planning but the continuous heartbeat of the entire iteration. Sometimes, it's easier for key stakeholders to interact with the team on a regular, pre-defined cadence. When you establish that interaction, regular planning comes naturally since you want to plan what you'll do between the end of one interaction and the start of the next. If you're getting constant feedback, though, the value of this decreases. I would say that estimation, especially at the unit-of-work level, is unnecessary, and there are plenty of resources on using historical data on work completion to plan upcoming work.
Grooming: No single person can make the right work on their own. Investing a little time from the whole team to review the work and develop a shared understanding greatly reduces the time needed to plan the work. You can also think about many perspectives - what various external stakeholders need or want, the architecture of the system, how you'll verify and validate the work, how to make sure it's deployable and operatable (and monitorable) in production. You'll find ways to reorder the work because doing X before Y will reduce the risk of Y or you'll find that the team needs to prototype and explore. Without some kind of refinement activity, I'm not sure how work can be clearly defined for the team to execute.
Trusting people to do their jobs is the heart of lean and agile methods. But, at the same time, you need structures and patterns to coordinate people, both internally on a team and externally with stakeholders. The problems arise when there is no trust, and people are forced to work in ways that simply aren't appropriate for their context.
Really good and nuanced response, thank you. I'm aware that my original post is a bit facetious and in bad faith.
I think my issue really is that a lot of what you're describing feels like it only works in theory, but my experience in practice is that it never works the way it's meant to because the culture to do it just isn't there. There's always a dickhead CEO. There's always one mobile developer who was shoehorned into the team because they nobody knew where to put them, their work isn't really relevant to anyone else on the team, but they're forced to come to all this ceremony that has no relevance to their work. There's always people who treat it like a status update.
Maybe it can work. I'd be interested to hear from somebody who's practised it and had it work well. But I don't think that place exists.
In practice, the frameworks don't work out of the box. Take Scrum, for example. The framework described today has had all the original technical practices used by the first Scrum Teams stripped out, with no new technical practices added, and it's been generalized to fit many organizations so it's marketable. There are many questions to ask. Why do I need to have a Daily Scrum every day? If I'm mobbing, do I need a Daily Scrum at all? Why a maximum timebox of a month for a Sprint instead of 5 or 6 weeks? What technical practices do I need to deliver software every day or week? All of these are important questions that would likely result in changes.
The culture is the big thing.
I've only worked in very large enterprises, but I've never had to deal with a dickhead CEO because they push decisions down. I haven't even had to deal with a dickhead business unit VP or director. Decisions are actively made 3 or 4 levels below the CEO. That's almost always at the product level, which could be one level up from a team if multiple teams work on a single product. I've also rarely had to deal with people being shoehorned in because we strive to eliminate single points of failure. That means having at least two people with (or working toward) a given skill set, cross-training, and being willing to work outside their comfort zone. People who stay in their niche and don't work with others often don't last long, by their choice.
So, yes. These things can work. I've done it. But it means you can't follow someone else's script or a canned framework and set of tools. It means having a deep understanding of why a framework has made certain choices around roles and events and what to change to build something that works for you. But it's also cultural change in the organization because agile ways of working are inherently different than predictive methods - they need different relationships and inputs and create different outputs.
A better title would be "Dark Agile is a scourge on the planet". There are plenty of people who've written about this, but Ron Jeffries' posts "Dark Scrum" (https://ronjeffries.com/articles/016-09ff/defense/) and "We Tried Baseball and It Didn't Work" (https://ronjeffries.com/xprog/articles/jatbaseball/) cover this well.
Retros: Retros are about being more effective. That usually means talking about and solving problems. If too many problems are beyond the team's control, that's indicative of a "faux agile" or "dark agile" environment. If your "CEO being a dickhead" is the biggest problem in anything but the smallest organizations, your CEO is not pushing decisions down to the lowest possible level where they can be made and isn't trusting and respecting the people with the knowledge and skills to get the work done. This is the kind of cultural shift needed to make agility work. If most decisions are made two or three (or more) levels above the team, then agility falls apart. When it comes to successes, it's not about patting yourselves on the back, but about finding ways to repeat those successes again and again in the future.
Standups: Even a "quick morning briefing'" isn't the intent of a standup. It's a planning session. If you have a bunch of people who barely work together, you won't get value from a daily standup. But when you have highly collaborative teams and are planning things like who is going to pair or mob today, what work will be integrated and would be ready for review, what unexpected problems came up, how to account for someone's unplanned time off, or how to plan for someone's upcoming time off, then you're getting value. In some cases, daily is even a bit much. Two or three times a week could work, especially if the team communicates regularly and well outside of this meeting.
Agile coaches: Unfortunately, companies hiring unqualified coaches has turned this role into nothing more than a team secretary or admin. Looking at Lyssa Adkins and Michael Spayd's Agile Coach Competency Framework shows that an effective agile coach needs many skills: lean and agile practice, teaching and mentoring, coaching and facilitating, and mastery in at least one of technical, business/product, or organizational development and transformation. Instead of hiring people who could actually teach and coach their teams and organizations on how to reorganize themselves and apply new practices, they hired people who took a two-day course without any practical experience in a lean or agile organization and who can't teach the people doing the work. Even if you do get someone with the right skills, the organization needs to trust and respect this person and be willing to make the changes needed to support agility.
Sprint / cycle planning: There are many models that emphasize continuous flow. However, it's not so much about the planning but the continuous heartbeat of the entire iteration. Sometimes, it's easier for key stakeholders to interact with the team on a regular, pre-defined cadence. When you establish that interaction, regular planning comes naturally since you want to plan what you'll do between the end of one interaction and the start of the next. If you're getting constant feedback, though, the value of this decreases. I would say that estimation, especially at the unit-of-work level, is unnecessary, and there are plenty of resources on using historical data on work completion to plan upcoming work.
Grooming: No single person can make the right work on their own. Investing a little time from the whole team to review the work and develop a shared understanding greatly reduces the time needed to plan the work. You can also think about many perspectives - what various external stakeholders need or want, the architecture of the system, how you'll verify and validate the work, how to make sure it's deployable and operatable (and monitorable) in production. You'll find ways to reorder the work because doing X before Y will reduce the risk of Y or you'll find that the team needs to prototype and explore. Without some kind of refinement activity, I'm not sure how work can be clearly defined for the team to execute.
Trusting people to do their jobs is the heart of lean and agile methods. But, at the same time, you need structures and patterns to coordinate people, both internally on a team and externally with stakeholders. The problems arise when there is no trust, and people are forced to work in ways that simply aren't appropriate for their context.
Really good and nuanced response, thank you. I'm aware that my original post is a bit facetious and in bad faith.
I think my issue really is that a lot of what you're describing feels like it only works in theory, but my experience in practice is that it never works the way it's meant to because the culture to do it just isn't there. There's always a dickhead CEO. There's always one mobile developer who was shoehorned into the team because they nobody knew where to put them, their work isn't really relevant to anyone else on the team, but they're forced to come to all this ceremony that has no relevance to their work. There's always people who treat it like a status update.
Maybe it can work. I'd be interested to hear from somebody who's practised it and had it work well. But I don't think that place exists.
In practice, the frameworks don't work out of the box. Take Scrum, for example. The framework described today has had all the original technical practices used by the first Scrum Teams stripped out, with no new technical practices added, and it's been generalized to fit many organizations so it's marketable. There are many questions to ask. Why do I need to have a Daily Scrum every day? If I'm mobbing, do I need a Daily Scrum at all? Why a maximum timebox of a month for a Sprint instead of 5 or 6 weeks? What technical practices do I need to deliver software every day or week? All of these are important questions that would likely result in changes.
The culture is the big thing.
I've only worked in very large enterprises, but I've never had to deal with a dickhead CEO because they push decisions down. I haven't even had to deal with a dickhead business unit VP or director. Decisions are actively made 3 or 4 levels below the CEO. That's almost always at the product level, which could be one level up from a team if multiple teams work on a single product. I've also rarely had to deal with people being shoehorned in because we strive to eliminate single points of failure. That means having at least two people with (or working toward) a given skill set, cross-training, and being willing to work outside their comfort zone. People who stay in their niche and don't work with others often don't last long, by their choice.
So, yes. These things can work. I've done it. But it means you can't follow someone else's script or a canned framework and set of tools. It means having a deep understanding of why a framework has made certain choices around roles and events and what to change to build something that works for you. But it's also cultural change in the organization because agile ways of working are inherently different than predictive methods - they need different relationships and inputs and create different outputs.
Super interesting, thanks for sharing your side, I appreciate it a lot.