What is Scrum & what does a Scrum Master do

Intro.
The Scrum process is anchored by the following standard fundamental elements; a backlog list, the team, owner, stand up, planning sessions, and retrospect. The Scrum Master role is to ensure all elements are functioning together properly, eliminating obstacles and tackling any unknowns head on. In addition to that, the Scrum Master will track the velocity (Burn down chart) within the iteration, capacity per iteration, capacity per person, and ensuring that the project and company requirements are met.

Scrum Project Charter (If needed)
For any new project, if a company calls for a charter, then the key elements will need to be identified by the Scrum Master, Owner and Team. The breakdown can be defined as such: Description (by Owner), Business Justification (by Owner), High level Project Requirements/Epics(by Owner, team and Scrum Master), Backlog (only if possible early in this stage by the Owner, team and Scrum Master), Risks (By the Owner and Scrum Master), Assumptions (By the Owner and Scrum Master) and Constraints (By the Owner and Scrum Master).

Project Initiation, Epic and User Story
The process is initiated by identifying the different areas in the system (Epics) and prioritizing them. This work is done by the Scrum Master, Owner(s) and team. In an ideal Scrum environment, a single role “Owner” will be designated for such a function, however in many companies, one must rely on many owners. For every Epic, a set of user stories are identified and created by the owner(s) and analysts. Each user story follows the standard format; “As a I would like/want to so that ”. Each user story will be estimated and added to the backlog list. This list must be visible to all parties in the team and stakeholders to ensure transparency. In addition to this, it is important to identify and make known the definition of when an item/task is "Done". "Done" is defined differently between companies and as you read further when an item will be defined "Done" will be clearer. In all cases an item is "Done" when  it is "Shippable"  or "ready for live system".

Iteration Initiation
At the start of any “iteration”, the Scrum Master schedules a planning session to go through each item with the team. The items are selected based on priority and ordered properly within the iteration. The sum of the estimates for the items selected for the iteration would equate to the calculated team’s capacity. Capacities are always adjusted to take into account how many points are spent on non-project related tasks.

Stand up
Throughout an iteration, everyday there is a daily stand-up. Each person will come ready to this time-boxed meeting with “What I did yesterday”, “what I will do today”, and “Obstacles in my way”. The Scrum Master role is to clear obstacles raised and keep velocities updated.

Functional Testing and Demo/Presentation
As a set of items are finished for the owner(s) and they have passed unit and functional testing, the changes will be presented with an opportunity for adjustment upon request. Negotiating as to what and if a change is possible in the present iteration based on that meeting is one of the Scrum Master's responsibilities.

Testing and Definition of "Done"
Some companies define "Done" when the user story has passed both functional testing and the owner presentation. Once all changes for the iteration passes through all testing environments, if a company applies manual or automated regression testing, then some of those companies define an item as "Done" once these tests pass. Many smaller companies would be ready to deploy the changes to a live system at this point. Larger companies tend to follow through user acceptance testing on a pre-production environment. Some such companies may define "Done" before the UAT others only after. For some companies with smaller teams who apply UAT, all members in the scrum team would be involved in UAT. In such cases it merits to define "Done" when the UAT is complete. For larger companies who have a scrum and UAT team, this is where the scrum team would start a new iteration. In all cases regardless of who is doing the Regression and UAT, any new item or defect discovered after the item(s) are set as "Done" will placed into the backlog list and re-prioritized accordingly.

Retrospect
At the end of every iteration, a retrospect meeting is initiated. Each team member will come to the meeting with three topics; “what went well”, “what did not go well”, and “how we can improve on what didn’t go well”. This will be a driver for the Scrum Master to improve every iteration to continuously advance the efficiency and quality of the team and system.

'me rant' about the Software/hardware and Business people

This is 'me rant' about the Software/hardware and Business people relationship (from a narrow perspective)

Software/Hardware engineers are event driven. They are the beloved folks that make things out of nothing... well.. with the help of IntelliSense (for us lazy ppl), almost out of nothing... They are always focused at the task at hand and not so much on the time. Every now and then the humble (some ain't so much) PM/SrumMaster/Product Owner would venture out of the hole (i.e. fancy office) to check up on the work being done and understand and clear obstacles where needed.

Then you have the other side. Business people. They are time driven. We all love them.. (sorta). After all, they have the all mighty dollar! They want things done now, noW, nOW, NOW! they are always focused at the task at large and not so much on the gritty details. They are focused on time. Similarly, the humble PM/SrumMaster/Product Owner would undertake the perilous journey (thank you thesaurus) and interact with them to identify and help everyone keep what needs to be done simple and organized (Dont quote this you Masters of Scrum)

So what is the best way to bride those two groups??? Meet "Super wo/men" aka "Product owner" and ScrumMaster (Dah, I already mentioned them twice). Lets start with the owner. So what is this hero's role. Well in simple terms, organizing  what is important and what is not (i.e. backlog/Task List). That it. nothing to it. right?.... WRONG!!!. Just imagine how many opinions the poor sucker ... I mean ... person will have to go through. This person understands and gets what the business needs and wants. And all this need to be passed along to the development team, they give the magic estimate, and runs back to the business folks with "Ok, so now I can do this, that and those, but these, have to be left to next 2 weeks" ... "and oh, here, I got you cupcakes and muffins" and then run away (As if muffins and cupcakes go together... heresy I say!!)

You have all this while the other hero ScrumMaster is running around and duct taping every problem. (Duct tap is awesome....) For every problem there is a solution. This person will have to be able to pickup the pieces of every disaster and make it into a 'bump on the road', in or out of the iteration.

So where does that bring this conversion to... not sure.. everyone is needed. There are no real heroes. you remove one role and the whole things goes back to old school chaos. So I'm going to just going to end it n..n...now.

(I love Duct tap)

How Scrum handles the case when you have 1 scrum master and 1 product owner and 3 teams working in the same product? each team consists of 6 members.

To Answer this question for simplicity, I will assume that we all know how "scrum" in a single team works, and I will assume we will have two teams of 6 rather than 3 to simplify my explanation. This same approach will apply to any number of teams (Proof by induction Anyone? :) )

* In my opinion, a rule of thumb is to make sure that no scrum team is larger than 6 +/- So If you have multiple teams that can be combined into one team of 6 +/- 1, then I would make it one team. Otherwise I would apply "Scrum of Scrums".

* In "Scrum of Scrums", each scrum team has one representative who is most knowledgeable in what everyone is doing in the scrum team.

* The Product Owner will have to have setup two backlog list for the different scrum teams. ( if not, then go based on Epics/themes)

* Each team will have its own iteration planning with the Product Owner going through the remaining items in the backlog list in priority. (so the meeting times need to be adjusted accordingly).

* After the iteration planning, the representatives will have a secondary iteration planing (much shorter) answering the following:
(1)"what we will be working on",
(2)"Any Issues we foresee in our way", and finally
(3)"How do you foresee that our changes will impact you?".
This way each team will know what the other team is working on.

* Daily, each team will have its own stand up meeting. Usually in a stand-up each individual will state
(1)"what I have worked on",
(2)"what I will be working on",
(3)"Any Issues in my way".

* Daily, after both stand ups for each scrum team, the representatives will have a "Scrum of Scrums" stand up meeting. The value I will focus on in this stand up is the "Impact" of a change. The biggest hurdle you will have in a team working on a single product will be the impact of one team making changes that will affect another. In the "Scrum of Scrums" stand-up, there is a bit of a twist to those three questions and a fourth; and they would be
(1)"what have WE worked on",
(2)"what WE will be working on",
(3)"Any Issues in OUR way", and finally
(4)"How will our changes impact you".
The last question will drive the conversation between the representatives on how the changes will affect each other.

Has anyone used Agile for ERP type projects or with large projects? Any suggestion or inputs are welcome

Yes it can be done. Some pointers (there can be much more)

* You are bound by requirements, audit policies, company policies info, ... etc. so each iteration will need to accommodate for such information. so your estimates need to account for all that are to be done.

* communications. not to enforce it, but rather to facilitate it. If you need to move people to improve this, then do so. if you want a collaboration tool, then get it ( you can use something like SharePoint or Microsoft Access ... etc) . I have dedicated the stand up room to be a place where people will go and talk out solutions to problems.

* stand up, and story board. I cannot stress how valuable these were. anyone lost is back on track just by being in a stand up facing a story board.

* If you have a large team, then apply the "scrum of scrums" concept. keep each scrum team no more than 5 or 6 members. The more people you have, the less communication.

* teach members about scrum.

* keep iterations short. and make it a policy to be ready for live at the end of it.

* focus on quality. this means include unit testing, automated testing, test scripts, manual testing, code review, test script review... etc.

* Last but not least; have a retrospective meeting at the end of each iteration; this will allow the team to reflect back on the it.

Tension within the team. Does anyone have any recommendations on how to handle personal tensions within a team?

A ScrumMaster (SM) is a facilitator and an example for a scrum team. Based on this premise, below are some ideas that might help.

1- If people in the group are in disagreement/tension, then let them work it out.

2- If they are not working it out, then create the right environment to work it out. have the stand-up room available for people to talk things through. If they want more privacy, then they close the door and talk it out.

3- If there is still an issue, then be the mediator. The SM's job is to "clear hurdles" for individuals in a scrum team, not just watch them deal with it. To clear this hurdle, you have to act as a mediator. No need to bring a third party unless you as the SM are in tension with others (but as an SM, I would really hope not). In my opinion, the more people you involve in a tense situation, the more complicated it will be and harder to resolve.

4- Be an example to everyone. As painful as it seems, be the most patient person ever when dealing with such a problem.

5- The best way to avoid tension is to anticipate it. And how do you anticipate it? By getting feedback from the team. I am THE BIGGEST FAN of the retrospective meeting. This 45 min every iteration meeting is a key to relief people stresses in future iterations. Less stresses for individuals in a team will make them happier in the team which makes them more patient and thus less tension. Of course, as a SM I would expect you to follow through in making and/or allowing the proper changes based on the retrospective.

6- Smile, and crack a jock every once in a while (even if you are bad at it), people who are more skilled at jokes will get the courage to do so later on.

1, 2, 3 are for specific individuals in disagreement
4, 5, 6, are for the team and future "way" to reduce tension in general

In regards to the original question, to reduce tension in the team as a whole, I would start off with the retrospective. To reduce tension between specific individuals in the team, then I would apply 1, 2, then 3