We're doing only new development and still trying to find the best methodology that will work effectively for us. We've been at it for several months, and unfortunately several of the higher-ups in management are making this more like Waterfall SCRUM, which is an oxymoron obviously. Not much I can do about it ... probably one reason for the lengthy time it is taking to get started with a Sprint.

They've tried to speed things up by instituting yet another meeting ... a pre-planning Sprint meeting. I agree that a little pre-planning is probably needed, so that we know which PBIs we'll be tackling and what exactly are the specs for those, prior to actually starting the Sprint. But, unfortunately, we're being meeting'd to death. (All these extra meetings have nothing to do with the actual Sprint meetings ... those are fine and necessary ... the 4 meetings: Planning, Design, Code Review and Demo/Sprint Review. They don't take up too much time). But, we still have endless other meetings, or at least I do, as a Team Lead.

Our problem, I think, is that we've been committed to an inflexible deadline and each Sprint gets methodically completed and the team moves on to the next Sprint (which may or may not have anything to do with the Sprint just completed), with not much wiggle-room to extend the Sprint when necessary (we can, but not by more than a couple of days). Consequently, stuff that should have been completed in one Sprint but was not able to be completed, gets either moved to the next Sprint (which is good, as long as they get done then) or left as an incomplete SBI ... which is fine, but the problem is that those will probably never bubble back up to be worked on (because of the deadlines) and that's definitely not a good thing.

Don't get me wrong ... I'm not knocking SCRUM. I think it's great! I just don't know if our company is going about it the best way ... the process still needs to be fine-tuned.

~~Bonnie



>We typically start coding immediately following the decomposition. At the beginning of every sprint, we look at the PBIs and create SBIs to be done. Sometimes that is done in advance by a programmer. A programmer may look at a PBI and create SBIs to show the team and the team agrees on them or modifies them. For new development, the PBIs and SBIs are more functional. For re-writes, it is looking at the fox code and ensuring not a single method or procedure is overlooked - for our current sprint they became SBIs. Each method or procedure will not be done in .net of course (some become totally unecessary), but they need to verified that the function they perform is included in the re-write somehow so the same behavior exists in the new product.
>
>We have developers all over the world as well :o) It becomes a challenge when participating in SCRUM meetings, but other than that, it isn't a problem. On my team there are developers in other states but we are fortunate that we are in the same time zone. We do have meetings that involve other timezones as well though and they can be a challenge. We have to include time in each SBI for understanding the function. For re-writes, an experienced vfp developer who is knowledgeable about the existing product often has to discuss it with the developer who is taking on that SBI so they really understand what it does before they code it in .net. For new development, not so.
>
>A challenge for us was to get the decomposition process to a point where it didn't take all day (or in your case, many days since you are limited in time for each meeting). In our first sprints, that was the case. It soon became clear though that it didn't make sense because we wouldn't get to all of that in the current sprint anyway. We are experimenting now with getting everything into a PBI or SBI and then allocating them to a sprint. This seems to be working for this sprint. You can bend the rules to suit your needs. Just to get the ball rolling, you might consider assigning some decomposition in advance of the meeting and then discussing them as a team when everyone can get together. I would just try different methods for the first couple of sprints to see what works.
>
>I'm interested to see what anyone else comes up with :o)
>
>I should add this process is still fairly new to us in practice (only a few months) so each team is experimenting with what works best. It is beginning to look like what works best is not the same for new development and re-writes though. We are still working it through though and we have the meeting at the end of the sprint were all teams get together to discuss what worked, what didn't, and presents new ideas to try in the next sprint. We don't limit that meeting to a single team while the process is still being tried and tested.
>
>Another add-on: if the entire decomposition doesn't get completed at the beginning of the sprint, we had to decide what to do when a developer took on an SBI that ended up being larger than initally thought. For example, a function may call several other functions and there may be forms and external methods in that process that weren't in the SBI, but assumed in the PBI. In our last sprint, it was decided that when that happens, the developer will create a new SBI for anything he doesn't get to (an example would be code specifically for interfaces that are not a part of the beta release) and stub it out for now. Or a call to a method that is actually another SBI (an example would be a method or function that is called from many locations in the app). The developer would just stub that out for now because the called function or method may not be in place yet if someone else is doing that SBI. If that called method or function doesn't exist as an SBI, then that developer either does it, or adds an SBI and stubs it out. It is important that it becomes an SBI though so it doesn't get overlooked in a future sprint.
>
>One thing that became obvious immediately was the need for a good tool that everyone has access to handle the PBIs and SBIs. We are testing a couple but right now. We are working primarily with one. I don't know if that will be what we end up using or if it will be another tool. It is important that a tool is used though so every developer can go in and see if something he comes upon is an SBI or not and who has volunteered to do it or if no one has.
>
>
>
>
>
>
>
>
>
>
>
>
>>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)