That's it exactly. I don't know why you were modded down. If I could mod you up I would.

That's great for you, as an individual. But as a team you're going to have to compromise as you become as strong as your weakest links. You need to address the overheads of communication and collaboration somehow and Scrum is a good way to start. It's not the end in itself - the communication and collaboration that comes about is - but it is a means to get there.

That's a good place to start, and it's a good approach to resolving the problem technically. Scrum seeks to address the social issues of project collaboration. If you understand your problem domain well enough that you can confidently write that unit-test and your colleagues too, and that the other players outside the team have confidence in your ability to do that, then you're right you have no need for Scrum.

Well aren't you great.

It's not "bullshit" because you have a contrary definition. You say PM, I say potato.

One principle of the daily standup that I always objected to was that they should be "open to all"; that a senior business stakeholder for instance could walk in and "observe" the deliberations (she's not allowed to participate). But to me this undermines the openness and candidness of the discussion. What Glen Greenwald terms a "chilling effect" not unlike somebody coming over to your desk and watching you code over your shoulder. I think that two goals of the standup (1) to improve communication and develop relationships amongst the team and (2) to give any outsiders to the team an insight into deliberations are inherently contradictory.

To me this sounds like "doing it right"

I don't believe that Scrum is something that should be applied rote, it really is all about taking the bits that work for you. If a team doesn't need a forum for deliberating over vague, shifting requirements then they don't need stories and refinement. If they don't have issues with business stakeholder engagement then they don't need a formalised product owner role. If things run smoothly as they are then there's no need for a scrum master. Your team perhaps saw the benefit of more frequent structured discussion so they held on to the standup - but others might see this as an intrusion upon daily routine.

When taken as a whole scrum is intended to solve a whole plethora of operational and business issues around software development. It's good to try the whole lot out for a while to see what works for you but it certainly isn't something that should be forced if it doesn't feel like a good fit.

I had to laugh at your terming the various meetings as "ceremonies"; I would have called them "rituals" or "pageantry". These are typically things one participates in without fully understanding the meaning or purpose but you just follow tradition and through the performance one attains the knowledge. I wish I could remember the sociology terms the process by which one attempts to understand a culture by engaging in their rituals, to get a perspective from the inside.

But anyway, I digress point is, if you gave it a go, and it mostly didn't work, but you kept the bits that did then it sounds like you "did scrum".

Sorry, but I think you are speaking from your own experience there rather than from any wider perspective on the industry. I am glad that you have a tight established enterprise. I really am, but it's not reflective of the trends in the industry as a whole.

Push deadlines. Achieve milestones. Progress timelines. Pick one, but whatever the terminology, no matter what nonsense systems engineering metaphors you use, none of these is a scrum masters responsibility.

By your definitions in a "weak-matrix" organisation, such as a software development team, a scrum master may eat the project managers lunch, though in a "balanced matrix" organisation the project manager is essentially redundant to all intents and purposes for software development as your department head, VP of engineering, whatever may essentially drive a scrum team directly and the team itself assume the remaining responsibilities.

If the project manager plays her cards right then she might still have some purpose as a PA or some kind of high-level admin.

Yes, kind of .. but you take ownership of it yourself.

Ideally though you've never committed to doing more than you're comfortable with - yes the daily standup does institute some "peer pressure" to keep making progress, but that is not necessarily a bad thing.

But again, this is not the scrum master's responsibility. The scrum master may intervene to keep the meeting moving along but he should otherwise be passive regarding content.

I know I know that in reality this might in fact be warped and the scrum master may also wear a business croney cap, but if hats the case it's subverting one of the central principles of scrum. It's something like scrum you're practising, with some similar features, but it's not quite.

But yeah, going by your definition it certainly is loaded term!

Right, but in Scrum much of this belongs to the product owner, who may or may not be a product manager of the variety you describe. Scrum does not prevent you from having such "CAPM" defined roles, however they must fit within the Scrum framework. Otherwise you're not practising scrum ...

Hmmmm - Project Manager is a very broad and loaded term. Many professional project managers wouldn't consider themselves Scrum masters and vice versa. In particular, the role of a project manager is specifically to push timelines, but in Scrum the role of the Scrum master is to guide the process - timelines are owned by the product owner. The distinction is subtle but important enough that it matters.

Cheap warm bodies off-shore are a reality of business these days. You just cant produce the volume of content that constitutes a modern product without it. This is one of the modern realities that legacy scrum just can't address.

No. Agile cannot design your system for you. It dictates the granularity of deliverables and the order in which they are delivered, but the structure of these must still be determined by good engineering leadership and/or architecture. These roles are not obviated by Scrum, they can co-exist quite nicely and these viewpoints should when presented inform the deliberations of the team's story refinement session. If you don't have this, Scrum isn't going to give it to you, and if you implement Scrum as a way to deal with this kind of inadequacy you will still have problems, but at the very least you won't have to wait 6 months to discover it.

I think the biggest weakness of Scrum is it's dependency on having a Scrum master. It just doesn't work unless you have somebody guiding the organisation full time, or a development team who have all been trained together. I've never seen the former, and though I have seen the latter it was at extraordinary expense in terms of training costs and lost productivity in the transition.