Tag: Agile

Yes! – but you have to do things very differently, see below for top 10 tips with sourcing experience in Hong Kong, we scaled the team from 0 to 80 vendor developers in 3 years

1) Accept that Scope would be uncertain, at the beginning, we tried to put Product Backlog (or Minimum Viable Product) as part of the contract, but it is not helping as we change the order, / details of product backlog too often, I would advise not to mention the scope at all in the contract, due to this one, we changed contract from Statement of Work (SOW) to Work Order (WO)

2) The WO is by sprint, we specified the name of people in the team (or else one vendor would quite often change the developer without telling us), their standard daily rate (we have different roles like Mobile Developer, Senior Mobile Developer for different rates) , usually we have one WO for 4~6 sprints , but sometimes we have like 6 month to one year for established product/ team

3) We internal staff interviewed all developers / Scrum Master before onboarding them to Scrum team , quite often the vendor themselves have no idea what Agile / Scrum is and they do not know how to find the right people (e.g. getting specialists that refused to work on other parts of software development ) , this “body shopping” way of engaging vendor has a high rate of success or a certain vendor Scrum Master + Development would start to do some crazy stuff, like getting 2 days pre-planning workshop before the sprint planning, asking a detailed requirement document of hundred of pages before adding product backlog items to the Product Backlog, even the Product Owner is no happy with the Increment / product backlog item, the Scrum Master would call it “Done” and actually report it that way

4) We have a clause that we can end the contract with 1-month notice, and we have the right to request replacement of Developer and Vendor must get new developers within 1-month time, this is the an extreme case that thing do not work out

5) We have a weekly catch up with vendor for latest recruitment status / request from developers like computer equipment / tools

6) We usually inject our own internal Scrum Master or developer to the team if possible, for both scrum adoption, and retaining the domain knowledge, as our internal team has much better Scrum experience (the ratio is about 1 internal developer vs 6 vendor developers)

7) We treat the vendor developer as part of the team, they have same say of the way how the team works, architecture/ technical design, they can equal say in the sprint retro, they have our company email, we sit together as a team, and they would have the same equipment / tools as internal team, besides contract, there is almost no difference to the internal developer, quite often the Product Owner / Business side has no idea which developer is from the vendor, we also engaged all developers to internal Town Hall / team meeting / lunch gathering / etc…

8) One of the important things is that we keep stressing that Vendor need to provide their team with training, Scrum related and quite often soft skills like Communication / Presentation

9) It is true that is quite difficult to get agencies to work in the above way, so far we have more success with one of the vendors only, other vendors keep trying to say they want to operate the same way but they have some major issues onboarding the team like the way requested

10) Internal staff would take ultimate take responsibility/ accountability, we never blame the vendor for anything, the whole Development team and some case even the whole Scrum Team take responsibility together

Havard Business Review posted an amazing article Embracing agile for agile adoption by Jeff Sutherland (co-founder of Scrum), Darrell K. Rigby and Hirotaka Takeuchi ( author of New Product Development Game which inspired Scrum), it is specified written with executives. Quoted:

.When we ask executives what they know about agile, the response is usually an uneasy smile and a quip such as “Just enough to be dangerous.” They may throw around agile-related terms (“sprints,” “time boxes”) and claim that their companies are becoming more and more nimble. But because they haven’t gone through training, they don’t really understand the approach. Consequently, they unwittingly continue to manage in ways that run counter to agile principles and practices, undermining the effectiveness of agile teams in units that report to them.

The Article suggested that leaders should do the followings:

1. Learn How Agile Really Works

2. Understand Where Agile Does or Does Not Work

3. Start Small and Let the Word Spread

4. Allow “Master” Teams to Customize Their Practices

5. Practice Agile at the Top

6. Destroy the Barriers to Agile Behaviors

A really nice article and a must read for all leaders who want to adopt or further adopt Agile!