devXero's blog

a blog about agile, development, and automation

Posts Tagged ‘Agile2008’

Agile 2008 – Dependency Management in a Large Agile Organization

Posted by Mike Longin on August 7, 2008

Presented by Eric Babinet and Rajani Ramanathan

This presentation was presented by employees of  For those that don’t know, salesforce is one of the most prestigious SAAS (software as a service) companies and has implemented Scrum across the board.  This session spoke to the issues of dependencies over multiple teams in an agile enviroment.

A few interesting ideas that they presented and I wanted to get down were (with my own take on it of course):

  1. Key values for success in an Agile enviroment
    • Transparency
    • Feedback
    • Automation 
  2. All teams should be part of the release planning cycle. It shouldn’t be just a top down affair
  3. Teams meet at the beginning of each realease to map out all of the expected dependencys.  Helps to identify where the bottle necks are going to be early on.
  4. Concept Reviews
    • Members from multiple teams meet to discuss implementation and ideas.  Encourages cross team collaboration and knowledge sharing.
  5. Virtual Architecture group
    • Members are composed of members from the individual scrum teams
    • Different members have familiarity with differnt parts of the system
  6. Build Master
    • Babies the build
    • Rotates over multiple people

It is easy to see that the solutions to dependency that SalesForce found were based around communication and cooperation.  And when looking at it froma  distance it is pretty easy to see that this is where the solution would be found.


Posted in Uncategorized | Tagged: , , | Leave a Comment »

Should a sprint review be only positive???

Posted by Mike Longin on August 6, 2008

This is a question that comes up from time to time on my team.  Should a sprint review only be about the positive.  And if so what do we do about the negative.

I have 2 examples that illustrate my question.

1.  Your team sets out to accomplish 40 points but only accomplishes 36.  Do you spend any part of the sprint review dwelling on those 4 missing points.  If so how do you go about discussing them.  Or do you wait to the retrospective to discuss them.

2.  Your team has accomplished all of the objectives and stories for a sprint, yet is aware that there is more work left to be done.  The product owner for whatever reasons disagrees over the teams assessment and feels it is time to move on.  Is the sprint review the time to bring up this issue since it is one of the few times that the powers that be are all located in the same room.

These are two questions that time and again we are faced with and have yet to find the answers.

Posted in Uncategorized | Tagged: , , | 3 Comments »

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 ( 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 (  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.


Posted in Uncategorized | Tagged: , , | Leave a Comment »

Agile 2008 – Questioning Agile with Scott Barber

Posted by Mike Longin on August 6, 2008

So my first session today was with Scott Barber(  His session was about questioning agile.  Agile itself is constantly evolving and as a practicer it is important that those who are  practicers to keep rethinking what it really means to be agile.

Some of the questions that he asked are:

  • What is agile?
  • Who sez you really are agile?
  • What does it mean to be agile?
  • Do teams make decisions?

The last question I found to be really interesting.  As a team member so often we make decisions for the team and yet when it comes down to it most of the time these need to be approved.  Some of these decisions are simple like when a meeting is scheduled.  But many times they have much more serious repercussions such as determining a build is ready for release.  And really while the team does decide its not up to them in the end since its not the team that usually is financially responsible for that decision.  Thought it made a really good conversation point.

Another good comment he made was (and this isn’t verbatim) “Software developers write software that they would like to use and not necessarily what the customer would want.”  And I found that so obvious yet very profound.  So many times when it comes to some decision we make as a developer we just make it without asking the customer what they might want.

Felt that he definetly opened up some good talking points and wanted to pass them on.


Posted in Uncategorized | Tagged: , , | Leave a Comment »

Does Agile mean Open???

Posted by Mike Longin on August 6, 2008

One of my feelings about Agile has always been that in reality it is just a way of promoting openness and transparency.  What I mean is that with good agile practices the relationship between the customer and dev-team is entirely open.

As a developer I know exactly what the customer is expecting.  Every 2 weeks (2 week sprint length) the customer gets to see exactly what the developers are working on.  On top of that I can see what they are planning long range.

As a product owner, I get to see what my developers are working on.  I know within 2 weeks what they will be doing for me, and I know that my expectations will be met.

To me that is just being open.  Everyone knows everything.

I would be interested in others thoughts


Posted in Uncategorized | Tagged: , , | Leave a Comment »