Don't Use Scrum

Why this recession?
Please come up with actual problem?
Suggestions to improve

I like your article, but a few observations -
Newton's "theories" are know as Newton's LAWS of motion - they hold immutable in every way unless we are speaking about sub microscopic particles or light itself.
As a parallel, Scrum is a VERY robust tool that addresses many nuances (including human nature) in a process that insists on maintaining itself as a craft (software development).
No tool, however, replaces good leadership AND common sense!!

You're absolutely right... People get so hung up on methodology they forget common sense during product development. I've been through Waterfall projects, RUP projects, Summit projects and (lately) Scrum projects. Thankfully my current team understands the need for applying common sense to implementations and we've been able to tailor Scrum to suit the needs of our organization.

-MJT

i particularly like the title and the ~logical~ case made, arguably writhe with personal perspectives rather than facts. it is rather interesting and factually on spot in terms of the cyclical new ushering out the old and the dogmatic practitioners of the old way surviving with clenched fist. onward... >>>

"So the question is: does Scrum (or any other agile method) still work now?" You say "mostly...but in some scenarios"; I'd say always in the same scenarios. Problem is scenarios are never the same. i think "business" understands that... i think a "consultants" knowledge and expertise is their trade... when sought out by a business to guide them, it should be done so by the "consultant" with pride and professionalism.

in the case of scrum... if scrum is the sought after solution for change, how is a "consultant" able to "recommend" the use or removal of any of the prescribed practice without the context for which the practice does or does not work? if scrum is the sought after solution for a project that is out of context for its practices to succeed, then pass on the scrum solution. surely there are an arsenal of solutions available to "rise a sinking ship". just don't provide a "patchwork" solution that "might" work, call it agile'ish, and leave the "business" struggling to figure out why it feels the same pains they've always felt.

the better question could have been: what is the appropriate solution for a must-have fixed-fee client?

I agree Common Sense is also important, but commons sense has to be updated too...
Common Sense 2.0
Common Sense 3.0
and so on...

Nice way to set up a strawman on an agile development website (e.g. "Don't use scrum").

Everything on the web about scrum always ends up with: "Analyze your process environment and see if Scrum works." Yet, I wonder why folks aren't just listing out success stories like the old waterfall ("hey waterfall was used to build F-18 jet and NASDAQ") and spiral/UP days ("hey spiral was used to build Amazon and the Boeing 747"). Why? cause agile projects have no EOL (end of life). The backlog is a concept to keep projects going, even if the customer ends the project, it will still have a backlog--it's never "done" and the domain knowledge stays with that team and only that team. That's great for that team of developers, period. +1 to scrum!

S/W developers have learned that getting quality, full featured, robust, scalable systems is NOT mutually exclusive with getting a working system within a month to, cough, make huge ROI over the long term. There's too many choices.

And for example, where has NASA's famous saying: 'better, faster, cheaper' gotten us? More failed missions (the 2 Mars robots are the exception) and a Space Shuttle Columbia (RIP). And projects there for some reason take the same amount of time still...

The thing is scrum itself, though advertised as a methodology, is not a methodology. And the term agile is just the new buzz word for iterative (from the developer point of view). Basically in sprial/UP, customers were allowed to change requirements, teams had no real say. In Agile/Scrum, that power is now laid upon the team (customers can only "negotiate") and the responsibility is now spread out (really no one's at fault).

Common sense, hero coding as it is mentioned in a earlier post, DOES WORK in 98% of all projects (Linux back in 1990, and even upto today is a perfect example). Just that the time risk is higher--which is greatly effected by inexperience developers.

A lot of these methodologies do not have a 'place'. They are just reminders to developers that: a. communication is important, b. quick consensus is a helper to gain domain experience fast, c. iteration is a trade off for flexibility, d. make sure YOU know the customer's expectations and make sure they know your capabilities, and e. you and your customer have a relationship, cultivating it for a win-win does have its benefits than just turning a quick buck.

As for Scrum, it reminds us of those aspects, but putting it into a methodology ends up enhancing the human factor (and job security) at the expense of cost efficiency, design/documentation, scalability, repeatability and robustness.

Sorry for the long outdated post, but had to say it...

> Microsoft Windows 7 has been developed using Scrum. Atlassian JIRA and Confluence have been developed using Scrum. Are these trivially small projects?
Can you verify any of this? Making random statements like this is similar to me saying that Empire State building was built using Scrum.

> Frankly, your argument is without merit.
And yours is better how?

> As to "System Engineering" - my past experience suggests that vast majority of system engineers are overpaid, underskilled bunch of individuals with overblown egos and totally out of touch with reality. The skill they _do_ possess is drawing pretty powerpoint slideware and UML diagrams - I think I am going to pass on these and leave them to management

I think you have an extremely narrow experience. Most system engineers I know can code as well as design high level architectures and express them using UML.
UML is a communication tool that allows you to express your design before committing to a specific programming language. If you can't draw a simple diagram to illustrate your dog house, how can I trust you to build it?

If I may, I'd like to add to a few items in this discussion.

This article does show many misunderstandings about Scrum and what it is. Also, there are good points that I would recommend to teams using Scrum.

Scrum isn't a methodology, it's a framework for managing work in a complex environment. Waterfall is a framework (as a concept, which is different from the methodologies like RUP), too, for managing work in predictable domain (such as the example of building a 65-story skyscraper). Thus, it does not make sense to use Scrum in planning and building a house (at least from engineering point of view), and it doesn't make sense to use waterfall in software engineering. The fact that people manage to get large projects done with waterfall approach isn't a testament that waterfall works, but a testament to the skill of the people that they've managed the work despite using a process that is not suitable for the work. Props for those people.

Unfortunately this article doesn't differentiate the process control model from applying it to practice. Scrum as a process is fundamentally suitable, but it cannot be used the same way in every environment. And _that's_ exactly the point. Continuous refinement of the actual development process is the key; you achieve that within Scrum. That is why (one reason, anyway) Scrum doesn't pretend to be a methodology and tell you how to create software (if you need that, check XP). It merely helps you to manage such work. It will reveal the problems in the current system and it's up to you to solve them or not solve them (the latter will prevent you from realizing the full potential of your organization).

Regarding common sense and Scrum, every Scrum coach should be the first one to bring up the need for it. So why would they (or anyone for that matter) then starting the use of Scrum "by the book"? The suggestion is based on experience. Too many people look at Scrum, pick a piece from here and there, and "improve" Scrum by including waterfall elements where the Scrum process doesn't "make sense to them". Thus they end up trying something that isn't Scrum and doesn't probably have much chance of success (and which may very likely be worse than their previous process). And then they blame Scrum for not working. Doh!

But you don't have to use Scrum to be Agile (there are other frameworks as well). And Scrum isn't enough; you have to take advice from other sources as well (like XP or Lean Software Development) to complement what Scrum is purposefully leaving out.

Unfortunately, transition from traditional approach to Scrum is about in the same magnitude (as a change effort) as moving from cowboy coding to traditional approach. It starts with "getting it", and without that insight, it's nigh impossible to apply the new approach to the environment. This is why it is so difficult for many to adopt Agility and why there are no silver bullets on the way.

Wishing everyone good summer and loads of common sense,

Petri