Advice: large, distributed team

Last post 07:53 pm February 6, 2018
by Ian Mitchell
2 replies
12:13 am February 6, 2018

Hi there,


I've just joined a team which is [very] loosely following the Scrum framework and would love to get some advice from you all if possible :)


Context: the team is part of a large program of work that has been running for 2-3 years using waterfall.  They didn't deliver what they set out to so the program changed direction, creating the team I'm working with to focus on generating documents for customers.  Unfortunately, the team is in a position where they've given fixed scope, dollars and time - not ideal - but I'm working with the team and the outer circle to try to reduce some of the top-down pressure.


This team is distributed - we have a Product Owner, 4 BAs, 1 Iteration and 2 Design Leads in Australia (where the business is based) with 1 Design/Development Lead, 5 X Developers and 5 X Testers in India (5.5hr time difference).  I'm reluctant to say they're operating even though they use the same backlog and sprint board because they have not had any shared planning sessions, retrospectives, only the development team estimate etc.  To add further complexity, the development side of things is a fixed outcome arrangement with a vendor so I have little to no scope over how they choose to deliver the agreed outcomes.


My time here is limited to 4 weeks so, after a week of observing, getting to know the team (mostly Aus based) and making small changes here or there, whilst educating, I'd like to get an operating rhythm going including the usual Scrum events.  I'm also spending a lot of time trying to help the people in the outer circle understand that their approach may be doing more harm than good (can go into more detail if required).


I know a lot of you will have worked with large, distributed teams in the past so can you shed some light on your approach to creating a more inclusive environment, particularly when you've had limited time to work with.  For example, would you try to split the teams into smaller scrums and how did you approach retrospectives?  The reality here is that they're operating more like two separate teams albeit with a single backlog and minimal structure.


All feedback is welcome.




12:15 am February 6, 2018

Sorry, a few typos in there :(

07:53 pm February 6, 2018

How about focusing on matters of transparency first, so there can be a clear and shared understanding of the current state of practice and the value being delivered? If Scrum events were to be attempted what information (e.g. Definition of Done, backlogs, burn rates, increments, history and projections) would be available to help people inspect and adapt?