I'm not an expert in agile development processes, so I'm kind of reluctant to give advice or "judge" what others are doing.

I think you answered some of the questions yourself in your answer to Tracy. :) Something about waterfal scrum :), inflexible schedule, too many and too long meetings. :)

On the other hand, I/we had similar problems on some projects... Here's how I see "agile" and how I try to solve this kind of problems:
All agile processes are based on the old and proved "divide&conquer". That's why there are iterations/sprints/etc. If it takes too long to plan an iteration, it means you did not divide yet properly or that people are analysing and talking too much. :) If people have the tendency to over analyse... the team leader/manager/etc should step in and cut it short. If you did not divide properly... do it again by looking at the problems from a different angle. Sometimes you may need one or more iterations just to divide the problem (that usually involves a lot of prototyping). We had such iterations where we just took one or two aspects of the problem (usually the aspects that were causing us to be stuck in discussions) and prototyped different solutions. Of course that may impact the overall schedule, but agile is also about accepting change and, many times, because you solve the riskier problems sooner, you make up the time spent on such iterations. Sometimes you have to add iterations, sometimes you can remove iterations.

Now, *I* like shorter iterations. But that's not always possible and it depends a lot on the project and the phase of the project. One mistake that I've seen a lot is to decide the length of the iterations at the beginning of the project and keep the same length for all iterations. That doesn't make any sense to me. The length of each iteration is determined by what you're supposed to deliver in that iteration. And the length of each iteration should not be cast in stone. If you have a 4 week iteration and finish in 3 weeks, change it to 3 and move to the next iteration. And if takes 5 weeks... that's life. :) It's better to finish what you're supposed to finish in 5 weeks than to declare the iteration finished in 4 and leave problems behind.

Another mistake is to force all teams to work on a common iteration schedule. Sometimes that makes sense, but many times it doesn't.

I think it's all about being smart and flexible. I don't believe there's any process that can guarantee success and that fits all projects and all teams. Agile processes usually make it easier to be adaptable/flexible and to deal with change. A cast in stone agile process doesn't really make sense. :)

I try to avoid long meetings - anything over two hours is too long - people don't concentrate anymore. If I see that I get into too many long meetings, I usually ask my manager to do something about it. :) Another solution I learned from some very good developers is to simply ignore the meetings and prototype, if at all possible. A lot of times people just keep talking about solutions without having enough data to decide. Protypes usually add that extra data needed to be able to make a decision. :)

Another way to cut down on iteration planning is to have really short iterations - 2-3 days each. That usually allows for tiny goals to be established and achieved and it makes it easier for some developers to concentrate in meetings and dicussions. In my daily work I try to set 1-day iterations for myself. It creates a good feeling when you start to work on something in the morning and it's done at the end of the day. :) The goal of such iterations is not necessarily something I could demo to the "stake holders", but it must be something I can "prove" through unit tests or something I can "deliver" to another developer.

Vlad



>Vlad & Tracy,
>
>You have both mentioned very short sprint durations. Vlad, you mentioned 1-2 weeks, Tracy 2-3 weeks. We must be doing something wrong, because our developers have barely started any coding after 1 week. I think our sprint planning and design must be taking too long, but I'm not sure where the problem is because I'm not on those teams.
>
>My team isn't quite that bad, and we have 2 members who are in the UK, many time-zones away, so when we do our initial sprint planning, we can only spend about 2 hours (maybe 3 if we're lucky) spread out over several mornings before we can actually finish the planning and move on to design and actual coding. None of the other teams have that limitation, so you'd think they'd get started immediately after the planning meeting.
>
>Not sure how we can improve the process, but I'm just throwing it out here in case anyone has any suggestions.
>
>~~Bonnie
>
>
>
>
>
>>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)