John

SCRUM will die and make way for an evolved framework, one that takes the agile values combined with the practicality and quick-start-liness of SCRUM, compared to other agile frameworks; Be it SCRUM-Ban or something else.

Note, that JIT, aka TPS, aka Toyota Production System, evolved between 1948 and 1975. It took 30 odd years for it to become what it is today, and its principles and values are being adopted in various other frameworks.

As you suggest in your piece, SCRUM per-se might die, but it will evolve into other agile software development frameworks.
Waterfall and the likes, however, are doomed to decline and ultimately disappear, much to the delight of enlightened business and technical people alike.

Furthermore, Scrum is called a framework because you have to adapt it to your needs, there is no way around this. If you get no value out of defining tasks, then don’t do it. Maybe try spiking first and then define tasks.
I agree with you that Scrum is not best for maintaining software. Kanban may be a better choice for this activity.

I just want to say that switching to another agile process without getting rid of the root problems won’t help much. If you (or probably more your management) don’t have an agile mindset, then all these methodologies will sooner or later hit a wall.

Very interesting discussions here – thanks
Urs

What you have made me realize, is what I am really addressing, which is that Scrum itself applied, preached and promoted to solve every software problem will die.

The points you bring up about different projects thriving better under difference processes is also very correct and an important statement. That is one of the reasons why I am leaning towards a lightweight framework, like Kanban + XP which talks about core values and a very light set of mandated process, then adding custom process and controls to fit the project.

One of the key problems right now is Scrum is being used as the silver bullet. Everyone is certified Scrum this and that. And people are lying saying it is working, when it is not working. The estimation point you bring up is also valid, but that 20% error margin is just usually not worth the trade-off of 10% of the sprint, and all the other time that goes to doing that kind of planning work (which may end being around 20% overhead.) I think this is a fundamental flaw in Scrum, which can not be easily resolved or dismissed. Again, I point to Kanban as a solution to this, although there are others, where the measurement is a natural part of the process not forced or subject to group think. Average time from start of queue to finish is accurate always, and requires no extra effort.

There is too much to be said on process and using hard fast rules to be said here. I want to address this in another post.

I will read the book you recommended. I am interested to take another look at planning and estimation.

Thanks again for all your comments, very much appreciated. You have some very good insights.

Also, I suspect he’s trying to stop people who want to be “Scrum in name only”. Unfortunately, “we’re agile” has sometimes become an excuse for programmers who don’t think they need any process at all. That usually goes very, very wrong. I’m sure Ken Schwaber is worried that “we’re doing Scrum” will become the same excuse. And yes, if you’re doing “Scrum-but”, you’re not doing Scrum, and you shouldn’t necessarily be able to use that label, which is trademarked and certified and all the rest of it. Perhaps that’s your point.

Meanwhile, back in the real world, no one process is a silver bullet. Would you use the same process to build the life support system in a spacecraft as you would a “Web 2.0″ social media service that you hope will be an overnight success? Of course not. Aspects like risk, budget, cost sensitivity, time-to-market sensitivity and many others mean that the two demand different processes.

Those are two extremes, but it’s not hard to see that these sorts of differences apply even to projects done within a given organisation. The challenge becomes that you can’t just train your managers on one process (sending them on that two-day course) and expect them to make good choices about how to adapt the process. If you have inexperienced managers, then telling them to follow a process to the letter is probably a good idea, and Scrum is not a bad one to follow. Training them on two or three company standards is probably an even better idea.

Once those managers have a few projects under their belts, I bet you they’ll start tweaking because they know that in the context where they work, those tweaks make sense. Forget about what anyone says about process X vs. process Y. Agile more than anything is about delivering value to the customer, not following some prescribed process at the expense of business value.

So back to Scrum: I find velocity, story-based estimates (the two go hand-in-hand) and per-iteration commitment useful tools. I tell my clients they’re about 20% wrong, but that this averages out. I also tell them the true cost if they want me to bring that error margin (both in estmates and tracking) down to, say, 5%. At that point, they normally agree that it’s better to move ahead with the highest priority items, especially since they’re normally a lot less sure they event want the lower-priority ones. That alone makes those tools useful to me. Highly imperfect, but highly useful.

By the way, one of my favourite books on the subject is Mike Cohn’s Agile Estimation and Planning. That’s not a Scrum book, really, but it covers the same ideas (story points, velocity, etc). I think it makes a very compelling case about why these techniques are useful.