devXero's blog

a blog about agile, development, and automation

Agile 2008 – Trouble with component teams and an alternative with Bas Vodde

Posted by Mike Longin on August 6, 2008

Let me start by saying what a great session this was to attend.  Bas Vodde (http://www.odd-e.com/blog/) is one of the fathers of lean\agile development and listening to him was really a great experience.

The session topic dealt with how large teams (50++) handle scrum.  He actually has a new book coming out that I am looking forward to reading (Scaling Lean & Agile Development).

The first thing discussed was Conway’s Law which I had not heard of.  There is a good summary here (http://en.wikipedia.org/wiki/Conway%27s_Law).  To summarize

  • Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.

Meaning that if a team is divided on some generic lines, the system itself will end up with divisions along the same lines.  While I have not heard of this law before I can attest to seeing this kind of division in different products and projects I have seen.

Bas’s main point throughout the talk is that teams need to be broken up as feature teams and not component team.  A component team is a team that owns part of the product.  Examples would be a UI team, or a file management team.  Feature teams are designed to pull tasks off the backlog indiscriminately.  Each team has the ability to change any part of the system due to a combination of diversity on the team and component guardians (which I will explain later).

One of the next points he brought up was that teams that have multiple product owners (under 100 members of the development team) really are just setting themselves up for failure.  The optimal situation is that there is one product owner and one backlog.  And that each feature team can handle any item on the backlog.

For feature teams to work one of the things needed is a good Continuous Integration system.  What this means is that the developers are constantly integrating their working code into the main build, and the system regularly is built to ensure compilation is possible.

Another important part of this is the concept of component guardians.  This is a single person who watches over a component to ensure all modifications to it are compliant with the original intent.  These component guardians can meet regularly with the developers of the system to help the feature teams make use of existing functionality.

I know this was brief but I am going to end this for now.  I am planning come back to this post in the future to examine how my company uses some of these techniques.

Mike

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: