I found this fantastic post from Tobias Meyer on the scrumdevelopment mailing list:

"There has been a lot of discussion on this list recently about what Scrum can and can't do, what it does or doesn't do, and how Lean can do things Scrum can't do, and so on. It is starting to feel like meaningless noise.

Scrum doesn't do anything. Nor does Lean. People do things.

In the end it doesn't matter what names you use for your processes, good people will do good work and continuously improve what they do. So much of the discussion around Lean versus Scrum (etc.) is about marketing hype, selling consulting and training services, and cornering the market with new name-brands. It is easy to confuse people new to this list about the nature of Scrum.

Scrum is not a methodology, it is not a process. It is a simple framework underpinned by some common sense principles. Scrum offers individuals and organizations the opportunity to continuously improve the way they work. It provides a space for people to behave like human beings, with trust, respect and passion. That's about it. But that is huge.

Scrum won't save you, it won't fix your organizational dysfunction, and it won't solve your interpersonal problems. Nor will Lean. Nor will XP. Nor will any new brand-name Agile "solution". So get over it -- and more importantly, get on with it. There is work to be done :]"

Comments

[Alllan S. Hansen]

Thanks for posting this post - it sums up my own opinion, and it is nice to see similar opinions existing.
Makes me feel less "weird" when not falling for the hype.

Regards

[Glenn Namian]

I am old school structured, that was re-tooled for object, and enlightened by agile ,,, guess what; Requirements, Designs, Coding, Testing and Deployment are still in fashion ,,, just re-branded. True, iterative approaches are more aligned with development that is not top-down.

The real challenge I face is not so much working with the more current styles, but how to manage expectations with management, who throws "demand" into the IT queue with dates already imposed, and budgets that do not account for adding enough resources to the mix to shrink the end-to-end duration.

In an era where speed to market is the buzz, iterative approaches may make it happen, or kill it out of the chute. If you are fortunate enough to work on a project that is asking you how much it will cost, how long it will take ,,, that lack of constraint is a wonderful thing. Most of us will see that maybe once in a career. But for the grounded, how do we educate our upper management to embrace SCRUM and other agile approaches? Is there a link to that Kool-Aid recipe?

Out

[Tom Hume]

Glenn - I know where you're coming from. Certainly most of our work is done under fixed-price (and frequently fixed-date) contracts. Working iteration and the ability to do rework into this is certainly challenging, usually we go through a typical change request process - which is heavyweight.

It's my experience that whatever the contractual framework you're using, delivering value early on is appreciated by the client (ours tend to). And once they can see software early, they're inclined to (quite reasonably) have good ideas, understand the problem better, and make changes. At this point I think they can start to see the value of being able to inject change into their product all the way through its development - one of the key advantages for them of an iterative process over a top-down.

Doing this with a client who doesn't know you, without the benefit of an existing relationship or trust, is challenging. But in the last year we've started to see companies approach us explicitly wanting exactly this (including some well-known names which you might not expect to be proponents of this kinda of thing).

[blahUscrum]

I am tired of Yip-yapping about process at work. We don't develop software only websites.

Seriously just get to work!