I have been working in managers who were technical earlier in their career and now they manage and guide the team. However now I have come across a manager who will be acting as our scrum master and also as our project manager. He is totally non technical person.What is the reason to have non technical project managers or non technical scrum masters instead of technical ? Also, how should the daily interactions with non technical managers or non technical scrum masters be like ?
Neither project mgmt nor scrum mgmt is inherently technical. While an understanding of the technical issues involved would of course be helpful (and will come to him over time, I'm sure), they're not required. I think it can be helpful to have someone who has no preconceived notions of "how things should be done"; such a person can bring a fresh perspective, and could act in a neutral fashion in any technical disagreements.
I don't know that the interactions would be any different. Obviously, you'd have to explain technical stuff more frequently to such a person.
Scrum Master is a coaching role. As long as the PM or SM can understand what is going on at a high level, it seems fine. Some projects are more technical than others. A non-technical PM or SM would probably do better on some projects than others. Just because some vocabulary is so technical it would require training to follow the standup.
Also, remember that projects don't have to be technical. For example, moving an office from one building to another is a project. And requires a project manager!
My understanding is that for technical projects, a good PM or Scrum master is the one who can get the team to complete the work faster and with good quality and that he would be able to get work complete faster with good quality if he has some technical idea of how they are doing it as compared to when he does not have technical idea of that.
Typical misconception of the scrum master role. Scrum master, as Jeanne mentioned, is partly a coaching role. They coach people on how best to collaborate and organize. There's a bit of irony there because agile teams are supposed to be self-organizing. In reality, there have been very few, if any, teams I have come across that are truly self-organizing. Most teams need help in not only their structure and communication but in their engineering practices as well. It is not the Scrum Master's job to get things done; it's the whole team's job. A good SM inculcates that idea on their teams. With collective ownership comes collective responsibility.
In reality, upper management often looks for that one neck to wring. This again is an anti-agile mindset that rolls downhill. So you get these anti-agile ideas that it's the SM's responsibility to crack the whip and keep developers in line. Bad, bad, bad.
A true SM protects their team from outside pressures. They coach their teams on how to organize. They protect the process and keep the work being done aligned to the process boundaries and parameters. If they are non-technical, they find a good technical coach for the team. The SM is a problem solver. They help the team deal with impediments, like upper management bugging for "just this one little feature" or pressuring to meet some arbitrary deadline. The SM is not a PM. That is another anti-pattern if they behave like one.
The best ideas are the crazy ones. If you have a crazy idea and it works, it's really valuable.—Kent Beck