> Sprints are about accountability

This, so much. If you're missing sprint deadlines, its not necessarily a personal failure as much as a process failure. The solution is to commit to less, to refine your items of work so they can possibly be met in the time you expect. For this to work though, there has to be buy-in from the team members: you can't force it on them.

I've also found that the somewhat artificial sprint goals do act as a good motivation for the team to help each other if they see that the goals might be missed.

There's also the part where you have to be continuously getting feedback and tweaking the ways in which you run the process based on the feedback. If team members feel that this is just another unresponsive management tool designed to get them to work more, it will fail miserably. Instead, if they see it as a construct to provide accountability to stakeholders, they will strive to change and improve the process until it works well.

Ultimately though, the key feature seems to be: the people. If you're not working with a team that's genuinely interested in accountability and helping the product succeed, this process will not work. These are high-trust, highly nimble processes which are completely inefficient if they are actively sabotaged or the promises of good-faith expectations are violated.

> If you're missing sprint deadlines, its not necessarily a personal failure as much as a process failure.

Is this true? I was watching a talk from James Coplien the other day and he claimed 50%. That seems extreme.

https://www.linkedin.com/pulse/scrum-evening-james-coplien-v...

If a task cannot be completed within the timeline of a sprint, one of two things are true:

1) The task was not correctly estimated; it is discovered during the sprint that more effort than originally thought is needed.

2) Work that was not accounted for during sprint planning reduced your capacity; things like ad-hoc or unplanned meetings, sick time, peer and code reviews, HR processes, bugs from previous sprints, and so forth.

In both cases, the plan that came out of "sprint planning" does not match reality. I don't consider this to be a failure at all. How people react to it can be wrong, however. "Just get it done anyway", failing to inform team leads / managers when the change occurs, etc are unhealthy, because it creates a disconnect in expectations among the team due to either conflicting understanding of the work being done, or changes in expectations about capacity required.

The 50% is simple math. If your velocity is V, you take V estimation points of work into the Sprint. V is a stochastic variable with a mean and a variance. You rarely deliver exactly V points: it is just the mean. About half the Sprints finish early, and about half the Sprints don't deliver everything on the Sprint backlog.

So this isn't about failure at all: a failed Sprint is one that fails to meet the Sprint goal. I suggest taking a Scrum class to learn how velocity works, how agile works, and to learn how to manage uncertainty (and if you don't admit to this 50% uncertainty, then you are lying to yourself and cooking the books) and to learn about Sprint Goals.

Your post suggests that you understand none of these things. They are all Scrum basics.

> management's expectations are simultaneously deadline, cost and feature driven. There is no management technique

I suppose when the product you're making is, say, advertisements, because you merely arbitrage, you can satisfy all of those at the same time.

The more interesting point of view is, "The kinds of software businesses you want to get into require no management at all."

It is entirely reasonable for management to set an expectation for two of the three between deadline, cost and features. The whole point of agile, as I understand it from "Uncle Bob", is that as professionals, developers are expected to provide information and guidance based on their professional opinion. Not only does agile help ensure accountability, but also acts as a continuous feedback cycle for developers to provide new context, information, and ideas as they surface.

I did in fact work at a company that was something of a dev shop for marketing agencies, and it was pretty miserable at times, because they inevitably expected contracts that held to all three. Cost was typically the one thing we could get them to budge on as new information came up (i.e. this necessary feature wasn't accounted for) though who actually ate the cost depended on negotiations.

I don't think I would enjoy working in a business with no management at all, to be honest. There are things that I am good at, and there is a definite perspective from which I view things, and the same applies to good managers, and there is not a complete overlap between the two. On top of that, they deal with problems that, often as not, I'd rather not have to worry about.

> "The kinds of software businesses you want to get into require no management at all."

Nice work if you can get it.