Global Organizational Transformation to Agile and Distributed Scrum 1

battleshipcarrierLet’s say you’ve been given a pre-1940’s battleship fleet and your orders are to take your fleet and go across the ocean into a major conflict and win against a modern navel force…now.  

A battleship was the flagship of the pre-1940’s navy, but today you need carriers to to be effective with a global navel strategy.   You’re going to need to change your battleship fleet to a modern aircraft carrier fleet before you arrive to have a chance against a modern navy.  But you haven’t been allotted the time to build a modern fleet, the conflict is going on…now.  You don’t even have time to pull into drydock and upgrade your existing fleet, your orders are to get underway…now.  Your only real chance at being victorious against a modern navy is to modernize your fleet as much as you can on your way to battle.  That’s a tall order and it is certainly not the prescribed approach to the situation to be successful, however it is similar to situations countries, and global organizations face all the time…modernize or perish.

Now, let’s say you have been give the task of performing an agile transformation on a non-agile global organization, and you need to start the transformation…now.  Most of you entering into the Scrum or other Agile frameworks will not have the luxury of redesigning the footprint of the entire organization to accommodate the framework.  Nor will most of you be given the leeway to make minor, let alone major changes to any number of existing structures within your organizations until you have shown to the decision-makers that your new process is effective and produces valuable results.  This is where Distributed Scrum makes practical sense.    I work for a 5+ billion dollar corporation who has locations all over the globe.  There is no way we could have started to move into the Agile arena on a large scale without figuring out how to embrace Distributed Scrum. 

Ideological Scrum (Full Scrum) prescribes co-location of all team members to achieve maximum effectiveness.  I agree with this concept for several reasons:

  1. Communication:  collocated communication is simpler and more complete (you can see your teammate’s body language) therefore it stands to reason that it is more efficient with usually leads to “quicker quality”.
  2. Focus:   when in a room together, a collaborative group will be more focused than a team who is sitting in front of the WWW.
  3. Comradery : people who experience things while together tend to grow more knowledgeable and productive at a quicker rate than those who do not have the opportunity to do so

However, in our case, it is not feasible let alone smart to relocate hundreds of employee from their current locations to our headquarters to demonstrate the benefits of Agile development (that would be the drydock approach).  So how do you mitigate the drawbacks of distributed communication and collaboration to deal with real world constraints yet still become highly productive?  Here are a few suggestions that you can implement yourself without heavily involving your senior staff:

  1. Put a product in a location: surround the product with as many local resources as you can avoiding the temptation to put team members from multiple time zones against your product wherever possible
  2. Constantly work towards co-locating teams around products locally:  if a remote team member moves on, look to replace the spot on the team with a local member where possible…this will co-locate your product teams around your products as you move forward
  3. Create an environment which uses as many senses as possible:  get video involved whenever possible and avoid using email as a communication mechanism (see “7% is not enough”)
  4. Avoid constructing  teams with skill-sets residing across oceans:  if your organization is multi-national, build fully-functioning teams in each location and service it locally (including PO) vs. a “develop in one country and test in another” approach
  5. Monitor team dynamics and adjust accordingly:  never underestimate team chemistry…if a team’s chemistry has not solidified within the first few iterations, it is likely that they will not excel in a distributed situation, so look to change up the team makeup quickly…don’t wait

What I have seen is that poor quality, delayed deployments, and  inaccurate deliverables are generated more often from poor communication than from a lack of subject-matter expertise.  Distributed teams complicate communication so it is critical with distributed teams to get team chemistry and communications working from the team’s inception for it to be effective.

One comment on “Global Organizational Transformation to Agile and Distributed Scrum

  1. Reply Jay Conne Jun 16,2013 8:24 am

    Well said Mike. Some clients still use offshore QA for integration, full regression, load and stress testing.

    Some have feature teams feeding component (or application) teams that are distributed. And some of these have project dedicated feature/component team members and some just share the component team staff. Transitioning these takes a lot of time to cross train silos of knowledge.

    It’s just like your analogy – thank you.


Leave a Reply