Managing such this type of team is no different than any other complex distributed virtual team.
1) Governance: get all the teams working from a single sheet of strategic music (HOW them implement is their decision) otherwise you will continue to experience too much organizational (team-to-team entropy).
2) Program/cross-team Trust: Trust is built through face-to-face meetings (early on) and takes time - scheduling either face-to-face meetings or conferences on some regular basis (the more distant the teams the fewer you'll be able to do physically), can also leverage video meeting technologies (i.e. vidyo, netmeeting, skype for business, skype, etc.) on a more frequent basis. To ensure folks are all working on same plan, the lead PM should implement the "Master Kanban" board from which all sub-teams driver their Kanbans/Sprints. RRP's should be frequent, regular and scheduled so there are no surprises.
3) Accountability: hold folks accountable, whether it's good stuff or bad... communicates that no one is special. Definitely cheer the good and definitely help those who aren't cutting it to improve but if they continue to not deliver you GOT to deal with it.
4) Master repo: maintain a master repo (used by testing & deployment) that pulls from all development repo's (sub repo's constructed by what makes most sense). Ensure you have rules set accordingly for pushes such that ALL pushes are tested prior to allowing that push to be integrated onto the master trunk version.
5) Continuous Build/Test: gospel!!! must have or else!!!
6) Design review whenever possible (doesn't have to be crazy, stickies on the wall, take a picture, quick document the workflow/etc.) just so everyone understands the goal, the intent and the initial roadmap.
7) Code reviews: must do prior to any push to master repo
8) Code base: be smart, be practical, this isn't supposed to be a death march but have a test(s) for each capability/function to verify it works as intended/designed
9) Management/PM's quiet in development team's RRP
10) Management/PM's have their own separate planning cycle and stand-ups that don't involve developers
11) Owners/Product Managers: push back on management but ALSO on development teams to challenge the initial response... Management always wants more than can be delivered and developers always cry that too much too soon.... Truth is in the middle.
12) If this is a long-term gig; have regular large conferences/team meetings where folks get to show-off their deliverables and how they were successful. Good work deserves recognition. Others can learn and improve.
13) Roles & Responsibilities: ensure that everyone assigned to the project/program understands their role & responsibility (foundational for accountability). For developers, there should be a common Developer's Agreement (deal with IP, etc.) for the overall project but there should/could be a similar agreement for each company/contractor if you have multiple teams working a single company/contractor's code.
14) Agreements: have your NDA's and IP management agreements in place before the work starts
Slashdot Mirror
Managing such this type of team is no different than any other complex distributed virtual team. 1) Governance: get all the teams working from a single sheet of strategic music (HOW them implement is their decision) otherwise you will continue to experience too much organizational (team-to-team entropy). 2) Program/cross-team Trust: Trust is built through face-to-face meetings (early on) and takes time - scheduling either face-to-face meetings or conferences on some regular basis (the more distant the teams the fewer you'll be able to do physically), can also leverage video meeting technologies (i.e. vidyo, netmeeting, skype for business, skype, etc.) on a more frequent basis. To ensure folks are all working on same plan, the lead PM should implement the "Master Kanban" board from which all sub-teams driver their Kanbans/Sprints. RRP's should be frequent, regular and scheduled so there are no surprises. 3) Accountability: hold folks accountable, whether it's good stuff or bad... communicates that no one is special. Definitely cheer the good and definitely help those who aren't cutting it to improve but if they continue to not deliver you GOT to deal with it. 4) Master repo: maintain a master repo (used by testing & deployment) that pulls from all development repo's (sub repo's constructed by what makes most sense). Ensure you have rules set accordingly for pushes such that ALL pushes are tested prior to allowing that push to be integrated onto the master trunk version. 5) Continuous Build/Test: gospel!!! must have or else!!! 6) Design review whenever possible (doesn't have to be crazy, stickies on the wall, take a picture, quick document the workflow/etc.) just so everyone understands the goal, the intent and the initial roadmap. 7) Code reviews: must do prior to any push to master repo 8) Code base: be smart, be practical, this isn't supposed to be a death march but have a test(s) for each capability/function to verify it works as intended/designed 9) Management/PM's quiet in development team's RRP 10) Management/PM's have their own separate planning cycle and stand-ups that don't involve developers 11) Owners/Product Managers: push back on management but ALSO on development teams to challenge the initial response... Management always wants more than can be delivered and developers always cry that too much too soon.... Truth is in the middle. 12) If this is a long-term gig; have regular large conferences/team meetings where folks get to show-off their deliverables and how they were successful. Good work deserves recognition. Others can learn and improve. 13) Roles & Responsibilities: ensure that everyone assigned to the project/program understands their role & responsibility (foundational for accountability). For developers, there should be a common Developer's Agreement (deal with IP, etc.) for the overall project but there should/could be a similar agreement for each company/contractor if you have multiple teams working a single company/contractor's code. 14) Agreements: have your NDA's and IP management agreements in place before the work starts