I worked on several projects that used some agile process in the past 8 years. None of them was following 100% the recommended process. On some projects nobody ever said anything about "agile", but the process was actually a variation of one of the agile themes.

About the scrum daily standup meeting: That's very good if if it's kept short and to the point. Some say that the only import question is "what's blocking u today?" and that's the only question asked/answered in some teams. You don't really have to standup - the idea is that the meeting has to be short and people have to pay attention (it's more difficult to answer emails or do something similar when you stand up :) ).

The self organizing teams never worked on the projects I worked on, where the team had more than 3 developers. In our case, developers are all around the world and they have very different skills. Cultural differences and different time zones also make very difficult to "self organize". I've seen it working though twice when the team had only 2 developers. :)

I've tried pretty much all agile recommendations - but as I said never 100% and never to the letter. In my opinion, the most important "things" are:
- embrace change - change is normal, deal with it, don't deny it
- iterations - 1-4 weeks - I prefer 1-2 weeks - each iteration has to end with "provable" results - how u "prove" it, who's involved, etc depends a lot on the team(s) and project
- keep away from the waterfall process - there are always people who try to drag u back to waterfal - resist it!

I've also tried extreme programming and peer programming. I didn't really like that and I didn't see the promised results. Most people cannot concentrate when somebody else watches them and that reduces productivity and it doesn't really improve quality.

Vlad

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