The past decade, more work is done remotely than every before, all fueled by technology and globalization. Companies facilitate working from home, outsource more and move work offshore. I think it fits us humans. Before the industrial revolution, there were no offices. People worked from home. Our ancestors were chasing deer in the forest and would probably think we’re crazy sitting inside a cubicle all day long. Working from home gives more freedom, time with your family and less distractions.
The traditional notion of outsourcing projects, whether it’s to a nearby firm or a team on the other side of the planet, is that you need to specify things. Many people believe that in order to outsource a project far away, they need to specify everything. And because it takes time to specify, they are reluctant to engage remote teams. Usually, the idea of outsourcing starts because of time constraints – you don’t have the people or the time to do it inside your own company. So we have a chicken and egg problem.
I’ve been pondering a question all week and need your help: what things do you want to know in order to pick the right (remote) team for your software project? This is not going to be a long blog post, rather I would like to have your views as comments, so others can learn from it. If you have a team, it would also be good to read on and reply, just imagine what your clients (would) ask.
Retrospectives bring benefits to agile teams. They help them improve and deliver value to their customers. And by improving team performance, retrospectives deliver value to your business.
This article is based on chapter from the book Getting Value out of Agile Retrospectives by Luis Gonçalves and Ben Linders. This book contains many exercises that you can use to facilitate retrospectives, supported with the “what” and “why” of retrospectives, the business value and benefits that they can bring you, and advice for introducing and improving retrospectives.
Are there any risks in offshoring? That’s the first questions that comes to my mind when people are afraid of moving work offshore. I think that many ‘risks’ are just perceived (how many things that you were afraid of in your life really happened?). I also believe that this perception can be altered and that certain steps can be taken to reduce the (perceived) risk.
When people across cultures collaborate, there’s always an influence of culture on the communication. When they’re working distributed across the globe, there are other factors that can influence communication. What I always find striking is that people assume there are ‘more’ or ‘less’ cultural differences between one country or another. I always wonder whether it’s true and whether it matters.
I just read a very interesting blog post on managing Indian teams, written by Dutch culture trainer Frank Garten. His article starts with a phrase that I indeed have heard many times:
“People from India always deliver late, and when a project is delayed, they will never tell you but rather say everything is fine”.
We recently launched our new eBook about offshoring and nearshoring : How to Overcome Cultural differences when Managing Offshore or Nearshore teams
In the world of offshoring and global collaboration, there is no topic that is more widely discussed that cultural differences. Or maybe there is one: communication. People with experience in managing remote teams often cite communication as their biggest challenge. But what is communication? And if communication is the problem, where do we start the solution? In most cases, one of the best starting point is ‘culture’ (the others being people and process, which we describe in our other books).
Many methods for product quality improvement start by investigating the problems, and then working their way back to the point where the problem started. For instance audits and Root Cause Analysis work this way. But what if you could prevent problems from happening, by building an understanding what drives quality, thus enabling to take action before problems actually occur?
The series on “What Drives Quality” describes both technical activities and supporting quality activities. Previous articles explored what Senior Management and Operational Management do to ensure that quality software products are delivered to customers. This article describes how Project Management drives quality.
I speak to many people about offshoring and nearshoring. One of the central themes that come up is the move from ‘providing people’ to ‘R&D offshoring’ and ‘collaborative innovation’. Instead of providing people for specific customer projects, companies look at joint innovation.
Products that are developed for a customer, can be sold in the local market of the offshore provider. Software that is developed by the offshore provider for the local market or another customer in another country, can be sold in the country of the customer.
The past year we’ve been working on an online platform, Bridge Teams. I have done a lot of research on outsourcing/recruitment/hiring platforms and would like to get your feedback on the use of this type of services.
Bridge Teams enables companies to select (a team of) A-player developers. Users can find detailed profiles and can request an interview. Many programmers are screened by us and get the label ‘guaranteed’. Once the teams is selected, the team (all employees of a company) will work from our (or one of our partner’s) office. A process manager will be assigned to facilitate the communication between the team and the customer. We’ll manage and improve the team step by step (using a structured personal development process, team activities, training).
I saw the following diagram spread in social media several times in the past weeks. Although the changes go slow, organisation moves in this direction. One element I believe needs to be added to the picture is from ‘office’ to ‘anyplace’. This has a very big impact on the way work is organised. In the 20th century work was where you went. Now work is what you do. Work moves to the people instead of the other way around.