- May 18, 2010
- Posted by: admin
- Categories: Agile Applications, Agile Project Management, Agile Quality Assurance, Blog, Business Dynamics, Communication, Enterprise Agility, Requirement Analysis, Uncategorized
The simplicity of Scrum. The high visibility. The collaborative approach. 
The frequent delivery of product. All in all, Scrum really did transform the relationship between IT and the business units. And transformed our ability to deliver.
However general agile is more loose ended with less control and prone to unstable delivery and project management. What are your thoughts?
What does that mean for you General Agile?
Scrum is an implementation of Agile.
Agile – a class (in C++ terms). Scrum – an object of the class.
Yes, an object is better because it is real.
Same question: What do you mean General Agile?
In terms of Java, Agile just like an Interface, you need to implement it to use it. Scrum, Kanban, XP, etc are concrete implementations.
Take a look of this page:
http://freecomputerbooks.com/specialAgileBooks.html
Links:
http://freecomputerbooks.com/specialAgileBooks.html
http://freecomputerbooks.com
There is a “general” Agile approach: the one described in Agile Manifesto. And by definition and by experience that is the Agile Development skeleton.
THESE ARE THE PRINCIPLES behind any agile process. Any process that is not conforming to these principles is something else is not Agile Development.
There are some PARTICULAR agile methods like Scrum and XP. These are not complete instances of full agile process! These methods are only fragments! That because each of them does not cover all the areas and all the disciplines from the SDP (software development process).
XP address more the Engineering part of the process and have leaks in PM part. On the other hand, Scrum addresses more the PM part and has missing parts in Engineering.
A FULL process of Agile type shall be a combinations of fragment methods like Scrum and XP and shall respect all the principles from the Agile Manifesto.
When an “agile” process uses the XP and does not use Scrum or something else that shall cover the PM part, that mean is a process with a very poor PM.
When an “agile” process uses the Scrum and does not use XP something else that shall cover the Engineering part, that mean is a process with a many leaks on the Engineering part.
Why “Scrum wins” (stand alone Scrum)? That is happening because it is very easy and comfortable to ignore the Engineering issues and to implement a fragment process instead of full process.
Generally, the SDP is poorly managed and SD is a domain with one of the highest rate of failures.
Scrum wins because it is Living Proof of Agile. Agile wins because it is Agile.
Scrum is not enough – it says so itself.
If you don’t understand this I doubt that your white papers and blogs would be worth reading.
I treat Scrum as any other ‘practice’ in Agile – it does certain things but not others, and it is appropriate in certain contexts but not others. Those last 3 words of that last sentence are very important. Scrum is NOT appropriate in certain contexts, indeed it is not appropriate in the MOST agile of contexts. The main big benefit that Scrum gives us is that it allows us to embed an agile team in a non-agile environment. If the environment IS agile, Scrum would do more harm than good. The isolation of the team that it gives would be a bad thing, not a good thing.
Scrum will bring transparency and show you all the things that are broken with regard to people and process.
Regardless of Scrum or not, some people jump onto Scrum bandwagon without first ensuring their software engineering is up to providing Scrum adoption (e.g. Continuous Integration, testing).
My thoughts are that I’m just reading a sales blurb. Facts and figures please.
Agile is philosophy.
Scrum is religion.
Both can lead to some form of enlightenment, but with philosophy there’s always a risk of not finding your own way, as well as with religion there’s a risk of turning into a mindless follower of some bizzare rules.
Let me quote Shakespeare: There is nothing either good or bad, but thinking makes it so.
It exactly applies to your question.
Whether you’d like to apply General Agile principles from the Manifesto or to use Scrum, it’s just a matter of the applicability in your particular situation. It may depend on the many factors like a nature of the project, corporate culture etc.
In some cases Scrum may bring success, in others it may be a disaster. Experiences project managers should be able to choose what exactly is appropriate for any given case.
Paul Oldfield is right on. (I keep saying that but it’s true.) Scrum is a way to keep the project moving but it says nothing about the nuts and bolts work of getting your code written. Sometimes the right thing is a combination of Scrum (as a team organization technique) and Extreme Programming (as a way to write code on a continuing basis through the day).