At our recent event, we discovered the 'new rules' of outsourcing. I opened the floor to our attendees, finding out what they really wanted to know about outsourced agile teams:
When does outsourcing work really well? What are your top tips for making outsourcing work efficiently?
"Outsourcing is a partnership and partnerships work well when they are based on trust and constantly nurtured by frequent, open communication. I would focus on making outsourcing “effective” rather than “efficient”.
For example efficiency might suggest cutting down on travel between sites because it costs money whereas I would say that forming strong collaborative relationships with each other is really important for working together through future challenges."
Does the Product Owner need to be from the client company?
"In a word, yes. If it is worth building with an outsourcer, it is worth building well and if it’s worth building well you want constant control of what is being built and you want someone employed by you, that owns the solution."
How do you find the right Product Owner and keep them sane through an agile development?
"First and foremost a good Product Owner really owns the product. They are passionate about it and can articulate a clear vision for its future direction. They need to have the respect and trust of a wider stakeholder group and at the same time be able to take on a wide range of view and needs and incorporate into a clear future roadmap.
For me, this is the single most important role and so the best advice I can give is take it really seriously. Don’t pick somebody because they are “familiar” or have some free time. If the person best suited has too much other work on then seriously consider whether you are taking the product seriously enough if you don’t free up their time to give it some real focus. It can be hard to fine one person who has all the characteristics of a great product owner and sometimes having a full-time proxy product owner or business analyst to work with the team on a more detailed level can be a useful complementary role if the Product Owner isn’t particularly analytical."
How do you manage the business' expectations from a service level standpoint?
"Quality shouldn’t be a variable. A good partnership will result in a robust product that is resilient. Once you are managing the relationship through service level monitoring and service credits, something has already gone wrong. Hold a drains-up meeting and discuss where each other’s expectations are not being met. What often happens is that during the build technical debt is built up and short-cuts are taken then this is forgotten when the product goes into producing and the chickens come home to roost."
How can you manage staff reactions to sourcing worries
"Our experience is that honesty is always the best policy. Be honest with the staff but also be honest with yourself. Is outsourcing going to solve a cultural problem of will it be moving it to arms length, where it will never be solved."
How can you REALLY protect IP with an outsourced IT team?
"It is difficult to completely protect IP. I am not a solicitor so this is purely my opinion: There are more protections available from an outsourced partner, whose business is reliant on maintaining a reputation of integrity, than with ex-employees who may leave to start a competing product or work for for a competitor.
The three things to check are:
1. The outsourced partner is not in your industry and are unlikely to compete
2. You have an IP clause in the contract that clearly delineates who owns what IP
3. That the outsourcer has IP clauses in their employee and supplier contracts
Use a solicitor who has IP experience to review the contract."
Why when you outsource do you not always get what you want?
"Part of the problem is that it is difficult to know exactly what you need up-front. The best situation to be in is to be in a long-term outsourcing partnership where you can constantly adjust what you are getting (and how you are getting it delivered). Another problem is that what you want can be lost in translation if communication is very document focussed (write a requirements document and hand it over). Focus on constant communication, collaboration and shared understanding."
As a trainee scrum master, how can I lead the dev team without them feeling like I'm 'micromanaging'?
"Being a Scrum Master is very different from traditional project management and the likelihood is that if the team feel like you are micromanaging them then you probably are. The leadership in a Scrum Master doesn’t come from telling people what to do but in explicitly encouraging the team to use their own judgement to make decisions while helping them to consider things they may not have thought about and keeping Agile practices front and centre.
If you find yourself with a clear view on what should be done - try to hold back and let ideas emerge from the team before you give your views. If you’re personally convinced that a bad decision is being made even after you’ve given your view then sometimes letting people learn from mistakes is more powerful than over-ruling (you may be surprised with the result!).
If you’re really concerned that it’s going to have a big impact encourage the team to test the idea somehow in a way that is less risky and can be adapted later as you learn more."
How do you 'sell' uncertainty as a benefit?! (you don't need to know NOW)
"I don’t see uncertainty itself as a benefit - more an inevitability. It’s accepting that uncertainty is inevitable and adjusting your process and behaviours to deal with it (rather than fooling yourselves that you really know much more than you do) that gives real benefit.
In order to sell the benefits you first need to help people understand the degree of uncertainty they are really working within and once their eyes are open to this then techniques for dealing with it (like deferring decisions until later when you can make a more informed decision) become more intuitive and slightly easier for people to accept."
If you outsource overseas, what considerations should you make about time zone and language?
What is best practice for geographical and timezone distributed teams?
"Every thing that doesn’t make communication easier and gets in the way of a continuous flow of work is another obstacle to productivity that will slow you down. I think that geographically distributed teams can work if you invest in getting to know each other and make communication a central theme of how you operate. My personal view is that if you additionally introduce language barriers or time zones where the over-lap in the working day is small then you lose the ability to effectively work together in an Agile way and so I wouldn’t recommend going this far."
How do you find new partners to work / outsource to?
"Once you have a clear idea of what you are looking for then the steps I would take in order are: (if call Unboxed Consulting isn’t an option) ask friends to recommend someone to talk to, asked your personal network, post a question on LinkedIn, tweet, see who’s sponsoring meetups and conferences in your field in your location, Google and ask your personal network on Facebook,"
How best to do long term budgeting / planning in an agile environment where requirements / design etc is not yet known?
"This area is a great example of where thinking that you know or can “plan” everything you need to make a detailed decision up front can lead to a false sense of certainty and very bad decisions. There’s no single right answer but since you’re working with a very large degree of uncertainty the process you go through and outputs you produce should recognise that. I am a fan of a technique that Dan North introduced me to called Blink Estimation. You can read about it in detail here".
How important are 'tools' when working in a distributed team? Which ones do you like? What are the best tools to use to engage your offshore team with the in-house team?
"Of course tools are important but they are just “tools”. They most important things are communication, familiarity and understanding and any tools you use need to genuinely support these. We use a variety including xxx but would encourage you to experiment with different tools and allow teams to choose what suits them best. Team choice is much more valuable that a big tool selection exercise with a mandated “right" tool for the company or spending lots of money on comms tools that aren’t really solving people’s day to day problems.
Having a fancy high quality video conferencing suite in each location that is shut away in meeting rooms is not as useful as Skype that is always on and active between team members."
Multiple teams working on the same product. The product owners are shared across teams. Is there a way to make this work efficiently? The teams are not in the same office.
"I've seen this work and scale best when different teams are focussed on different functional components of the product. This limits the coverage of the product that any one developer needs to have and reduces the overlap between teams. It can sometimes be useful to add proxy-product owners or business analysts for each team who are able to take a more detailed view and make quick local decisions if the Product Owner is spread quite thinly across a larger product."
What is Agile for non-beta stakeholder?
"Assuming the question is asking how do stakeholders engage with an Agile process that is beyond Beta, the two obvious touch-points are attending fortnightly show-and-tells and engaging with the product owner, formally in prioritisation and story generation sessions and informally over a coffee."
Is it best to share your work environment with offshore team or share theirs? Who should visit who?
"Any investment in understanding the other’s environment is worth the money. Spend as much time upfront in each other’s environment as possible - having the whole team visit for a week of two at the start can seem expensive but can reap huge rewards later with communication barriers being more technical due to distance rather than because people are strangers that haven’t formed effective working relationships. Arranging for one or two people to be regularly working in each other’s location for a a couple of weeks (different people each time if you can) also really helps break down the barriers between the two groups."
What book do you recommend reading in order to learn more about managing distributed teams?
• Waltzing with Bears: Managing Risk on Software Projectsby Tom DeMarco and Timothy Lister
• Peopleware: Productive Projects and Teams by Tom de Marco and Timothy Lister
• The Principles of Product Development Flow by Don Rinertsen
• The Goal: A Process of Ongoing Improvement by Eliyahu M. Goldratt
Where did you get that crazy shirt from?!
If these questions have sparked any queries and you'd like them answered, feel free to tweet me @richardstobart with the hashtag #agileteams.