Using Scrum in a Flat Global World

But how do we fit this Agile method which expects co-located, cross functional teams that iterate through sprints in a self-organizing fashion, with a capable ScrumMaster removing impediments and prioritizing backlog items from a Product Owner nearby, to one where teams, customers and Product Owners are located in another part of the globe, in multiple time zones and don’t all speak the same language fluently?

 

Not very easily and not without some significant tweaks to Scrum.

 

First of all, though Scrum and Agile purist will scoff at overly formal and complex processes, you will have no choice but to establish and agree upon some structure and process to how you will arrange daily stand-up meetings (or calls and emails), prioritize backlog items, run and review Sprints and the working deliverables each Sprint must create, as well as an escalation procedure to remove impediments.  This escalation procedure is important since the time zone difference between a team and a ScrumMaster could be significant.  For example, a team located in Asian could experience a significant impediment that will not be known to a ScrumMaster in the US till the next day.  The ScrumMaster removes the impediment, but will not find out if it was effective till the next day, and worse, if the impediment was not successfully removed, it will add another couple days of cycling through till it gets resolved.  This is not very agile!

 

A ScrumMaster will have no choice but to pre-define a clear communication, escalation and implementation plan that allows flexibility, yet enough structure and guidance to ensure deliverables get done on time.  It will also be very important to truly have a self-organizing team.  If you can’t be in the same presence and time zone of your team, you will really have to rely on them to be self-organizing, efficient and effective.  This means you have to carefully select a good team or work with one that you can trust.

 

You will also need a clear articulation of what it means to be “done”.  Use good software tools that will allow you to implement continuous integration of builds, source control and test driven development to ensure that the software being developed and delivered in each Sprint has been through the necessary QA before being released to the customer so that done is “done”!

 

This is hard and expect to lose sleep, but if you can balance both having a clear and well thought through coordination procedure and process, while still allowing the flexibility and agility that Scrum is known for, you may just get the successful results typical of Scrum when done right, but on a global scale.

This is hard and expect to lose sleep, but if you can balance both having a clear and well thought through coordination procedure and process, while still allowing the flexibility and agility that Scrum is known for, you may just get the successful results typical of Scrum when done right, but on a global scale.With this month’s Gantthead emphasis on global project management, it’s fitting to discuss using Scrum in an increasingly flat, global work environment.  With the trend staring in manufacturing in the 80’s and 90’s, coupled with the rapid advances in communication technologies, the imperative to to deliver application development in shorter timeframes, with better quality, lower cost and with globally dispersed teams is now the “new” normal.

 

But how do we fit this Agile method which expects co-located, cross functional teams that iterate through sprints in a self-organizing fashion, with a capable ScrumMaster removing impediments and prioritizing backlog items from a Product Owner nearby, to one where teams, customers and Product Owners are located in another part of the globe, in multiple time zones and don’t all speak the same language fluently?

 

Not very easily and not without some significant tweaks to Scrum.

 

First of all, though Scrum and Agile purist will scoff at overly formal and complex processes, you will have no choice but to establish and agree upon some structure and process to how you will arrange daily stand-up meetings (or calls and emails), prioritize backlog items, run and review Sprints and the working deliverables each Sprint must create, as well as an escalation procedure to remove impediments.  This escalation procedure is important since the time zone difference between a team and a ScrumMaster could be significant.  For example, a team located in Asian could experience a significant impediment that will not be known to a ScrumMaster in the US till the next day.  The ScrumMaster removes the impediment, but will not find out if it was effective till the next day, and worse, if the impediment was not successfully removed, it will add another couple days of cycling through till it gets resolved.  This is not very agile!

 

A ScrumMaster will have no choice but to pre-define a clear communication, escalation and implementation plan that both allows flexibility, yet enough structure and guidance to ensure deliverables get done on time.  It will also be very important to truly have a self-organizing team.  If you can’t be in the same presence and time zone of your team, you will really have to rely on them to be self-organizing, efficient and effective.  This means you have to carefully select a good team or work with one that you can trust.

 

You will also need a clear articulation of what it means to be “done”.  Use good software tools that will allow you to implement continuous integration of builds, source control and test driven development to ensure that the software being developed and delivered in each Sprint has been through the necessary QA before being released to the customer so that done is “done”!

 

This is hard and expect to lose sleep, but if you can balance both having a clear and well thought through coordination procedure and process, while still allowing the flexibility and agility that Scrum is known for, you may just get the successful results typical of Scrum when done right, but on a global scale.