Not sure I can address each of your questions, but I can answer from my experience. We are using SCRUM and if you questioned every developer when we first started, most probably would have answered 'not another meeting!' :o)

As it turned it so far, it is working great. One thing we did was bring a certified SCRUM master training to our location and require all of the parties involved to attend the training. The biggest problem and one which we cannot abide by, is the rule of one team per person. Just too many projects with commitments ($) going on all the time. We cannot do that. However, it is really working well. QA and documentation attend our meetings. If the project requires any special hardware then the tech folks attend as well. If you obey the rules and keep the daily SCRUM to 15 minutes it goes fast. The longest we've had is probably 30 minutes when we first started before we learned to keep it short. Just the highlights. It gives everyone an idea of what is on the plate, who needs help, and what is left to do. No help or direction is given during the meeting. Plus, with SBI's identified, when one programmer finishes an SBI they can hop on another one on their own. A big adjustment is to stop thinking and practicing waterfall. Some companies employ a 'modified' SCRUM.

Keep in mind, that in SCRUM, there is no manager calling the shots. There is a product owner and a SCRUM master (not the same person). We rotate SCRUM masters every sprint. One of the major adjustments is for a manager to behave as a team member and not as a manager or make them the product owner if you have to because the product owner determines the value of each item. A good learning step is to make sure that the first ones who serve as SCRUM masters are NOT managers. Managers asign people to teams, but the team itself is self-managing. It quickly becomes apparent who is working hard and who is not. New developers may take on easier or less complex SBIs in the beginning, but it will be easy to see if they are actively participating or not. Participants volunteer to take on a backlog item. It may be that some items are far to 'hot' or specialized for everyone to do, but in that case the team member capable of doing the item takes it on. We have not had any problems with developers fighting over items or anything. Most often, if a developer has experience in a particle area, he or she will volunteer for that item. If a person really wants to get their 'feet wet' learning a new area, then they may take on an item if the burndown process is going well. The whole idea is to get a deliverable out there every sprint. At the end of each sprint, a demo is done. In our case, it really wasn't a deliverable, but the demo definitely highlights the effort put into it and visually demonstrates what remains to be done. In my experience so far, there is a lot MORE flexibility in SCRUM.

Have you attended SCRUM Master training? It is really important if participants really are going to understand the process. Get the managers, developers, QA folks, etc all in the training so they really understand what the process (and their behavior) should be. If you cannot do that, then have at least one person attend and become a certified SCRUM master so they can in turn train everyone else. In the training you learn how to create the product backlog, decompose sprint backlog items, and how to vote on the hours required to complete and anything else to do with SCRUM. Use SCRUM cards with hours on them 1, 2, 4, 8, 20, etc and the team holds up the card for each SBI and you determine what the expected time to completion for that SBI is. More experienced developers may tackle more difficult SBIs, but it is important that you determine the amount of time required to complete the SBI for any developer on the team. Developers don't 'take sprints.' Developers take on an sprint backlog item within the sprint. Every developer on the team is responsible for completing the SBIs and PBIs that are identified as a part of the 'sprint.' If a developer cannot do an SBI, it can be taken over by another developer, but all on the SCRUM team (for that product or project) participate and have responsibility. You can make the sprints as long as you wish regardless of the recommended length. We have rotated between 2 and 3 weeks for each sprint so far and have considered a 4 week sprint under special circumstances.

We have some developers in close proximity, and others who are not. It really isn't an issue. In some cases we've had VFP developers on teams to help the dotnet developers understand VFP code when it comes to a SCRUM having to do with a re-write of a product into C#. The breakup of the teams had to be equal to account for that (if you have a mix of VFP developers, C# developers, and VFP/C# developers). That developer may spend the majority of their time initially actually explaining VFP code to the .net developers on the team (basically walking them through the code of their sprint backlog item), but that is a part of the process and just as valuable. As the developers who originally didn't understand VFP code go through a few sprints, the time required for them to walk through existing code with a vfp developer should decline which then frees up the vfp developer to spend more of their sprint time actually coding as well.

The longest process, and one that hasn't been optimized yet, is the process of identifying PBIs and SBIs. That process is long for large projects and I guess every business has to decide how they go about that.

So far, I'd highly recommend it in businesses which have more than just a couple of developers and especially in businesses which have a development group, a qa group, and a support group and possibly a documentation group or person, a hardware group, etc. That is surprising because, unbeknownst to others, I was a diehard "NO WAY" participant initially (just give me a task or project and leave me alone to do it!) SCRUM is really great for getting a product out the door and giving developers the freedom to take on new tasks and have the result 'visible'. :o)



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