BT

Interview with Bas Vodde at Agile 2008

by Amr Elssamadisy on Jun 02, 2009 |

Bas Vodde describes strategies for large teams with legacy software to adopt Scrum successfully in this interview at Agile 2008.  Bas discusses communication problems found in most component teams and why and how teams - especially large ones - should make the change to feature teams and how that change affects organizational structure.

Bas discusses the communication issues that come up with component teams:

If you got a bunch of component teams and you got one requirement and one requirement will never fit to one component team, and therefore the requirement will need to be split up and parts of the requirements will need to be given to different teams. Once you got a requirement and you give it to multiple teams and the requirement is over, first of all there will be a lot of communication freezing of interfaces and that kind of things, to decide, because interface in software and communication between teams in component teams is equal to each other so teams need to freeze their interfaces because their interface is the communication between other teams.

If they freeze the interface they can program to the interface and then hopefully later integrate it together. And because the requirements never balance to the teams, therefore the teams will get out of synch so when they got maybe perhaps not the highest priority requirement then that requirement will be worked on for example in one component team in one sprint but the other team will not be working on that requirement yet and they will be working on the next sprint and therefore you get not only the communication or the synchronization issues but because they are not working on the same feature at the same time you get this other team sprint later communicating back about one thing that they did in the previous sprint. And you get kind of the same problems as traditionally between developers and testers, where developers are annoyed by testers because testers are giving feedback about what the developers did earlier.

And his solution to this problem is to create feature teams and have teams manage their own inter-team communication:

One of the key practice for letting multiple teams work on the same component is continuous integration so a lot of the communication actually goes by the teams via integrating lots of small parts. So for example if one team makes a change in a component the other team is also working in that component and they notice that the other team makes that change then at that moment these teams would talk to each other and that is another important concept which we talk about in the book is that teams within a large product need to be responsible for their coordination between teams. Instead of creating a role for coordination, it’s the job of the team to coordinate between teams and such coordination could be changes in the code for example.

So if you are in a large organization considering a move to Agile watch this interview.

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT