It's human nature to resist change and come up with reasons to not do something. You should start with some research and reading. Some of the things you've said about Scrum are correct, others are not. And I totally agree with Tracy. Get some training. See other responses inline....

>We have a new president and he wants to switch to Agile development cycle. We've looked at it in the past and backed off because we wanted to switch to Scrum with Test Driven Design and it just didn't work at that time. We are back at looking at it now (just scrum not test driven design) but I have some questions and hopefully people that have been thru the pain of switching can answer some of my questions.
>
>1) Daily standup. Seems overkill to me. I don't work this way in general of what I can do "today" and what I did "yesterday". There are only 9 developers and we have weekly meeting currently about what's our workload and if there are problems. We are a tight nit team we all sit next to each other and just stand up and ask a question if we are stuck or need help. Everyone will always stop and help if they know the answer.

There's a reason it's called a "stand up". Don't sit down. Many teams don't even have chairs in the room. Make it 15 mintues and stick to the three questions, What did you yesterday? What will you do today? What's stopping your from progressing? Don't try to fix problems or offer solutions or suggestions in the meeting. There are two purposes to this meeting. 1) To find someone to help with problems (again, solutions aren't given in the meeting) and 2) Let management and project stakeholders know where things stand.

>2) Self organize team.
> a) I'm in charge of the programming department and what exactly would I be managing in Agile cycle? Nothing? I should point out that I'm not a micro-manager. I let people run their own project currently with the understanding they are responsible for having that project go smooth and if there are problems they need to let me know so we can figure out a way around it.

Scrum is not about mico-managing. It's about knowing where the project stands. You can still let them run their own project. They just report status more often. It also causes roadblocks to show up earlier in the process.

> b) What about skill set. I've had people that wanted the harder project even with their skill set not up to the challenge. How do you handle that? Tell them no but then they aren't self organized? Let them go and just watch it fail? Wouldn’t “clicks” get started where only people want to work with each other? I currently do divvy out work.

You can still match people with projects appropriate to their skill set. For example, the project has easier and more difficult tasks. The devs with more experience can be given a list of tasks from the difficult list, then they choose what to do. The less experienced devs are given a list of the easier tasks.

> c) Also the time slicing. If one project will take 2 months to complete can programmer A take the first sprint then say no he doesn't want to complete the 2nd sprint? Seems it would be more efficient for them to complete the entire project.

Two ways to tackle the problem. 1) Break down the 2 month project into smaller slices that can be disbursed to different devs. 2) Give one dev the task of completing the project. The work is then broken down into multiple sprints.

> d) Encouraging colocation. Currently QC/Business Analyst/Programming all sit in different areas. BA would be the voice of the customer but my team runs smooth and I don’t feel the same way about the other departments. I would hate for them to potentially ruin my great team of players with their attitudes with nothing I can do because they don’t answer to me.

Colocation doesn't necessarily mean everyone sit in the same area. As for voicing, IMO, if QA is not involved from the beginning, the project has a higher chance of failure. But you don't let the other teams drive the Sprint. If they are inserting too much influence, then you step in as manager and let them know there are boundaries and they've crossed them.

>3) We do both a baseline application and we do modifications for clients of that baseline work. We currently don't have designated developers to one or the other. Based on the weekly meeting we determine who will work on what (customer vs baseline). That can switch all the time. I like not having a "baseline" team because a) All the programmers will at one point work on baseline and know what's coming out and we don't have a learning curve for all the developer who weren't on baseline to learn the changes b) Baseline isn't only coded to the styling of a couple of developers. We do have standards but each developer has their own quirks. How can we keep this flexibility and still have Agile? Make the sprints only a week then reevaluate who needs work (seems too small of time in between sprints)

A week is really to short, but not every task fits into a week. At the beginning of the sprint, the dev is supposed to take what they think they can do in a month (and the tasks should be divided up be management, stake holders, and scrum master so that they are presented in 30 day chunks). So, one 30 day task may consist of baseline and non-baseline work.

You don't need to follow the "rule" of Scrum to get some of its benefits.