As a I would like to so that

A user-story breakdown is as follows:

• As a <user> I would like to <do some function> so that <reason/value>

A common mistake when writing user-stories is that in the section where we specify the <user>, the author of the story specifies the owner/requester of the change instead of a system user. 

A user story is meant to bridge the business and the system/code. This means that the <user> has to be a tangible entity understood from a business perspective as well as from a development stand point.

When a business member reads "As a <user>", he/she may understand this as the "person who is using the system", while the developer is reading it as "the user with type T with permission XYZ". Both are correct. Both have a different view of what a <user> is, but most importantly both are talking about the same user and again.... both are correct!

I Love simple software.

So I was bored today and decided to play around with factorials on Google (Yes, don't make fun. Factorials are exciting, They are the epitome of exclamation marks! ) and to my surprise, a calculator now loads when you enter a formula on the search bar. Try entering "5!".

I know I know, It's just a calculator, but the exciting thing about all this is the simplicity of the idea and how such a simple idea can be so functional, practical, and powerful.

This brings me to software UI, Functionality, behavioral and problem solving simplicity in general. I recall one of my professors in university always saying "The simplest solution is probably the correct one".  How true this is back then when working on my assignment as it is today working on company projects. I rely on this statement in my day to day work, and so far, it never failed me. 

Expanding this further to the outside world, some of the most successful software ever built, some comparatively speaking, are focused on being simple for end users and simple for the developers to maintain.

In my opinion, some of the simplest software interfaces/tools/systems that I can think of are:

• I give you: Microsoft Calculator - Simple interface/Tool- If you ever owned a Windows OS, even the 1st BETA version, you have used it. If you didn't, odds are that you did without you realizing it. If you still say you haven't used it, I say you're a liar. If you are a holy person and don't lie, I say get out of your cocoon, open Run > Calc and play around with it. The idea behind it is simple to the point where you know how to use it without thinking about it. I cannot talk about how this was implemented, but given that it has been around for ages without it being changed in windows 95 to XP, to me, this implies that there is some form of simplicity, extensibility, and maintainability in the design. 

• Google search box- Simple interface - A single magical text field; enter what you need, and a result set is displayed. Again, the idea behind the usage is simple to the point where you know how to use it without thinking about it. If you ever notice Google applications in general, they revolve around being as simple, and as least "UI crowded" as possible. What does this imply? Simple UI, Simple Forms, and proper division/inheritance/decoupling of the code in the background.

• The LIKE link/button on social media sites - Simple interface/system - So simple to the users, with immense power to the companies who store and analyze what is liked and what is not. Many of the advisement you are bombarded with these days are a result of your 'likes'.

• The US air-force F22 Fighter jet - Simple interface, comparatively speaking -  ( please don't quote me on this) I was looking online on WIKI and it was explained that the interface for the jet was so functional and simple compared to older aircrafts, that anyone with basic military fighter jet training can fly it. ( Again, I have no references to back this up anywhere, so if this is false, then it's false)

• Last but not least, ScrumQueue. - Simple interfaces/tool/systems - I was so fed up with how complex project management software in the world out there to the point where I literary created one myself with simplicity in mind. I use it for any project I work on. The objective: manage my backlog of items with a simple status and history logging. I don't need fancy colors/etc. I use it and never looked back. Of course, I am always tinkering with it to advance it with new features, but always with simplicity in mind. This is my salesman pitch :-)

IMPORTANT: Simplicity does not mean Lack of Progress, 

It means Smart Progress

And here is a screen shot of the magical calculator that enlightened me to write the above.

I have 6 departments, each with applications to maintain, and 4 developers. How do handle this in scrum?

You already know the root of the problem. Work your way from there...

1- Get the products owners (PO)/business...and let them know the situation.
2- With the POs, divide the departments into two backlog lists. Group them in a way so that the dept. that are most related to each other are bunched up. So now you have 2 backlogs.
3- POs will then re-prioritize based on what is best for the business as one entity and not on what is best for the department.
4- Divide the team. 2 devs and 2.5 devs, each will take care of one backlog.
5- If the two teams need to still know what the others do, apply scrum or scrums.

Just by doing that, you will improve the quality because devs will have a smaller scope to focus on.

Should technical work (non-code. Example: setting up servers, DBs, Hardware.. etc) be added as a user story to a backlog?

Short Answer; Yes

Long Answer;
A user story has 3 parts: As a [user/actor] I would like to [Action] so that [reason/value]

Whenever you make a decision, whether technical or not, you need to consider "why" we are doing what we are doing. Thus the last part of the user story has very high value to the owner. Example. why should we upgrade the server version from X to X+1. Another, Why should we increase the hard drive space from X GB to Y GB? It could be to support a new feature that will require lots of data storage or new DLLs from some server version, or lots of transactional audit data... etc. These points help put on paper in clear and concise way why we are doing a change

If you recall in scrum, during the iteration planning, we need to estimate how much effort is needed for a task. We estimate using points. Based on that you can estimate a task it takes to complete a technical or non-technical task. Remember, in scrum you estimate the effort to complete a task in full in accordance to your organization. Thus documentation, audit needs, any task required by your company would have to be considered during the iteration planning. So Hardware is a part of that. To estimate, you will need to look at the i.e. what is it that needs to be done.

Last, if you recall when working on a user story, the aim is to make it measurable. Thus you could end up with multiple stories to complete and epic story. Example: Epic. Build a server for Web application X. The stories title could be: Install OS, Install IIS or Apache, configure Ports, install DB server, Configure DB... etc. You see that you can take each of those and write a simple user story. In each case capturing a small piece of what needs to be done, and as mentioned above, capturing why we are doing it.

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