It really depends on the environment.<p>At one place I was at they were &quot;Agile&quot; and said they utilized &quot;SCRUM&quot; methods, but yet the PM&#x27;s were running dev team meetings and really they were just status meetings that took a dev team of 3-4 people 30-45 minutes to get through, totally not the purpose in my opinion.<p>When I took over a team at that same company, I immediately took over the process and turned the meetings into roughly 10-15 minutes long where we announced roadblocks, issues and what we accomplished and were working on. If needed, we would schedule a separate time to discuss details of specific issues that needed more time.  I still invited the PM&#x27;s  but didn&#x27;t let them ask for status updates on each scheduled task or defect item.  I would instead provide them a status update weekly as made sense, sometimes more often in the case of defects.<p>Personally, I have been part of a lot of environments even as a consultant and seen a lot of varied implementations.  At least from my experience the ones that try to layer it with every possible role, and have separate scrum masters etc just aren&#x27;t as successful.  I personally think they miss the point.  The idea is to remove layers of process to make all teams more effective, not just development.  I have a feeling that the original scrum concepts were perverted by PM consultants and training courses which added back in lots of process and layers to something that is supposed to be lightweight and nimble.<p>IMO the ones I always see the most successful are when a technical lead is running the process, at the dev team level.  And the PM or product owner is interfacing with only the team lead or maybe one person between the team lead and themselves.  This removes unnecessary layers, keeps the dev team focused, and still gives great insight for the business into what is happening and makes the process pretty damn fast.  It does mean that a team lead is not coding as much, they are instead focused on keeping the monkey off the dev teams back, but that is kinda the job role.  In the one place, I was their Chief Software Architect (as a consultant) and I acted as the go between for team leads and the business, which worked well because the team leads stayed more heads down and I could articulate both architecture and schedule issues back to the business.  That was really successful, but a little sole sucking for me.