'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)

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.

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.