[andruby]

That’s exactly why I prefer a more kanban-inspired flow. We discuss new tickets weekly, estimate them with planning poker [0] and move some to “in focus”. We have WIP limits on focus, doing and for-review to limit the max concurrency and encourage pairing.

Product manager and engineers decide together when a feature/project is ready to be launched or when scope needs to be cut or changed.

[0] http://pokershirt.io

[scottlilly]

I'm also a fan of using Kanban for most corporate line-of-business development.

In almost every Scrum team I've worked with, they get close to the end of the iteration and start doing bad things - just to fit their interpretation of Scrum.

At the end of the iteration, they have a unfinished tasks and one of two things happens.

The ScrumMaster/Product Owner/Manager starts berating them for "not being committed to completing tasks within the scrum" (regardless of the fact the task will take as long as it takes, and same SM/PO/Manager has been ignoring the problems mentioned in the daily stand-up).

Or, they mark that task as "complete", but make a new story for the remaining testing/bug fix/additional requirements work. They eventually have to deal with the fact their burndown chart is almost flat, since they're creating a half point of work for every point they close.

They also have people who complete their tasks early, but don't want to bring in another story, because that's "a violation of Scrum". Or they're worried about not being able to complete it by the end of the iteration and going through the previously-mentioned problem.

And no amount of bringing this up in retrospectives will change anything. In the scientific method, if your hypothesis fails in reality, you reject the hypothesis and search for another. In IT project management, when your process fails in reality, most people apparently prefer to reject reality.

Just admit you're doing Kanban and stop causing the problems created by arbitrary deadlines created by your iterations.

[icedchai]

I have seen much of these problems with Scrum, as well. Redefining "complete" so we can book the points, but actually finish it in the next sprint is very, very common. Finishing early, starting on a future story, but the scrum master asking you to not bring that story into the current sprint, in case you don't finish it, is also a frequent occurrence. My view is "if I don't finish it, it rolls over, so who cares", but this is frowned upon since it throws off the reports.

[sharken]

It's the same issue with SAFe, with the added cost of many additional meetings that provide little value.

Redefining "complete" or letting a story roll over, e.g. the estimate for finishing it was wrong, seems to indicate something doesn't work as it should.

Breaking down a project into milestones sounds like a great idea, i totally agree that project management could use an alternative.

[icedchai]

All the overhead that occurs with Scrum / SAFe / Agile in general is absolutely terrible. Daily standups? Sprint planning? Retrospectives? Grooming meetings? Then there are additional, generally agenda-less team meetings on top of it. All these meetings, plus time lost to context switching, etc., probably adds up to 20 or 25% of the time.

[roeles]

One of the more interesting things I recently learnt about Agile (by listening to what Joe Justice did at Telsa was), that reaching the sprint goal appears to boost velocity. Thus, in the long run it's better to under-commit slightly than to over-commit. Sadly, I can't find the source for this easily. It's probably somewhere in the hours of interviews Joe gave which are on YouTube.

[scottlilly]

My gut feeling is that there's still good value in frequent demos/checkpoints/etc. It does create a sense of urgency to complete tasks and lets the owner know that progress is really being made.

Besides undercommitting for the sprint, I've seen a lot of point inflation. Developers start padding their story point estimates to allow for extra time.

The worst case I ever saw was a team of five developers breaking down a feature request into very small stories with total points that would require the whole team's workload for two sprints. I completed all those stories by myself in three days. I'm good, but not that good. I suspect the team was so tired/afraid of being admonished by the Product Owner, they just kept padding and padding their estimates.

Of course, no one bothered to look at the cause of the problem behind the developers massively over-estimating required effort. "The Process" is always right, and the people are always wrong. Isn't that the first principle of the Agile Manifesto (sarcasm intended)?

[roeles]

I think showing evidence of your progress is an effective way to plan more realistically (evidence-based) than the wishful thinking I've seen.

The moment estimates are no longer without consequences you get this kind of behavior. I've done it too, in a place where I personally had to be present in a call with the customer to explain why I went 2 hours over the (someone else's) estimate. Your behavior changes after such a call.

The main point I was trying to get across is that team morale appears to be very important for the velocity. You don't get high morale by stuffing too much work into a sprint or making any single story important.

My main objection with Scrum is that people tend to take the rituals as gospel. Which is why I mentioned Agile rather than Scrum.

[theonething]

Would be great to have job board specializing in companies that do kanban (and are anti-scrum, sprint, etc)

[andruby]

That’s actually a good idea.