Separation of Concerns Principle

This principle states that a given problem involves different kinds of concerns, which should be identified and separated to cope with complexity, and to achieve the required engineering quality factors such as robustness, adaptability, maintainability, and reusability. The principle can be applied in various ways and it is no exaggeration to state that the separation of concerns principle is an ubiquitous software engineering principle.
From the Aspect Oriented Software Architecture Design Portal . They define the term Concern as ,
Concern:A canonical solution abstraction that is relevant for a given problem.

More : http://trese.cs.utwente.nl/taosad/separation_of_concerns.htm

"Don't call us, we'll call you".

I am in a very good mood to tell some theories today...
I went for a long drive, had nice dinner and now back in home....
Computer is not calling me today....Time for action (sleep)!...) Let it control me today, I used to control it most of the time.... (Is that called as IoC ? )
IoC is about inverting the control between objects. Thus, for example, rather than object A controlling object B, object B might be passed to A, such that it appears that the control is the other way up - i.e. inverted.
Miles to go before I sleep....

My The Scrum Master is My Business Analyst!

I recall i worked for a company they used to say "Customer First"... (Everyone does right?).

What if My Busniess Analyst/ My Business Manager became my Scrum Master and you are just one of the pigs!.... Good enough.. right??
What if you are just a chicken in the whole process? I can see three possible answers,
1. Are you just the part of the process (not the heart?? Are you Contracting for a Non -IT firm??)
2. Are you just do Agile?? ( This create a big impact!....)
3. What about other pigs .
Atleast one of my readers must ask... Are you in a wrong team/wrong environment?? Get the hell out of there!....