Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am in a shop where we do everything. I have been studying Agile and Scrum and while I can see how well it works with programming, I wanted to know what to do for non-programming projects. For example, I have to upgrade a lot in my AD, like moving the root server out of my forest for a new machine that will be the forest root. Or maybe transition from a Windows environment to Linux or Mac.

I don't want to go crazy with projects and some of those might not be the best example, but say I had a lot of server admin stuff that needed to get done. Is there a good way to handle it like you would a programming project? I have seen some that try to put every single thing on an excel sheet to those who put nothing down anywhere (that'd be me) and just do it. It's getting more complex now, however. I can see how some agile axioms are good for this situation but some don't appear to relate at all.

Thank you for any thoughts.

EDIT: if I use scrum how would I do it? What would user stories and features mean here? Would that be "We want to be able to have a stable machine for the forest root"? That goes on the product backlog, to the sprint, get estimates, etc.?


locked by HopelessN00b Jan 22 '15 at 5:19

This question exists because it has historical significance, but it is not considered a good, on-topic question for this site, so please do not use it as evidence that you can ask similar questions here. This question and its answers are frozen and cannot be changed. More info: help center.

closed as too broad by Dave M, cole, mdpc, kce, Rex Nov 21 '13 at 22:39

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

What kind of staff do you have to work with?

I've used Scrum for other non-programming projects and it works well for me. I like it because it helps me to prevent scope creep and doesn't give me the impression that I absolutely have to do every task iteratively, where there are no dependencies. Both of the examples you give would fit well with Scrum.

Features and stories are just your big tasks and their subtasks, as long as they're measurable. For example, migrating from Windows to Mac. A feature could be "I need to move software to Mac versions". A story could be "Migrate MS Office 2003 to MS Office 2008". This may or may not work depending on how long you've defined your sprints to be, you might need to break it down further. I've seen (and occasionally used) another layer (Epics) in between Features and Stories in order to have one more level of breakdown.

Not sure what you are asking. – johnny Jan 5 '10 at 18:59
Basically, who are the players in your projects? Do you have a project owner and people that can play the scrum roles? – squillman Jan 5 '10 at 19:13

Kanban would work well for this since it doesn't require you to have sprints or iterations, makes it really clear what work is being undertaken and what is left, and encourages you to deliver quality quickly.

Kanban 101 is a good introduction to Kanban, explaining most of it better than I could, and here's some good photos of Kanban Boards.

For large projects like migrating from Windows to Linux I'd definitely take some of the principles from other methods like XP - pair working in the planning stage is vital, as is testing absolutely everything before going live and limiting the number of hours worked per week means you don't miss things due to tiredness.

Most importantly, you don't need to follow any project management strategy to the letter, you need to find what works best for you. Investigating Scrum, Agile, XP, Kanban etc will give you some good ideas for might work well in your corporation's culture.

Finally, buy a whiteboard. Even if you don't use it religiously as part of any project management method, they're useful to leave reminders for yourself and others.

"and encourages you to deliver quality quickly". No it doesn't Having worked with Kanban for at least 20+ years I can assure you it does absolutely nothing for either speed or quality. It's really little more than a task list. It's objective is simply to ensure that ALL tasks/stages are carried out. – John Gardeniers Jan 5 '10 at 23:03
Then you're not implementing it fully. One of the ideas behind Kanban is that you decide which task to take on next based on which will deliver the most value to the customer, so you aim to prioritize delivering to the customer rather than taking on new tasks. – kaerast Jan 6 '10 at 11:12
@john my brief study of it made me think the same thing. It looked like graphical task list and no real deadlines. I need timeboxes or I'll never do it on time. I wonder if the folks using it where it originated have a different work ethic and others do. I would have to be highly motivate all the time to make it work. – johnny Jan 6 '10 at 15:32

first you should be clear what people are involved, is it only operations staff or are also some developers involved. When only operations is involved you can choose by yourself, otherwise it should be related to the projectmanagment from the dev-deparment. When I understood you right, ops has no pm, but dev has it most of the time.

Kanban is in my opinion a good way to regulate the work which is done at one moment in time. But you must first be clear what has to be done in the project.

Some people have tried to adopt agile principles to systemadminstration. Here are two blogs to start:

If you search Google for agile systemadministration you will find a lot more.

I suggest you start with a small plan and do not try to implement to much pm techniques. If you feel the need to implement some more methods you can add some more. So you also iterate over your project management style. The methods you implement also depend on the size of your projects. If you have small project sizes (lets say up to 4 weeks) it does not make sense to implement a lot of methods. It will only make your projects more complicated and lengthen them.


Use an outliner that allows you to manage a tree of tasks. Works wonders compared to flat TODO files or even spreadsheets.


I'm using these two: leo and hnb.

Of course there are more options: vim and emacs have outlining features, there is also freemind etc

you mean like in Word with I, A, a.,i.etc.? – johnny Jan 5 '10 at 18:58
No, an outliner... like vimoutliner, or one of the myriad of GUI tools that exist. They're incredibly powerful. – womble Jan 6 '10 at 0:10
I'll have to research. I've never seen anything like vimoutliner before. – johnny Jan 6 '10 at 15:29

As a project manager, I pretty much use Scrum in my projects. Also, I have seen growing demand for Scrum Certified professionals. Also, the Guide to Scrum Body of Knowledge provided a complete reference for the Scrum project I am working with. It is a very good book and extremely readable. I really liked sections on risk and quality. The tools mentioned in the processes were very helpful. I highly recommend this book if you are planning to implement Scrum in your organization. The first chapter is available on


Not the answer you're looking for? Browse other questions tagged or ask your own question.