• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Agile Scrum XP blues

 
Ranch Hand
Posts: 69
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

About a year and a half ago, I came across this whole Agile thingy. I took me some time to get into the grooves, but yes it worked absolutely fine for the first project. we were 12 people, sprints always delivered what the product owner wanted, and with time we achieved a 100% availability for a 'historically notorious service' which had taken an oath to break down 10 time every weekend and give blues to the duty maanger.

So with all rosy I now went to the next project. a huge one i must say; 6 teams 50+ developers in teams of 10-15 each developing each of the sub systems in this titanic thing I am talking about. But this time things are as bad as they used to be in the days earlier to this first Agile/Scrum exposure. it is the same guys more or less, well for all of them this is not the first Agile/Scrum/XP exposure, but yea, its not been that good at all.

That makes me wonder

1) Is the combo suitable for small sized teams (or projects) only?
2) Some one gave an interesting thought that one never really has time for performance / load etc and the like as it will be more harmful if the product owner does not see the functionality at the end of the sprint rather than giving a sub performing system but yes all functionality delivered.
3) Is it that for large projects using which are some where in the core based on a product, if using Agile etc it is better to just develop on top of that product than tweaking/changing it around to suite your needs better?
4) Is it viable to have an independent Integration Team which can point out "Hey this is gonna hurt badly later"
 
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Anadi Mishra:
So with all rosy I now went to the next project. a huge one i must say; 6 teams 50+ developers in teams of 10-15 each developing each of the sub systems in this titanic thing I am talking about.
[...]
1) Is the combo suitable for small sized teams (or projects) only?


Small teams will always fare better than large teams. It's just so much easier to collaborate within a smaller group. That doesn't necessarily mean that agile methods wouldn't be applicable and effective for large projects. The problems we've seen with large projects in the past, we used to try and solve with introducing more planning, more intermediate artifacts and more procedures. To some degree that helped make lives easier during a project but didn't solve the actual problem - how to build software with a large group of people - and eventually the s*it hit the fan anyway.

Agile methods don't solve all those problems but they force us to tackle those problems right there and then.

There seems to be a couple of key ingredients to making large-scale agile development feasible: continuous integration and feature teams. There's a nice extract from an upcoming book available on the latter.

Originally posted by Anadi Mishra:
2) Some one gave an interesting thought that one never really has time for performance / load etc and the like as it will be more harmful if the product owner does not see the functionality at the end of the sprint rather than giving a sub performing system but yes all functionality delivered.


I find it harmful if the product owner doesn't see the functionality already before the end of the sprint. If all features are finished on the last day, it's just a waterfall scaled down.

Having said that, performance testing (and, consequently, tuning) is frequently left outside of a team's Scrum process (I assume you're using Scrum since you're talking about POs) and being run as a parallel track along development iterations.

It would be better if you were able to create and run performance tests during the same iteration where new functionality was added but, in my experience, that parallel performance testing track is rarely the biggest problem to pay attention to.

Originally posted by Anadi Mishra:
3) Is it that for large projects using which are some where in the core based on a product, if using Agile etc it is better to just develop on top of that product than tweaking/changing it around to suite your needs better?


I'm not sure I understand what you mean by this?

Originally posted by Anadi Mishra:
4) Is it viable to have an independent Integration Team which can point out "Hey this is gonna hurt badly later"


This is what many projects have ended up with. I don't know that it is the best way to solve integration problems. In fact, I feel that such a team would merely externalize integration issues from the development teams, making them less accountable for working towards a whole product and more focused on their own turf. I'd much rather optimize the heck out of your builds to get continuous integration working smoothly across all teams.
 
Anadi Misra
Ranch Hand
Posts: 69
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

Thanks for the explanation, I totally agree that continous integration is a very important ingrediant in the success of large projects with multiple teams, it has helped us a lot too.


To some degree that helped make lives easier during a project but didn't solve the actual problem - how to build software with a large group of people -



Cant there be a scrum of scrums thing to tackle such problems? I had that opinion but you cant win all arguments in life

Point three was more of a mixup, I realized it is not something related to Agile.

Another question that keeps popping in my mind is that my team gets its set of user stories, while team X gets there, if we have an epic sort of broken down into user stories and these assigned partly to us and team X shouldn't we teams know of the epic and all the user stories derived out of it?
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I don't have any experience with large projects, but I know that there are people who apply Agile principles and practices to large projects, and prefer it that way. You might want to take a look at http://www.jeckstein.de/agilebook/index.html
 
Ranch Hand
Posts: 1609
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am not into project management anywhere but yes from my personal perspective it is not just agile to be blamed off. Same things could have been possible if not been obvious with other methodologies, for the same sized project. Scrum if it is really rooted to this sport then i feel it could mess with its own-self.

How do you have sprint deliverables, one per team or one for the whole project? Problem with scrum is, you can not clearly foresee longer and that the path to the deadline is not pre-planed and that way the owner should be worried for big project's metrics.



Originally posted by Anadi Mishra:


Cant there be a scrum of scrums thing to tackle such problems? I had that opinion but you cant win all arguments in life



Same arguments here as well, it would not only solve integration but also load balancing would be effective.
[ August 26, 2008: Message edited by: Akhilesh Trivedi ]
 
Akhilesh Trivedi
Ranch Hand
Posts: 1609
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well, this article is said to have written in 2003.

http://jeffsutherland.com/2003/02/scrum-keep-team-size-under-7.html
 
Anadi Misra
Ranch Hand
Posts: 69
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

How do you have sprint deliverables, one per team or one for the whole project?



We have it one per team, the continous integration takes care of the fact that eery thing builds from the root pom etc. The problem I saw was not the lack of vision or any thing, it is just that we deliver that user stories, we can never gaurantee we "deliver the best performance for the system as well".
 
Anadi Misra
Ranch Hand
Posts: 69
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

I am not into project management anywhere but yes from my personal perspective it is not just agile to be blamed off.



Me not either, but I get these 'keedas' of questioning things. Not a blame but I do feel Agile is deificient in some aspects, or may be it is not clearly defined how the Agile way is in certain scenarios. Ofcourse the odd mis-interpretation does occur but with self - organizing teams it is caught early, It cant be that all go stupid at one time you know .

My only query that remains unsolved clearly tiil date is how does Agile ensure a "performance optimized deliverbale by all the teams" at the end of each sprint in a multi team/big project scenario. If it doesn't I would prefer a way to incorporate that activity within sprints.

Such things now normally come back as a Service Request in maintenance builds and I can tell you ( you might agree to it as well) what it means for me is irritating Dominos Pizaa dinners in office for few days

Keeping it to 7 developers !!! well, we will have to split up the products then I guess, coz some of these individual projects can just do with 7 developers.
 
author
Posts: 37
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think the problem is not small teams or large teams, it is something a little more subtle than that. In fact, it is very common for the first agile adoption team at an organization to do fabulously well, and then the others fall flat on their face. In my experience it all comes down to different contexts - large teams is just one example of a different context.

Agile is no silver bullet. And one set of practices may fit very well for a small team and not work for a large team, or a distributed team, or even another small team that has a different set of priorities.

So, since this is a discussion on the book, I'll feel free to plug the book without feeling too guilty That is exactly where the book comes in - the first part is all about understanding the context of the new team and then choosing the practices that fit that context.

So, for example, one of the differences between a small team and a large team is the overhead involved in communication. Therefore communication practices will generally take precedence in a large team to mitigate this difficulty. More attention will need to be paid to information radiators, keeping team meetings short, and visibility. As noted in some of the comments above, continuous integration becomes crucial, etc...

It is not that Agile doesn't work with large teams - in fact my very first project back in 1999 was on an 80 man team and XP did wonders for us then - but we adapted many of the practices and introduced some new ones such as test driven requirements and continuous integration (this was the team at ThoughtWorks that came up with cruise control).
 
Anadi Misra
Ranch Hand
Posts: 69
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

Can you give some thoughts on this. I strongly feel this one should also be included, and honestly speaking am looking for some firmer groud when I bring this up again to my team

So, for example, one of the differences between a small team and a large team is the overhead involved in communication. Therefore communication practices will generally take precedence in a large team to mitigate this difficulty. More attention will need to be paid to information radiators, keeping team meetings short, and visibility. As noted in some of the comments above, continuous integration becomes crucial, etc...



"Cant there be a scrum of scrums to tackle such problems?" , along with continous integration and optimizing builds etc.....
[ September 10, 2008: Message edited by: Anadi Misra ]
 
Amr Elssamadisy
author
Posts: 37
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello Anadi,

If I understand you correctly, you would like something more about the differences between a large team and a small team. If this is correct, let me start by saying that every team is slightly (sometimes extremely) different. So this may or may not fit your context:

1) Large teams have more people to communicate. It is difficult to know the entire status of a larger team than for a smaller team. So things that you may have overheard while sitting down in the same room in a smaller team are no longer available because you are not all co-located.

2) Larger teams have more people checking in code. Coordination of code merges, conflicts, and dependencies become an issue.

3) Larger teams produce more code. It becomes difficult for everyone to keep up with the entire code-base, all of the requirements, and the full architecture.

4) Larger teams tend to be more distributed - even if on the same floor in the same building. They lose the 'osmotic communication' that smaller teams have.

5) It is easier for things to "fall between the cracks" with more people because of point (1), larger team members are not aware of the full status of the team.

6) Larger teams have a tendency to break into smaller subteams who communicate well with each-other, but exacerbate communication among subteams.


There are probably many more instances and reasons that communication breaks down. It is too much to go into these here in the email - the subject will fill a book....

All of these are all communication issues, so to improve communication you generally want to improve visibility and increase feedback. There is a communication cluster of patterns defined in the book (unfortunately not available for free download) .

Some of the practices are:
1) co-located team
2) self organizing team
3) stand up meeting
4) cross-functional team
5) customer part of team
6) pair programming
7) information radiators

etc..... Not all of these practices are applicable to all contexts, and you would have to read each pattern and discover it's (in)applicability to your context.

Hope this helps.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic