How can I have project planning for the systems administration area? [closed]

a lot people are trying to adopt agile software development principles to system administration. and there has been more written about than i can tell you here. i will mention some resources later on, but first some hints:

• get to know what your sysadmins do. (as all the other already stated)
• don't push changes to your sysadmin, not all principles will work in every company.
• ask your sysadmin whether they already have ideas for improvements.
• do you have enough admins, so some can only work on projects for some time? (normally not the cast, but perhaps you are lucky)
• don't try to introduce all agile principles at once. start small and let your sysadmin get used to the new principles.

here are the mentioned resources:

• agile system administration blogs and newsgroup:
  • http://www.agileweboperations.com/
  • http://agilesysadmin.net/
  • http://groups.google.de/group/agile-system-administration
• another "movement" which tries to bring developer and sysadmin closer: devops
  • http://www.devopsdays.org/
  • just search google for devops
• kanban and scrum for sysadmins: http://www.infoq.com/minibooks/kanban-scrum-minibook
  it is a comparison of scrum against a lean principle developed by toyota

Can you be a bit more specific about the areas you're going to be trying to improve? Not all SysAdmin work is "project" friendly - much of it is operational (repetitive tasks, checklists, preventative maintenance), much of it is more like debugging (handling support calls) and some of it is designing, building and deploying new infrastructure. Not all of those will map into agile methodologies well but some will, to be sure.

The best advice I can give to you in starting this off is to get to understand the nature of their overall workload and try to figure out how much of their time is related to the various aspects of the job. If you are interested in improving the ability and time to deliver new\improved infrastructure then definitely get involved in one of those projects. Get to know the team and explain why there is a need for this bridging (and I think it's an excellent idea BTW). If I was in your shoes I'd kick this off looking to make it a two way street - as in we want to improve X,Y and Z so what do you want us (either the dev side or Management or both whichever hats you are wearing) to do in return.

One thing to look for is to identify the things that are Really Important. For example if I'm working on deploying some new infrastructure and I get an alert that there's a performance issue on the SAN or something is going screwy with the firewalls I'm going to stop the project work and focus on the production issue until it's resolved, or someone else takes over. If that means the project deadline is shot, then so be it. Now I think that's obvious but I have been in a situation where I was being hauled over the coals by a deployment PM in the past for missing deadlines because I was busy getting a $2bn production facility back up and running after a catastrophe so I'm not unfamiliar with what I consider to be poor attempts to improve project effectiveness.

In my experience as organisations get larger quite a significant (and unhealthy) distance builds up between developer and administrator groups which is a pity and efforts to eliminate or avoid that are to be applauded.

Weekly meetings sound okay in general. But if you want to bridge a gap, you should go ask them or at maybe their lead if there is one. I think you should first try to learn what they are about, what their common tasks are etc. Then you might have better ideas on what a working structure might be. If you go in with a plan and haven't talk to them, they might be defensive about it and feel you are being a little hostile.

It is important for the future relationship because the best environment will probably come out of both the developers and the admins being able to give in to each others needs, and taking the time to understand the perspective of each other. If you don't seem like your primary concern is to understand their perspective first, they probably won't be open to yours.

Also, you might want to be cautious about going all "agile" on them, they might look at you like some sort zealout ;-)

You definitely need to get together with your sysadmin co-workers and learn about what they do before you start recommending any changes. Even if you have previous IT experience, every company has its idiosyncrasies, and nothing is more irritating to a person than someone trying to tell them what to do who doesn't understand what it is they actually do.

The first thing I would try to find out is how they keep track of what needs to be done. There should be some recurring tasks that are performed according to a schedule, and some one-time tasks which include support requests from users and projects that IT is working on. If there are multiple lists in multiple places, you might start by trying to get things consolidated, preferably in an electronic form that is accessible by multiple people (those that need access). Tasks which are not part of a specific project should be organized into general projects. For example, an IT Maintenance Tasks project could include all the routine maintenance tasks that are performed daily/weekly/monthly. It might be wise to categorize more definitely if several of the tasks are related. For example, if there are seven tasks related to data backup, you might want to put those in their own project instead of in the generic IT Maintenance Tasks project.

The second thing to find out is how they determine priority. Is it more like a queue (FIFO) or a stack (LIFO)? Are scheduled tasks more important than one-time requests? What is on the backburner or being saved for a rainy day? You should hopefully find that catastrophic issues are escalated to the top of the list, because systems being used for production need to be running or nothing gets done, just like a programmer would prioritize bug fixes over adding new features. Because you mentioned the word "agile", I would be on the lookout for whether the amount of time to complete a request is taken into consideration in prioritization. I find that doing quick tasks (10-15 minutes or less) right away helps keep the volume down and users happy. Longer tasks should be prioritized with as many levels as possible/necessary; this depends on how many tasks and how many resources are available to work on the tasks. Each task should be assigned to one resource and each resource should be able to filter the task list to show only their own. Manager-types should be able to see the tasks of everyone beneath them with the ability to sort by person or by project.