For those of you who are not very clear of what Scrum is and what it is not, here is what I was given to understand of what Scrum is, by a CST on this forum. I am taking this at face value pending its endorsement by the official big wigs in the Scrum Alliance.
--------------------
I do not believe that the Scrum Alliance is under the umbrella of the
Agile Alliance. Many members of the Scrum Alliance are members of the
Agile Alliance, of course, but it would be incorrect to say that scrum,
itself, as a process for Agile Software Development. As Ken has pointed
out, one of the major scrum teams mentioned in the "Enterprise and
Scrum" book (the transition team) does not have software as a product.
Of course, most of us see scrum as a good process for Agile Software
Development, but it is not only for that. The Scrum Alliance defines
"Scrum: A team-based framework to develop complex systems and products."
right on the front page.
Dan Rawsthorne, PhD, CST
Senior Coach, Danube Technologies
dan@danube.com, 425-269-8628
So far everyone in the Agile Community have been adopting Scrum as an Agile Software Development methodology within the ambit of Agile Values and Principles. What we are now learning implies that "Scrum can also be used in Agile Software Development while it was never designed exclusively for Agile Software Development"
I recall a blog of mine titled "Scrum in not Agile" more thant 2 years ago that was frowned upon by the Agile guys ( http://scrumtales.blogspot. com/ :19th March 2007 ) Now it looks like afterall it was not so much out of the context.
With this, as a veteran member of the Agile Community I feel that the Scrum Alliance, for the sake of their own credibility, should clearly communicate this to their potential audience and may need to clearly spell out different approaches for implementing Scrum in the following varied contexts.
1. Scrum for Agile Software Development (as in xp@Scrum)
2. Scrum for Agile Product Development (as suggessted in Ken's book on it)
3. Scrum for the Product Production Industry (sequential process or waterfall - as in manufacturing and construction industry) in line with what we are planning for FScrum
4. Scrum for Research and Development (as in Jim's Adaptive Systems Development)
5. Scrum for the Creative Industry (Advertising, Hollywood and other industry involved in Commercial Arts) that engages a true iterative empirical approach.
6. Scrum for PM BOK ( I know of this initiative by the Scrum Alliance to co-opt Scrum with PMI, IPMA and other project management associations worldwide )
Agile Alliance. Many members of the Scrum Alliance are members of the
Agile Alliance, of course, but it would be incorrect to say that scrum,
itself, as a process for Agile Software Development. As Ken has pointed
out, one of the major scrum teams mentioned in the "Enterprise and
Scrum" book (the transition team) does not have software as a product.
Of course, most of us see scrum as a good process for Agile Software
Development, but it is not only for that. The Scrum Alliance defines
"Scrum: A team-based framework to develop complex systems and products."
right on the front page.
Dan Rawsthorne, PhD, CST
Senior Coach, Danube Technologies
dan@danube.com, 425-269-8628
------------------------------------------------------------------------------------
Based on this, I am now very clear on many of the aspects of Scrum implementation as an Agile Software Development Methodology, in software development environments.
I recall a blog of mine titled "Scrum in not Agile" more thant 2 years ago that was frowned upon by the Agile guys ( http://scrumtales.
With this, as a veteran member of the Agile Community I feel that the Scrum Alliance, for the sake of their own credibility, should clearly communicate this to their potential audience and may need to clearly spell out different approaches for implementing Scrum in the following varied contexts.
This also reinfornces my belief that we need to have separate versions of Scrum for the following contexts. Using a single generic approach in the practice of Scrum in all contexts may spell disaster.
1. Scrum for Agile Software Development (as in xp@Scrum)
2. Scrum for Agile Product Development (as suggessted in Ken's book on it)
3. Scrum for the Product Production Industry (sequential process or waterfall - as in manufacturing and construction industry) in line with what we are planning for FScrum
4. Scrum for Research and Development (as in Jim's Adaptive Systems Development)
5. Scrum for the Creative Industry (Advertising, Hollywood and other industry involved in Commercial Arts) that engages a true iterative empirical approach.
6. Scrum for PM BOK ( I know of this initiative by the Scrum Alliance to co-opt Scrum with PMI, IPMA and other project management associations worldwide )
This further reinforces my belief that working to develop an FScrum - a version of Scrum for the waterfall types, may not be invain.
I am aware that Scrum was created to be truly "ADAPTIVE" and it reflects in the evolving "Values and Principles" of the Scrum Community, who have been "EVOLVING" Scrum in line with changing market and economic considerations, over the years, for the benefit of all.
Hi Kripaji,
ReplyDeleteIn my experience, i have found that the fallback to waterfall by team members and PMs is as natural and inevitable as a "switch...case without a break..."!
So, my observation is that there is really no need for a FScrum or anything - the reason being that once exhausted with their efforts to implement (which itself is a wrong approach towards Agile) Scrum as an Agile method, teams fall back into their comfort zones, which is naturally waterfall, without any hitch! And, not just cursing Agile for its fallacies, they even start admonishing anybody doing Agile the right way as blind fools!!
I believe (i think even you do) that Scrum is closest to the boundary separating tradional, process based methods from non-traditional semi-or-no-process based software development methods. Therefore, the fallback into comfort zones does not hurt the teams at all because they were always partially or fully dependant on processes and policies to bail them through when the project runs into deep waters!