Bridge Global IT Staffing Blog of Bridge Global IT Staffing company.Publishes articles about Global staffing,IT Outsourcing,Offshore and nearshore outsourcing Wed, 10 Dec 2014 06:26:49 +0000 en hourly 1 Remote Interview: Hugo Messer Wed, 03 Dec 2014 05:26:42 +0000 Hugo Messer Continue reading ]]>

Lisette Sutherland, author of Collaboration Superpowers, did an interview with Hugo Messer. In the interview, Lisette and Hugo discuss Hugo’s experience setting up Bridge, starting offices in India and Ukraine, the books he’s published and what does and does not work in managing offshore and nearshore teams.

You can watch the interview on Youtube or listen to the podcast on itunes or Stitcher. Beware that there is a short disruption after a few minutes, after that the broadcast is fine!

]]> 0
The future of work is remote Tue, 11 Nov 2014 12:41:11 +0000 Hugo Messer Continue reading ]]>

The past decade, more work is done remotely than every before, all fueled by technology and globalization. Companiesfacilitate 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. 

Companies that are able to work with people from home, are also able to work with people from any other location on earth. This brings enormous potential. For any job, you can find the best available person, be it an employee, a freelancer or a consultant. You tap into the global talent pool instead of your small local pond. For any project, you can find the best available team, wherever they are. 

Today, many companies are still using the traditional way of working: everybody in the office. Even companies that enable their employees to work from home, feel uncomfortable working with people from other countries. But it’s all a matter of training. The more you do it, the easier it gets. The more people do it, the more normal it becomes.

Sometimes I walk around in companies that offshore parts of their work and I am astonished by what’s possible. Not only do they engage people from dozens of nationalities remotely, those people also regularly walk around in the local offices. It becomes a melting pot of talent and nationalities. Offshoring is second nature, business as usual. They don’t think in terms of local employees, but about getting the jobs done. And for getting a job done you need good people, wherever they are. 

You see that some multinationals are very mature in engaging offshore and nearshore people. Some are still in the learning stages. But all of them do it. All of them become better over time. And all of them do more of it over time. 

The next decade we will see a substantial increase of remote collaboration in many forms. Company boundaries will evaporate, collaborating with people from all over the world will become business as usual. 

]]> 0
How to make specifications for an outsourced project? Wed, 05 Nov 2014 07:15:08 +0000 Hugo Messer Continue reading ]]>

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 experienced the same when I started with outsourcing 10 years ago. Because it’s hard to get your ideas across to other people, especially in software development, you believe specifying everything detailed is the only solution. But nowadays, humanity and software development has evolved. Remote teams became more mature and know what it takes to collaborate successfully with clients from the West. Tools to structure communication have become much stronger and more widely available. And software development has changed.  

 While for smaller projects, specifying every detail might still work, in most cases a more agile approach works much better. Instead of specifying everything, you describe short user stories. These stories you store in a tool like Jira. And every week or two weeks you do a sprint planning session with your team to walk through all the user stories you (and the team) has gathered. In this session, you discuss what the user story means in both functional and technical terms. The scrum master stores the solutions in the tracker in words, supported by graphics or links or diagrams. The product owner (typically onshore) could re-check what was agreed before everything is implemented.

So there is no need for the onshore project manager to specify everything, it We have a project in which I am engaged. The setup we chose is to have a product owner facing customers in the Netherlands. Then we have a proxy product owner, who’s in India, together with the scrum master and the team. As it’s a marketplace we’re building, I gather feedback from the supplier side (as well as from the buyer side). To share the things I learn from my feedback talks, I join the backlog grooming session as well as the demo. In those meetings, I share insights, suggestions for user stories and give my feedback on what we’ve built so far. I have no need to specify anything, this is the role of the product owners. The Dutch product owner does the sprint planning, but remains on headlines and agrees them with the proxy product owner. Then proxy product owner then describes the ‘real work’ together with the team and scrum master. And it works! 

We do weekly sprints and continuous integration, so whenever I learn something crucial on day x, I can oftentimes see it implemented on day x + 1 or 2. To get the team up to speed this way, took us some time. You need to do strong retrospectives, agree on good engineering practices. Above all, you need to have a team that can do the thinking and doesn’t need you to specify everything in detail. But I am convinced that with a strong team and a strong collaboration process, you don’t need to specify a thing and you could start outsourcing your projects wherever the team is located. It’s 2014, not 2004.

]]> 0
What 5 questions do you ask selecting a (remote) software team? Sat, 18 Oct 2014 09:25:26 +0000 Hugo Messer Continue reading ]]> 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.

Imagine you have a certain software project or you need a team of people to work on your project. You have decided that you don’t care where the team is located, as long as you’ve got the best matching team. What are the criteria you use to select this team? What would you ask the team (or the management of the company) to figure out whether they’re good for your project? 

The past years I have received massive RFI’s from companies with 10 pages of questions. That’s one solution. I have also gotten requests from people that don’t care who does it or where the team is located as long as the project gets done. I think it’s important to keep the list short, so you ask the most important questions that give you the answer. It’s easier to decide when you need to compare 5 teams on 5 aspects than 5 teams on 30 aspects. My pick on the 5 things that are important to figure out are

1. For what type of companies in what industry have you worked mostly?
2. What three technologies does your team really master?
3. How would you describe the strengths of your team?
4. What’s the typical process you use to get a project from start to end?
5. What specific things are you doing to make remote collaboration work?

What’s your top 5?

]]> 0
Benefits of Doing Agile Retrospectives Wed, 15 Oct 2014 13:32:09 +0000 Ben Linders Continue reading ]]> 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.

Getting Value out of Agile Retrospectives can be downloaded from InfoQ and Leanpub. Also available as paperback on AmazonLulu, and Barnes & Noble. See also the translated editions, available as eBook in my webshop. More information can be found in the book leaflet.

Actions by the team, for the team

In agile retrospectives you look for improvement actions within the agile team that team members do themselves. Teams are self-organizing which means that they have the power to change the way they work (their process). If they want to try a different way of working, it’s up to them to give feedback to each other, to discuss what happened, to learn, and to decide what to do.

The team defines the actions that they want to perform in the next iteration to overcome issues that they ran into during their last iteration, to work more efficiently and effectively, and to deliver more business value to their customers. Nobody can effectively change a self-organizing team but the team itself!

Product owners can be involved

If there are issues related to handling the backlog, doing planning, or dealing with the needs of the users, we recommend inviting the product owner to the retrospective. Team members and the product owner can together explore the issues, define actions to solve them, and improve collaboration.

In some cases you may also want to invite customers to the retrospective. For instance, it’s helpful to involve them when there have been issues with the sprint review, when the team members and the product owner want to improve communication with the customers, or when you want to explore ways to involve customers more often into the development of the product.

Teams sometimes come up with actions to change the way they collaborate and communicate with current and future customers. Often times, they also want them to change the way they interact with the team, for instance to have them attend sprint reviews or how they provide feedback on the product. It is up to the customers to change their behavior if they discover that it would be more effective; it’s not for the team to decide. Telling this to a team as a coach doesn’t always make you popular but it’s how it works. You can influence people but you cannot change them directly. People can only change themselves!

Team members can agree on how they will change, but individuals cannot dictate what others should do. Change triggers change, so let the action start within the team and watch how it influences others. Have patience: it usually works.

No handovers!

When I started with agile retrospectives, I discussed with my colleagues why we should do them. We already did project evaluations, so where do retrospectives differ and what would be the benefit of doing them? One difference is that agile retrospectives focus on the team, not on the organization. There are no handovers of improvement actions needed.

Project evaluations investigate what happened in the project, and recommend changes for the organization or future projects instead of defining actions for the current project. It’s logical since most of the time a project evaluation occurs at the end of the project. But there’s not much that can be changed in a project once it’s completed. To accomplish the actions, the project team that did the evaluation must hand them over to another project team or other people responsible in the organization for improvement.

In an agile retrospective, there is no handover: The team members will analyze what happened, define the actions, and follow them up.

 Buy-in from the people

You may remember a time when your company announced another improvement program. It would address the business’s needs, and solve major problems that the company was facing. You probably wondered if it would solve your problems, and how it intended to do that.

Instead of waiting for improvement program to solve your problems, why not use agile retrospectives to take control of your own improvement journey? Solve the problems that hamper you and your team, the ones that you yourselves consider important to solve. One of the benefits of agile retrospectives is that they give you the power to do it!

Many large improvement programs fail, but not because of the people who manage them. These professions are usually capable and know how to manage change. And they have assured management commitment and funding. But what is often lacking is buy-in from the workforce, from the people in the projects and teams.

This is where retrospectives take a significantly different approach, as they are owned and done by the agile team. They decide where and how they change their own way of working, instead of having it dictated by improvement programs. Teams collaborate with managers and quality and process professionals to have changes that will last and are valuable.

Teams lead their own improvement journeys

Retrospectives empower the team to control their own destiny. A team uses them to solve problems that they consider to be the biggest hurdles. They can improve at their own pace, doing as little or as much as they consider possible.

Managers should enable and support teams in doing retrospectives. They can ask and expect teams to improve within the possibilities and constraints of the organization, and contribute to the organization’s goals, but it is up to the team to choose how they improve and where they decide not to improve (now). A manager must respect the judgment of his/her employees and rely on the team’s professionalism, trusting them to manage their own journey.

If a team needs professionals who are not part of their team to do their actions, like their manager or a support department then it is up to them to involve them. The team can, for instance, explain their needs, make clear what they expect and why it is important, and how the things that they request will help the team. A team should double-check their expectations: Is the request something that the manager or supporting department is able and willing to do? It is important to know what is feasible in the organization and to have that done, and prevent any false expectations.

Getting benefits from retrospectives

Agile retrospectives are a great way to continuously improve the way of working. Getting feasible actions out of a retrospective and getting them done helps teams to learn and improve, and it bring them many benefits as described in this article.

With plenty of exercises for your personal retrospective toolbox, the book Getting Value out of Agile Retrospectives will help you to become more proficient in doing retrospectives and to get more out of them. You can develop your retrospectives facalitation skills to get more benefits from doing retrospectives and learn more about retrospectives by joining the Valuable Agile Retrospectives mailing list.

More information

Several articles are available that cover the agile topics mentioned in this blog:


]]> 0
How to overcome the risk of offshoring? Tue, 30 Sep 2014 12:12:57 +0000 Hugo Messer Continue reading ]]> 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. Let’s go through the risks that are often cited by people:

1. Knowledge and IP

What most people are fearing here I believe is someone running away with valuable information to start their own company or to go to the competitor with it. Now of course this sometimes happens, but did you ever experience something first hand? What happens to your knowledge when you hire an employee who walks away? Probably you have a labor agreement which forbids the person to take the information to your competitor? But can you really prevent someone from using things that were printed into his brain? And which risk is bigger: someone in India where 1.1 billion people live with probably a small internal market for the products you sell, leaving your team? Or someone in your country where your competitors work next door leaving your team? And is it still real to keep all your IP for yourself? What about companies that thrive on open source? What about companies that open up their business models to engage a crowd to improve on them? 

I believe that the risk of moving knowledge to a remote team is smaller than having it into the brains of people in your own country. To protect yourself from the risks, you can sign contracts as you do with local employees. And you could also think about ways to keep for example your source code on your own systems, while giving the remote team only the parts they need. You give people knowledge and information on a need to know basis. 

2. Communication

Yes, it seems harder to communicate with people that you don’t frequently see face to face, especially if they have a different cultural background. But given the fact that talent is scarce in your own country and many companies move work all over the planet, what choice do you really have? How do you experience communicating to foreigners when you go on holidays? Do you like getting to know the other culture when you travel? How normal has email, social media and other ways of communicating that you never heard of 15 years ago, become? If you approach communicating with remote people with an open, accepting mindset, it’ll work. You will face some communication issues, you’ll learn and over time, communicating to someone in India will be like communicating with a person in your own country.

Actually, I communicate BETTER with someone in India than with someone in Holland often. My management team is in India and they work for me for over 5 years. I can work with them with my eyes closed. When I hire people in Holland, I need to get used to those people, cause they’re new. Over time I learn how to communicate with them. 

3. Project delays or screw ups

They say projects sometimes get delayed when an offshore team works on the project. Sometimes the project becomes a big failure. But doesn’t that also happen when projects are done locally? And how comes the project went wrong, is it because of ‘those foreigners’? Was it the way you organized and communicated? Did you know how to manage a remote team or you assumed the remote team would tell you? And did you experience the delay or screw up firsthand or from stories? People love sharing screw up stories, don’t they? 

I am currently writing a series of books on managing remote teams. And guess what? I speak to many people that made it work. People at big companies and people at small companies. They are positive about the remote collaboration and achieved more innovation, joint market introductions with the foreign partner, new products, faster cycle time and even cost savings. If they can, you can too? 

Projects get delayed or fail because people work on them. Sometimes those people are in your own garden and sometimes they are remote. If they are remote, there is just one ‘secret sauce’: you need to invest time to learn how to work with your new team + how to work remotely. If your guidance is the fear that it can go wrong, it probably will? If you are open minded and practice consistently, it probably will work? 

There are probably more risks that I could discuss here (if you have some suggestions, please leave a comment!), but my common belief is: use an open mindset, think about possibilities instead of risks and get going. Most risks just look like risks and in the end never happen. 

]]> 0
Cultural differences: is offshore or nearshore easier? Tue, 09 Sep 2014 12:46:01 +0000 Hugo Messer Continue reading ]]> 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 visited Spain during my vacation and the past year I have heard several stories about Dutch companies working with Spanish people. Some moved them to their office in Holland, others sent their work to Spain. What I found striking in Spain is the working hours. I was all the way in the south, so in July it’s HOT. Between 1 pm and 6 pm you’d better not move. And that’s what really happens. People close everything from 2 pm till 5-5.30 pm. I was used to the timings in France, where they usually close between 1 pm and 3-3.30 pm. In Holland, 2-6 pm are working hours. 

I heard some stories from companies who got Spanish people into their offices. They find their siesta so important that they just would demand it. Having a team of 4-5 people makes for a strange cultural change inside your own office as a big part of the team just stops working for several hours. Hours that you presume are productive, important working hours. 

People say that working with India is harder than working with people in Eastern Europe, because the culture is ‘more’ different than with Eastern Europe. The same is said on Spain. I found some characteristics with Eastern Europeans as well. One of the things I have experienced many times is that they are comfortable speaking up and telling you things can be done differently (or just that you’re dead wrong!). The flipside is what I call ‘heals in the sand’ > people can just take a stance and stay there, no movement. In India, people are often uncomfortable in confronting you when they think you’re wrong. They are also used to getting told what to do. 

When I work in a team, there are several individuals. To become an effective manager, I need to learn each team member’s strengths, weaknesses, behaviors, values, convictions, dreams. By knowing my team members well individually, I can create understanding among the team members, distribute tasks and roles based on strengths.

In this last paragraph, did I describe a local team or a distributed team with people from different cultures? I had in mind a local team, but read it again and you’ll see that the logic is the same for a distributed inter cultural team. The key is in understanding each person and in case of foreign team members, that means taking his cultural background into consideration (but that’s not the only part of ones behavior). 

I believe it doesn’t matter where the person’s from. What matters is that you accept the fact that there are differences. Based on this acceptance, you try to understand what the person’s strengths, weaknesses, (cultural) values and drives are (as opposed to clinging to ones own cultural values and expecting the foreigner to adopt those values). With this understanding, you can create a cohesive, productive team. 

So is someone from Spain or Ukraine easier or harder to work with than someone farther away? It depends. On that person. On you. On the maturity of your organisation. And on the way you manage the (cultural) differences. 

]]> 0
2 Golden tips on how to manage an Indian team Thu, 04 Sep 2014 06:59:05 +0000 Hugo Messer Continue reading ]]>

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”.

Frank gives some general rules of thumb to change your own behavior (as opposed to trying to change the other’s behavior):

Practical advice therefore for the Western project manager is to

  • Say clearly what you expect of people, how to carry out their work and how to report back to you (on what, using which medium, when, etc.)
  • Describe work processes on paper, and even practice work processes with the people who carry them out
  • Do not expect people to be creative and pro-active. Explain them very explicit, and very often, what ‘creative’ and ‘pro-active’ means to you. Be very explicit about the fact that you want them to think out-of-the-box and voice their opinion. Help and encourage them often to do so.

  During my 9 years working with Indian teams, I have found that people tend to choose one of 2 paths to solve the cultural gap with Indians: either they specify everything until the last dot OR they try to develop an open and entrepreneurial culture within the team they collaborate with.

      I won’t argue that describing every detail to an Indian, will work. The issue is though that it’s frustrating for a Westerner to do so (maybe even more for the northern europeans than the Americans). We’re used to having people come up with their own ideas, giving a view on the outcome we expect, give them the conditions and let them figure out their own way to achieve the desired outcome.

     In a software project, having to specify every detail onshore takes a lot of time. And even if you do this, it’s likely that you still won’t get back exactly what you described. 

So the approach that I have found to work in our company is twofold:

A. select people and develop people on 2 core values (we have 6, but these 2 solve the puzzle described in this article): responsibility and openness. 

B. choose an agile process

A. Selecting and stimulating openness and responsibility

    Dutch are open at the risk of being very blunt. Indians tend not to be open, mainly to ‘keep the peace’ (resulting in a friendliness that I personally love). As Frank describes, it’s important to communicate why you find this important time and again. When you select people that are more open than the average and train them on openness, they will open up. 

     Because of the hierarchical society, people are used to getting instructions instead of taking 100% responsibility for their own work. Hire people who feel responsible for the work that they produce (one simple question that helps you drop many people within a minute: do you tend to ask for permission upfront or forgiveness afterwards?). In our company, we put every programmer in direct contact with a customer from day 1. No excuses, you’re all naked and you have to make your customer happy. Your performance is measured by the review you get directly from your client and you’re responsible for getting the review. Your salary also depends on the review you get. In this system, people who avoid responsibility won’t stay long. There are no project managers or testers to improve bad results. 

B. Use an agile process

Scrum has two central elements that help avoid the rigid solution of describing everything in detail:

  1. requirements are specified by the whole team (team+scrum master+product owner). B. there is a meeting rythm in which every day the team discusses what they’re working on and where they’re stuck and regularly the way of working is reviewed. 

Conclusion: If you select the right people and instill an agile process, delays in projects will happen as frequently as you’re used to with your local team. And if there is delay, you’ll know and you’ll have plenty of opportunity to steer your project in the right direction. 

I have written several books about this topic, if you want to get deeper insights into these two tips, you can download our books here

]]> 0
How to Overcome Cultural differences when Managing Offshore or Nearshore teams? Wed, 03 Sep 2014 12:02:42 +0000 Hugo Messer Continue reading ]]> 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).

The goal of this book is to give you practical insights on how to manage cultural differences when managing offshore or nearshore teams. Culture is a ‘soft’ topic, more a concept than something driven by analytics and data. There is no step by step ‘how to’ approach to deal with cultural differences. The only thing to do for people working with other cultures, is to learn as much as possible about the other culture. To make this learning effective, this book presents articles on how to understand culture on a more general level as well as real life experiences on cultural differences for a specific country. All authors come from different backgrounds and write from their own experience.

In the first chapter, Bert van Hijfte, a Dutch culture trainer specialised in Indian culture, writes about culture and communication in the outsourcing industry. Bert has trained many teams at companies like HCL, Aegon, Achmea, in various countries around the world. An industry veteran, he describes the way the outsourcing industry evolved in the past decades and how the current world of high attrition, influences the cultural divide. He cites the famous book of Hofstede and uses this to explain how to approach the cultural differences.

Chapter two is written by a famous cross cultural author from the US, Gayle Cotton. She has written a bestseller ‘SAY Anything to Anyone, Anywhere! 5 Keys to Successful Cross-Cultural Communication’. Gayle describes a global ‘etiquette’, a set of guidelines for behavior across different cultures.

Chapter three is written by Rajiv Mathew, head of Marketing at Compassites Software . He is a hands-on technology marketing & communications professional with proven expertise in multiple facets of the marketing spectrum. Rajiv describesvarious Cultural aspects in international business.

In the forth chapter, I describe the magic of ‘empathy’ to bridge cultural differences. Based on my own experience, I see a mismatch between technologists and empathy. I describe on what levels (team, company, product, culture) stimulating empathy can improve the odds that globally distributed teams succeed.

Chapter five is written by Natalya Veremeeva. Natalya lives in Ukraine and has worked for several outsourcing providers from Ukraine. She writes a story from the heart about her perception on Ukrainian (and in the broader sense: Soviet) culture. The guidelines she gives make it easier for any Western company to understand the intricacies of Eastern Europe.

Ged Roberts, describes the cultural differences between Dutch and Indians in chapter 6. As a native Brit, he can reflect on the differences from a ‘neutral’ perspective. He zooms in to some specifics about each culture, which we can use in our daily collaboration between India and the Netherlands.

Chapter 7 is written by Jennifer Kumar who, originally from the US, lives in India since 2011. Jennifer organizes many trainings for Indians about the US culture. In the article, she gives guidelines on how to effectively give and use trainings. This gives us insights in getting the maximum value from a training and gives trainers details to pay attention to while giving a training.

This is the forth eBook in a series of eBooks that will be published within a couple of months’ interval and later on into one printed book. These eBooks are being written through a crowdwriting project and the authors are experts from all over the world. We would appreciate your review on Amazon.

If you are interested in the upcoming eBooks or are an experienced practitioner who would like to contribute with your knowledge, please send an e-mail

]]> 0
How Project Management drives Software Quality Fri, 22 Aug 2014 11:45:13 +0000 Ben Linders Continue reading ]]> 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.

 Understanding what drives quality enables you to take action before problems actually occur, saving time and money.

 An earlier version of this article has been published on as What Drives Quality: Project Management. There is also an eBook available for download: What Drives Quality. This book explores software quality practices throughout the full application lifecycle.

 Managing Projects

 With project management I mean managing of projects and programs that include software development and delivery. This can be waterfall projects, RUP, or Agile project Management; the basic principles of project management and their contribution towards software quality is needed for all these kinds of projects.

 Project managers can use specific project management methods or certifications (eg. PRINCE2PMI or IPMA), these methods describe the quality activities that should be performed. Also the CMMI includes process areas that cover project management and the quality activities that are typically performed in projects.

 Factors that drive Quality by Project Management are:

  1. Decision Making Capability – The ability to balance quality, time, cost, and functionality and to make timely decisions that involve the right people. Also to assure that decisions are communicated and that the work is followed up to completion.
  2. Project Portfolio Management – Planning and tracking of the set of projects, including project steering groups and all decisions made to start, continue, cancel, and conclude the project.
  3. Project Management Capability – Skill and experience level of project managers.
  4. Risk Management Process Capability – Awareness of project risks, the maturity of the process, and the capability of managing risks.
  5. Planning Capability – The ability to estimate, plan, and track projects with respect to the quality of the delivered product.
  6. Scope Stability – Impact of major changes in the projects (e.g., those related to stability of the products to be developed), the development teams involved in the projects, and major changes in project funding or delivery dates. These changes are often related to changes in the product roadmap.
  7. Schedule Pressure – The way deadlines are used to put pressure on projects and people to deliver on time.
  8. Operational Overview and Insight – Insight into the status of ongoing projects (e.g., processes used, documents delivered, quality of the documents).
  9. Operational Line Management – Activities done by department managers in their role as responsible for the short term activities.
  10. Project Management Process Adherence – Checks (e.g., audits or assessments) to determine whether the baselined processes are being followed and if they are effective and efficient.

Decision Making Capability

Project Managers are expected to take decisions that are needed for project to deliver and meets its goals. This can be decisions about what to do, when to do it or how to do it. Depending on the project management method that is used and how the project is steered and monitored, there can be big differences in which decisions are taken by the project manager, and which are taken by members of the project team, or by stakeholders.

For instance, in an agile project, the content of each sprint is decided in the planning game. The Product Owner and team discuss the User Stories, estimate the work involved, and decide which ones will be included. The planning game must decide about product quality that is required, since this can have much impact on the work that needs to be done. Aspects of quality are the knowledge and skills that are neededto develop the software, the quality activities that need to be done (eg. pair programmingreviews ortesting) and the process that will be used to do the work. Decisions can either be documented on the scrum board, or in the Definition of Done (DoD). Retrospectives can be used to look back on decisions that were taken in the planning game and stand-ups, and to continuously improve the capabilities of the agile team to manage their work.

Do we still need projectmanagers to manage projects with agile teams? Yes, but their role will be different. Project managers can for instance organize the coördination between the project teams (eg. with a scrum-of-scrums), to ensure that the subproducts can be integrated and delicered. In larger projects they will do the delivery planning, to ensure that project deliveries are aligned with product roadmaps. And they have to align the project with all the stakeholders, like project sponsors, line managers, and product managers, where this is not done by the Product Owner.  

In the end, a project manager is also responsible for steering product quality in agile teams, and for the reporting of his/her agile project. My opinion is that there is still a need for project managers in agile, where they support the primary planning mechanisms from agile methods like Scrum.

Risk Management

The quality of the software products is related to the way that risks are managed in projects. Product quality risks should be identified early and continuously, and actions taken to either reduce that change that the risk occurs, or mitigate quality impact.

In agile, User Stories that pose a high risk are usually done as early as possible in the project. It is better to deal with risks early, while there is still room to deal with them. Spikes are a great way to deal with risks in projects as early as possible. They decrease project disturbances, and help agile teams and product owners to get quick feedback about product possibilities. To reduce risks and improve quality, agile teams shoulddevelop their capabilities to deliver code with high quality.

Schedule Pressure

Several good books have been written on managing time and people on projects, like The Mythical Man Month from Fred Brooks and Peopleware from Tom DeMarco and Tim Lister. They make it very clear that (project and line) managers should carefully manage teams, and prevent that professionals are overloaded with work.

My experience is that keeping teams composition stable enables team members to learn and improve continuously. Also XP promotes a Core Practice “40 hour workweek”, which aims to reduce pressure on team members to prevent them from making mistakes that result in less quality.

Why do project managers put time pressure on their teams? I don’t know, and it still surprises me, so I can only guess at their reasons to do it. Maybe because they think that putting pressure on people makes them more productive? That team need deadlines to come up with results? They might see it as bargaining, where they want to find the optimum amount of work to be delivered within a time frame? If you know what drives project managers to put pressure on their teams, please react to this post, and let me know!

Summing up, there are lot’s of good reasons for project managers to reduce schedule pressure, to reduce quality risks with products that are developed. Why it is still done (too) often surprises me.


Project Management can drive quality. By taking decisions that enable the project team to develop software, and by establishing a structure and environment where the team can deliver quality products and services in an efficient way. And by taking and communicating decisions timely so that professionals know what has been agreed with the project stakeholders. Together with Senior ManagementOperational Management and Process Management, Project Management drives professionals to deliver high quality products, on time and within budget, which meet their quality goals.

]]> 2
Positive effects of Offshoring on innovation of Firms Wed, 23 Jul 2014 05:58:26 +0000 Hugo Messer Continue reading ]]> 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. Products can even be developed as a joint investment. I heard someone at a big telecom company from the Netherlands describe this case literally. They had outsourced a big part of their business to a partner in India. They specifically selected the partner on their innovative merits, not only on price or the narrow competencies needed to ‘do the operational job’. They have successfully launched products together and sold products back and forth in their respective markets. 

Many companies also establish R&D centers offshore, especially in India. This can be done in collaboration with a partner or as a captive center. In India there are many highly educated engineers, many even studied or worked abroad. These engineers can contribute substantial value to innovation for companies that are established elsewhere. An interesting case I read in a paper from Ferrazzi Greenlight:

Leveraging Remotely-Located Product Teams
For most global companies, teams located in far-flung parts of the globe are a huge untapped resource for innovation. At a large manufacturing company with whom Ferrazzi Greenlight recently worked, most innovation came from research and development teams located in the United States, despite the firm’s presence in approximately 180 countries around the world and its research labs in more than a dozen locations. Most products marketed abroad included only minor adaptations for local markets. While some of these were successful, many weren’t. Often they were much too costly for the local market. Also, some were developed myopically, without fully understanding local needs
As homegrown competitors in emerging markets started to become a force to be reckoned with, the company began to encourage their own local teams to propose innovations. One such team was located in India, where the overcrowded and poorly maintained infrastructure of roads is shared by trucks, cars, scooters, bicycles, and even livestock. As you might imagine, accidents are commonplace.Using base technology originally developed in the U.S., the company’s research unit in India proposed and co-developed a special strap-on bumper for cars that reduced impact and made fewer accidents fatal. The local team’s superior understanding of the market’s needs – and its price sensitivity – defined the project’s parameters, while U.S. team members contributed technical and testing expertise. The resulting product was so successful locally that the manufacturer is considering marketing it in other emerging markets – but not without getting sufficient input from local teams first
]]> 0
Feedback needed for a new platform Wed, 16 Jul 2014 07:02:54 +0000 Hugo Messer Continue reading ]]> 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). 

The current solution is aimed at software product and service companies and enterprises with large scale (ongoing) software development needs. As it’s hard to find good developers in many countries, companies can hire them outside their borders. The work will then be done remotely from our office (India/Ukraine) or the people can relocate. 

Right now, the team can be assembled by picking individuals based on skills, technologies. The longer term vision is to enable users to search existing teams that have worked together before on a certain domain, industry, solution or technology. 

The main thing I found on comparable platforms is that they all focus on ‘freelancers’. My vision is that although freelancers can take on projects, for larger scale projects it’s not always the best solution. In bigger projects, you want a team to work from one place, because it’s already complex enough to work with 2 locations. In addition, freelancers became freelancers to be ‘free’ > meaning you can’t always rely on their availability as they often have other projects .

Major platforms I have in mind are:

Odesk > this is the biggest platform for freelance work
Elance > recently merged with Odesk, the offering is similar to Odesk

These two platforms work well for smaller scale projects and for time-rich-cash-poor companies. The main hurdle is picking the right people. For that, you need to invest a lot of time (even though the reviews from previous projects help, you’ll get many results or many offers that you’ll need to go through). 

Recently, I found a few variants that aim at solving specific problems compared to the ‘Odesk model’:

Ziptask > adds a project management layer. You pick a PM, the PM picks + manages the team/project. 
Toptal >  pre-screens the freelancers for you. Before you can search for the people, you get an intake with a sales person and they provide the best fit. 
Matchist > you post a project, they match the project with a pre-screened freelancer. 
If you think we miss any other service, please put it in a comment or drop me an email

It would help us a lot to get your feedback on our own platform. Here are some questions I would like you to address (put it as a comment or drop me an email).

1.      What would you say about the concept/value proposition of the staffing marketplace/platform (e.g. is it clear, would it appeal to you)?
2.      How distinct/similar is it comparing to other (known to you) staffing solutions?
3.      What would you say about the user experience, usability, layout etc. of the site?
4.      Would you sign-up/register (please do if you feel like doing so)? Please elaborate
5.      Would you immediately transact on the platform? If not, what would it take to make you transact? Please elaborate 


]]> 0
Work is what you do, not where you go Tue, 08 Jul 2014 12:32:35 +0000 Hugo Messer Continue reading ]]> 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.

Technology has only recently started to facilitate this change (although the Internet is several decades old, only the past 15-20 years did it start enabling people to work remotely). Many tools are developed to support remote work. We move from rigid ERP/SAP environments to specific cloud based tools that support work. We move from server-based Microsoft solutions to Google Docs and Hangouts. When I started my business 9 years ago, I had to build my own project management tool to facilitate distributed software development. Today, if you google ‘project management tool’, you’ll get bombarded with solutions. 

Offices were invented in the industrial era. People moved to the office to do the work together, because there was no other way. Before that, life revolved around the house. I believe life will move ‘home’ again in the decades to come. Office is where you go to meet your colleagues once in a while, to feel the human connection (because sitting alone at home 5 days a week will make you numb). 

And it will matter less and less where you’re doing your work. People can live where they want. Teams will become completely cross-cultural and cross-country. 

]]> 0
3 pitfalls in offshoring and nearshoring Mon, 30 Jun 2014 07:33:50 +0000 Hugo Messer Continue reading ]]> Few weeks ago, I gave a presentation on our company’s event. The visitors were both experienced offshorers and people planning to offshore their software development. One of the questions that arose was ‘what are the pitfalls in offshoring’. While I could write a book about this (and I actually did), I have a top three:

1. ‘Us versus them’ and ‘Parent-child’ relationships

I see collaborations across geographies go wrong most often when an atmosphere of ‘us versus them’ develops. It is human nature to develop this mentality. We always look at other people as ‘strangers’, especially if they are from another country, religion, city (right?). If not, we wouldn’t have wars. If our aim is ‘collaboration’ and ‘partnership’, we have to be weary of this mentality. 

If words arise like ‘those Indians’ or ‘the other guys’, it’s time to talk. The only way to make cross-cultural collaboration work is if it’s about ‘us’ > it’s one team and together we’re trying to achieve something. 

A similar pattern is ‘parent-child’, which often arises because of the client-supplier paradigm. We are the client, so what we tell has to get done. And if they say they deliver on wednesday the 25th of May, then they have to, otherwise we’ll fine them. With this attitude, it is very hard to make a collaboration work out for a longer period of time. 

2. Not enough preparation

I see companies spend months on RFP’s, selecting the country, talking to vendors, trying to make the right choice. And when the ‘real work’ has to start, they go with what they always did. They organize the work as they have always done locally. They rely on the vendor to show them the way (because the vendor has been doing this for years). 

What’s required is a focus on 2 things: selecting the right people and thinking about the’ how’. Everything succeeds if you’ve got the right individuals on your projects. So screen the people (even if it’s a vendor) as thorough as you’d do it recruiting your own local colleagues. And second, once the people are ‘on board’, think about how you are going to communicate and collaborate. Brainstorm on the process (and the way it has to be modified to match the new situation), agree on (coding) standards, fix a meeting rythm of daily and weekly meetings, nail down responsibilities of everyone involved. We’ve developed the ‘Bridge Global Staffing Canvas’ for this, which I can send to you if you drop me an email ( 

3. The black box approach

When I hear people say ‘outsourcing doesn’t work for us’, I get cautious because I hear ‘outsourcing’. My question is always ‘how did you organize the work?’. And in 99% of the cases, they tell me ‘well, I took a 2-3 months project, specified everything until the smallest detail and agreed on a fixed price and date with my supplier offshore’. 

While this way of working is hard with a local supplier, it’s 4 times harder with a remote supplier. In software, it’s hard to specify upfront what needs to be developed. Next, it’s hard to estimate the workload (we’re always optimistic). And then, when requirements and estimate deviate, a lot of communication is needed to agree on the terms for ‘extra work’. 

Instead of throwing the requirements into a black box, open up the black box. Choose a process that’s more iterative, scrum based. Ensure you select the people that will do the work for you. Create a flexible collaboration, where agreements can change upon new insights. 

]]> 0
Reshoring: truth or myth? Tue, 17 Jun 2014 04:29:11 +0000 Hugo Messer Continue reading ]]> Are companies moving IT jobs back to their home country? Is offshoring on the reverse? I often hear people say that it’s the case. It often sounds like ‘hard facts’, so I decided to do a small research. 

The first thing I found is that there is no research. There is hardly any research about the countries people offshore or nearshore to (at least from the Netherlands I couldn’t find any data). There is also no research about the net effect of jobs moving abroad versus jobs ‘coming back’. Maybe a wake up call to some researchers?

I did find some stories on ‘reshoring’. In the US, there is a movement called reshorenow. This is a group of people creating awareness among companies to move manufacturing jobs back to the US. They appeal to people by communicating the benefits of creating jobs ‘back home’. Diving into the movement, it seems to me that there is no hard prove that jobs are indeed returning, although there are individual cases. This also relates to manufacturing jobs, not IT jobs. 

In the Netherlands, the financial newspaper (FD) did a research in 2013, which showed that 10% of companies that moved manufacturing jobs offshore, moves the jobs back to the Netherlands. Another 5% is considering this. I find this research not very convincing, because it doesn’t say anything about the movement in the other direction: which % of companies moves work offshore? And from the 15% that indicated moving jobs back, how many are still at the same time moving particular jobs offshore? Again, it’s about manufacturing jobs. 

The Boston Consulting Group, did a similar research in 2013. This research showed that among manufacturing companies in the US, 54% of companies are considering moving jobs back, while 21 % are actively moving jobs back. 

For the situation in the Netherlands, this (Dutch) article made an interesting analysis on reshoring versus offshoring. They interviewed people from different backgrounds (a director, an economist, a researcher) to comment on the idea that jobs are indeed returning to the Netherlands. It seems that all of them agree the media love to report jobs are coming back, but that apart from some individual cases, the trend is moving jobs offshore, not the other way around. 

From my non-academic findings in the market, I also observe that offshoring and nearshoring are growing in popularity. I also believe that the trend is unstoppable for in Europe, we have a lack of skilled people in certain areas. And more work is done remotely than most people know about (because most media only publish on hypes). I spoke to consultancy firms that tell me most of their report are written by colleagues in India. For certain consultancy jobs, they even fly people from India to the customer. A part of the Dutch highways, is monitored on big screens in an office in Kerala. The Dutch postal service has people in the Philipines screen envelopes that couldn’t be read by their systems, so they arrive in the right address. It seems to me the movement is to the East and not the other way around.

]]> 0
How to Organize Offshore and Nearshore Collaboration? Wed, 04 Jun 2014 04:39:27 +0000 Hugo Messer Continue reading ]]> We recently launched our new eBook about offshoring and nearshoring : 
‘How to Organize Offshore and Nearshore Collaboration’

The main questions came up when managing teams that are geographically distributed are:- How do you organize a remote collaboration? What process should you introduce? How do you communicate your requirements? How do you ensure that people are doing what they are supposed to be doing? Nowadays, the technological infrastructure is in place and there are many companies working with globally distributed teams. At the same time, a lot of people look for a proven way to organize remote work. In this eBook, nine practitioners from different parts of the world and from different organizations share best practices based on their experiences.

In the first chapter, I discuss three ingredients for a successful remote collaboration – process, responsibilities, and performance. Thereby, the crucial questions such as ‘What process works best? Should you use scrum, waterfall, or something else?’ will be answered. As far as process is concerned, I describe the importance of creating clear responsibilities among the team members. Once the process is in place and people know what to do, you need to measure the outcome.

The second chapter is written by Darel Cullen who has a long and varied experience in the software industry in various sectors including nuclear, space, air traffic control, and other industries. He provides guidelines on knowledge transfer and IP protection. Many companies struggle with transferring (tacit) knowledge to their team members at a remote location. The remote team lacks the interaction that a collocated team has. Darel shares some best practices on reducing this knowledge gap.

The third chapter is written by Abhilash Chandran, an Agile Software Development Manager, coach, and practitioner, employed with Xerox Corporation. He shares his experiences on setting up a distributed Agile team in India. His expertise gives you practical insights on what roles should be performed onshore versus offshore, and what tools can best support the Agile collaboration.

How do you discuss, manage, and realize planning and deadlines? In chapter four, Andy Jordan introduces the steps to success in planning your offshore project. Andy is the President of Roffensian Consulting Inc., an Ontario, Canada-based management consulting firm with a strong emphasis on organizational transformation, portfolio management, and PMOs.

In chapter five, Erwin de Bont, who has over 20 years of experience in successfully managing many aspects of the Telecom and ICT Industry, shares his insights on good governance and multi-level KPIs in outsourcing. He uses the example of a large organization that wants to outsource many primary processes to help their customers.

In chapter six, Andreas Brilling and Anuj Kumar describe their concept on ‘how to make the waterfall model work in a multi-shore setting’. While most organizations move to Agile and scrum, the authors describe a successful implementation of waterfall and how to add Agile elements to the waterfall process. Andreas Brilling is an Engagement Manager at Capgemini based in Stuttgart. He has more than 20 years of experience in software development projects in various international settings. Anuj Kumar is a Senior Manager with Capgemini, India, based out of Mumbai. He has been working with custom software development-based projects for the past 14 years. Most of his projects involve multi-shore teams.

In the seventh chapter, Jean-Paul van Wieringhen Borski and Herke Schuffel describe the differences between offshore and nearshore collaboration, and provide suggestions to deal with them. They have developed a framework for organizing nearshore collaboration differently from offshore. Jean-Paul has 17 years of experience in the IT domain. He has spent most of his time in an international environment where he managed several offshore delivery centers. Herke has been in the IT domain for almost 20 years now. He is currently responsible for a business unit delivering application support on custom-built software with extended resource teams in Serbia and Ukraine.

In the final chapter of this eBook, Henk Woolschot, Delivery Manager at HCL, shares his insights on partnership. He draws the line between two kinds of collaborations and gives us a clear picture of when one should prefer a ‘client-supplier’ relationship over a real partnership.

This is the third eBook in a series of eBooks that will be published within a couple of months’ interval and later on into one printed book. These eBooks are being written through a crowdwriting project and the authors are experts from all over the world.

If you are interested in the upcoming eBooks or are an experienced practitioner who would like to contribute with your knowledge, please send an e-mail

]]> 0
How to avoid the talent shortage in ecommerce? Thu, 29 May 2014 10:52:09 +0000 Hugo Messer Continue reading ]]> The past few years, the ecommerce market is booming all over Europe. And consumers plan to shop online even more. Deutsche Post published a research last week, which shows that by 2025, ecommerce share on overall trade in developed countries, will grow to 40%. In another research by Ecommerce Europe (Europe B2C Ecommerce Report 2013 – LIGHT version), it is estimated that the Internet economy in Europe consists of 3,5% of the total 16 trillion GDP of Europe. This percentage will double by 2016 and triple by 2020. 

At the same time, the European Commission estimates that in 2015, Europe has a shortage of 700.000 IT people. This shortage could even go up to 900.000. Even in countries like Greece, where about 24% of the working population is jobless, there is still a shortage of IT people and vacancies remain open. The shortage is biggest in the Northern European countries. 

The question for companies in Ecommerce is: how will you attract and retain talent? The past decades, we’ve all been fishing in the same pond. While there are very few talented IT specialists, we keep stealing them from each other, driving up the salaries. 

One solution is to change the education system. While governments in Northern Europe have tried this, the results are not sufficient. In Sweden, about 3.000 people graduate from an IT education. In the Netherlands, this number is about 7.000. At the same time, the baby boom generation, with many people working in the IT industry, will leave the labor markets. 

My strong belief is that there is only one solution: we have to change our mindsets. We need to start thinking about a global workforce, engaging talent where ever on the planet they live. In countries outside the EU, like India and Ukraine, there is a vast pool of highly educated engineers. India graduates about 300.000 people with an IT background every year. 

To achieve this global mindset, we need to think in terms of talent, not location. We also need to change the way we organize. Of course, it’s easier to manage a person in your office, sitting next to you, speaking the same language and understanding your culture. To work with people remotely (even in the home country) requires a change in the infrastructure, in the systems we use and in the way we communicate. As many companies have shown, this can be achieved. The most extreme example is WordPress. They have over 220 employees working from 190 different locations all around the world. Everyone works from home. 

If you are able to attract the brightest engineers from all over the world and they wrap their brains around creating more value for your company, you’ve got a strong competitive advantage. And you also guarantee that you can stay in business, for your competitors will have a big challenge finding the talent to grow their business. 


]]> 0
Can video conferencing replace physical contact? Thu, 22 May 2014 20:12:31 +0000 Hugo Messer Continue reading ]]> The past months, I have interviewed some 35 candidates for a marketing and sales role in our company. Because I want to save time, I always do the first screening through Skype. I believe this is a better medium than only phone, since you can see the candidate. So I have a list of questions that I go through in maximum 30 minutes to assure that there is at least a basis. 

I am still flabbergasted by the errors I made. With some candidates, within the first minute, I knew there wasn’t a match. And through Skype, I thought ‘wow, this guy knows what he’s talking about and makes a strong impression’. How can we be so wrong, while we see and hear the other person?

In her book ‘wilful blindness‘, Margaret Heffernan writes the following: 

‘Video conferencing distracts all its participants, who spend too much time worrying about their hair and whether they’re looking far, uncomfortable at seeing themselves on screen. The nervous small talk about weather – it’s snowing there? It’s hot and sunny here – betrays anxiety about the vast differences that the technology attempts to mask. 

Physical distance isn’t easily bridged, no matter how refined the technology. Instead, we delude ourselves that, because so many words are exchanged – email, notes and reports – somehow a great deal of communication must have taken place. But that requires, in the first instance, that the words be read, that they are understood and that the recipient knows enough to read with discernment and empathy…It’s extremely hard to communicate well with people you don’t really know, whose concerns you cannot see.’ 

Although I am still a fan of Skype and video conferencing, I believe the key is in the last sentence. Skype can’t replace the physical connection and the ‘human connection’ we only make when we meet in person. Using Skype as a ‘judgment tool’ for interviews seems very challenging (we’d need some research here, cause I still believe it does help to screen out the people we believe don’t match on hard data/background). But using Skype to communicate with people that you know, does seem to work. 

I use video conferencing every day to communicate with my management team in India and the Netherlands. And I believe I can even read people’s emotions, because I know the people. But maybe I am wrong. Having said that, especially in a context of offshoring work to a team far away, it’s required to meet your colleagues at least 1-2 times a year. After meeting, video conferencing will serve you well in organizing the work you need done. 

Margaret also quotes a research to support the above conclusion. In the experiment, people are asked to give electrical shocks to others. The shocks grow in intensity and people are ordered by a researcher to raise this intensity step by step. When people are in different rooms and can’t see each other, 65% of people delivered the maximum shock. when they are in the same room, this number reduces to 40%. And when people had been able to touch each other, it lowers to 30%. Still a shocking number, but it shows that we better meet each other regularly to ensure we really collaborate!

]]> 0
The Business Value of Agile Retrospectives Mon, 05 May 2014 07:14:06 +0000 Ben Linders Continue reading ]]> Agile retrospectives are a great way to continuously improve your way of working. Getting actions out of a retrospective that are doable, and getting them done helps teams to learn and improve. An overview of things that you can use to get value out of your retrospectives.

Together with Luis Gonçalves I have written the pocket book on Getting Value out of Agile Retrospectives which can be downloaded from InfoQ and Leanpub. This book is based on our blog posts on retrospectives (see Luis blogs on retrospectives and Ben’s blogs on retrospectives). We value your feedback, feel free to contact me and let me know what you think of this?

Retrospectives bring benefits to Agile teams, they help them to improve and increase the business value to their customers and the company.

The things that you can do in retrospectives to get business value out of them are:

 The retrospective Prime Directive

 The prime Directive from the book Project Retrospectives by Norm Kerth assures that a retrospective is a positive event. It states: “Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand”.

With the Prime Directive people feel comfortable enough to share their problems, opinions and concerns. Which is important as that assures that retrospectives become an effective team gathering to learn and find solutions for teams to improve their way of working.

If you want to learn more about the theory behind retrospectives, see the book Agile Retrospectives* from Esther Derby and Diana Larsen


I stimulate teams to use the means they already have to make their actions visible. Stick them to the wall at their workspace, put them on their planning board, use them as input in the planning game, etc. For bigger improvements it often helps to define a User Story (describing who, what and why), and plan time to do it. For some examples on visibility, “Continuous Improvement, Make it Visible!“.

We need to  need to uncover better ways to do (process) improvement, and retrospective support that. I prefer to do short cycled improvement, helping teams to develop continuous improvement skills. Teams can self-assess their agility and actually use  use Scrum for process improvement. With improvement (change) skills, teams become agile and lean. and are able to efficiently manage their own improvements and deliver more value to their customers.

How does a Retrospective look?

Different techniques help you to get most out of retrospectives. They are also useful when there is a risk that teams might be getting bored with retrospectives.

Different kinds of techniques that I use are:

  • I use the 4 retrospective Key Questions from Norm Kerth, including “what did we learn?” and “what still puzzles us”. In many of my retrospectives learnings are shared and valued, and the puzzle question has revealed lot’s of tough issues that needed attention.
  • A variant on the 4 questions is to divide a flip-over into quadrants, labeled “continue”, “start”, “stop” and “shout out” (shout out is where you can give appreciation to what team members did). Team members write sticky notes and add them to the quadrants. You can do clustering and dot voting to determine which actions will be done in the next sprint.
  • Actually, there are lot’s of different questions that you can ask in retrospectives. The trick is to pick the ones that help the team to build up insight into the main / urgent issues and improvement potential, and add questions where needed to go deeper during the retrospective.
  • When there are issues in a team that need to be discussed, I have each team member state how they feel about the past sprint in 1 word. Chances are big that at one or more words, with some questioning, triggers a discussion where things are spoken out about the team that often don’t reach the surface. A variant is to use images from magazines or the web, or have team members draw an image on how they feel about the sprint.
  • When there was a significant problem, that the team doesn’t want to happen again, I do a Root Cause Analysis using a 5 times why retrospectives. Often actions coming out of the retrospective can be done immediately in the next sprint.
  • To explore how team members are collaborating, I have them draw a timeline of things that have happened during a sprint. They can use smileys to show how people felt about it. This makes visible where a team faced some tough situations, and where there was high energy and flow. It is also a great way to measure team happiness and improve the team morale.
  • A somewhat similar technique is to ask team member when they felt high energy (flow!) during a sprint, and when low energy. Discussing these moments helps a team explore their way of working, to discover bottlenecks and take actions.
  • One of the most valuable questions that I have experienced in retrospectives is asking why? It gives insight in people’s behavior and their feelings and motives that drive them, helps to find root causes of problems, and reveal the strengths that people have. And helps teams to see common goals, and find ways to collaboratively reach them.
  • You can use a solution focused approach in a strengths based retrospective to visualize the strengths that people and teams have, and explore ways to use them as a solution to problems that they are facing (for a article in Dutch on this, seeVeranderen vanuit je sterktes, da’s anders).
  • You can also use a deck of cards to discuss the qualities of the team members (Dutch: Kwaliteitenspel). This is often useful with new teams, to combine a retrospective with team building, and to develop feedback skills.
  • When time is limited and a team feels pressured, I often do the “perfection game“. I ask team members to rate the sprint on a scale from 1 to 10, and to state what they could do in a next sprint to make it “perfect” and score a 10. Try to limit actions and come to one significant improvement that can be done in the next sprint.
  • A technique similar to the perfection game is the Angels Advocate, a brainstorming technique which stimulates creative and positive thinking. Just as the perfection game you are not allowed to say negative things (that would make it a Devil’s Advocate).
  • When a team has many actions open from previous retrospectives and finds it difficult to implement actions, I use the retrospective to set priorities and remove some of the actions from their list. They come out of the meeting with fewer actions, and feel more empowered to work on the ones which are still open, because they now have a better picture of why these actions are needed.
  • You can use (family) constellation to see how team members and stakeholder co-operate. Have the team members take a role, either representing the team, or a stakeholders that the team interacts with. The members take positions in a room, showing how they feel that the roles relate to each other. Then ask a team member to move, and have other team-members react to that, visualizing the interaction within the team, and with the stakeholders of the team. This can give insight in team dynamics, and visualize collaboration issues.
  • When you have a agile project with multiple teams, you can improving collaboration with the retrospective of retrospective. This is a good way to share learnings across a project, and to solve problems that a project is facing.
  • If you have teams that have more than one customer, maybe even multiple product owners, things are different. Team members are often not working together on a daily base. You can do a retrospective for teams with multiple customers to find actions that will be beneficial for the complete team.

Using these techniques helps to keep teams in a continuous learning and improvement state, making many small steps in delivering more value to their customers.

]]> 0
Building bridges between people – in two ways Mon, 07 Apr 2014 05:30:04 +0000 Judith Weinberger Continue reading ]]> If you have a look at our facebook cover picture, you might already imagine it. Being a Global IT Staffing Company, this does not only mean that we do business on an international level. For us, operating in and between different nations and cultures also involves global engagement in social and ethical matters.

Bridge has its headquarter in India, a country of contradictions. Even though it has developed to be one of the largest economies worldwide, there are still myriad people living in absolute poverty. Despite of growth, the gap between the super-rich and the poor is tremendous. 

How can WE contribute to closing this gap?

Apart from his business-related visions in his early years as a company founder, CEO Hugo Messer had also put a lot of thoughts into this question: “How can Bridge contribute to closing this gap?” The answer was obvious: By being aware of our CSR – Corporate Social Responsibility. For over six years now, Bridge has been engaged in several philanthropic activities. The cooperation with Raksha Society, for instance, supports Indian children with disabilities. Self-made penholders in our corporate design, which are also being sent to our clients, are the result of this project. 

a practical accessory in our everyday office life

On a quarterly basis, Bridge also shows its social commitment towards the south Indian  Saandhwanam Orphanage by providing new clothes and chocolates for these kids.

Education, happy grannies and financial aid

Of course, Bridge also assumes responsibility for its impact on Ukraine’s society, where our nearshore offices are located. As member of Dorcas Aid, we have recently ‘adopted’ Victoria, an ambitious yet underprivileged young woman who now is able to do her studies at Kriviy Rih Pedagogical Institute.

Thanks to Dorcas Hulp, a dutch-based organization, we are able to support a project that fights poverty in old age in Eastern Europe. As a result, a few lovely Ukrainian, Russian, Romanian, and Moldavian grannies are now part of our global Bridge family.

Mrs. Nina Nikolayev, a Russian granny adopted in 2012

Even one social commitment in Africa, called Zidisha, has been added to our CSR list lately. It makes microloans available to poor people.

As you can see, our concept of building bridges between people is not only related to IT staffing and matching our developers with European companies. It also refers to our intention of taking over social responsibility. Connecting with people from all over the world who need help and support, this sometimes creates new ways for individuals, builds bridges to a better life.

Learn more about Bridge’s social commitment:


]]> 1
Self-assessing How Agile You Are Mon, 31 Mar 2014 11:19:20 +0000 Ben Linders Continue reading ]]> Do your teams want to know how agile they are? And what could be the possible next steps for them to become more agile and lean? In an open space session about Agile Self-Assessments organized by nlScrum we discussed why self-assessments matter and how teams can self-assess their agility to become better in what they do.

Becoming Agile over Doing Agile

There are many checklists and tools for agile self-assessments. Some of them focus on “hard” things agile practices, meetings and roles, while other cover the “soft” aspects like an agile mindset and values, culture, and the conditions for agile adoption in organizations to be successful.

We discussed about self-assessing the teams agility at the nlScrum open space. One conclusion was that most attendants had a strong preference for assessing based upon agile values and mindset to explore if and how their teams are becoming agile. This way of assessing distincts teams where professionals have really internalized what agile is and know why they should do it and how it helps them to deliver value to their customers and stakeholder from teams that are only doing agile or Scrum because they have been told to do so by their managers or organization.

Assessing values and mindset involves asking why certain agile practices and rituals are done. It empowers the agile team by developing a shared understanding of the weaknesses and strengths of their way of working and to decide which steps they will take to become better.

Effective agile teams understand the agile culture, mindset and values. That makes it possible for them to improve their development processes in an agile way. They can use the golden rules for agile process improvement to improve by continuously doing small but valuable improvement actions.

Can teams assess themselves?

As the name suggests agile self-assessments are intended to be tools for agile teams. The result of an assessment helps a team to know how they are doing to help them improve themselves. Therefore the results of an assessment are intended to be used by the team alone. They should not be used by managers to evaluate the team performance or to compare and rate teams.

Question is if you can expect that a team can assess itself? It depends as usual :-) . Teams who have just started with agile can find it difficult to take some distance and explore how they are doing.  They also might not have enough understanding of the why and how of agile to really assess how they are doing. In such cases an (external) facilitator can help teams to do their first assessments.

Agile retrospectives are another great way for teams to reflect and improve their way of working (read more on how to do them in our bookGetting Value out of Agile Retrospectives). They help team to learn observing and analyzing their way of working and define their own improvement actions.  Many skills that team members develop doing retrospectives are also usable to do self-assessments, so investing in retrospectives makes sense.

Finally an agile coach can help a team to develop assessment skills, enabling them to do their own assessments in the future. Soft skills matter in IT and agile coaches can help people to learn and improve those skills. Which is also an effective way to help a team to become agile in an agile way.

Agile self-assessments

I like the Open Space Technology (OST) approach, it’s a great way to people to get together and discuss those things that really matter to them. At the nlScrum Meetup about Scrum Maturity Models hosted by Xebia we did an open space session where we exchanged our experiences with agile self-assessments. This is what came up during out stand-up meeting:

I already talked about assessing values over practices and why self-assessments are intended to be used only by the team and not by their managers. In our discussion in the open space and afterwards on the meetup forum several tools and checklists were brought up to do self-assessments and also several models and frameworks were mentioned that can be used to develop your own assessment. Some of them were already on my list of Agile Self-assessments tools and checklist, but there were also some new ones which I added (thanks guys!):

Self assessing your agility

Have you done agile self-assessments? They help you to improve and become more agile and lean? I’d like to hear from you!

]]> 0
Remote teams: why you need them and how to work with them Fri, 14 Feb 2014 12:35:16 +0000 Hugo Messer Continue reading ]]> Two months back, I visited the lean startup conference in San Francisco. One of the talks that I loved was with Matt Mullenweg, the creator of WordPress. He built wordpress step by step in the past years. Today, he has 225 employees working for him from 190 cities around the world. How comes such organisation works, while many companies are too afraid to even hire 1 team offshore or nearshore? 

Last week, computable, a Dutch IT magazine, published an article about the growth of IT-vacancies in the Netherlands. In 2012, the number of vacancies grew with 5%. Now the economy in the Netherlands isn’t strong at all at the moment, a very tiny growth is predicted for 2014. What will happen to the number of IT vacancies when the economy grows with a few % per year again? 

Another visionary speaker at the conference was Marc Andreessen, one of the founders of Netscape in the 90s. He said several times ‘every business turns into a software business in the next decade’. And I think this movemen’t is happening all around us. Retailers are all forced to sell online for they are struggling to survive with their traditional channels. Everyone has a strong pc in his pocket anywhere he goes, moving workers to work remotely more and more. And everything needs to be supported by software. But if we have 123.000 IT vacancies today with less than half the people to fill those gaps and software becomes more important day by day, how can your business survive? 

I believe every organisation will eventually need to move into the wordpress model of organizing. Companies need to become open minded and flexible in the way they engage talent to produce the value they produce. Work is not a place you go to, but a thing you do. If an organisation is able to implement a structure on that thought, they can engage talent from any place on the world. The challenge is this. WordPress was started with this idea and Matt built a business around the global staff model. He could create a structure, device processes and working models around a distributed team. But organisation that have a structure in place have a big challenge in changing the way they think and work. 

The change goes step by step. The first step is to give employees the opportunity to work from home. This forces a company to create systems and structure that enable remote work. Then people need to get used to working with people from different cultures. Channels to attract global talent are needed (where do you find the people?). Methods to screen and select (cultural) remote people. But maybe the most important starting point is opening up to the possibility of enaging remote teams. Creating an open mindset that accepts cultural differences and working with people that are different from us. In the end, if a company gets used to it (like WordPress), it really doesn’t matter where someone is from. It only matters how talented the person is. 

To get you started, we have recently published an ebook on How to prepare for offshoring. Different authors from around the world have contributed articles in which they share their experiences in setting up remote collaborations. 

]]> 0
Does the situation in Ukraine affect nearshoring? Fri, 07 Feb 2014 12:19:40 +0000 Hugo Messer Continue reading ]]> The past weeks I often get questions about Ukraine from people. They wonder whether we notice anything of the unrest in Ukraine and whether it affects the work our nearshore teams do. 

From my perspective, it’s simple: as long as nobody barricades our office or cuts the internet or power lines, business can go on. Our developers love their work and as long as they can do their work, they will. On the longer term, a change in government might affect laws, which may have an impact on the way nearshoring is organized. But the past years, Ukrainian government has discussed changing tax laws and only a very small new tax was added last year. So I am not worried about our office in Kiev and Odessa.

I spoke to a Dutch person working at one of our competitors in Kiev on monday. His remark was that the media make things look much worse than it is from the ground. He lives near Khreshchatyk in Kiev, the street that crosses the Maidan, where protestors ‘live’. He even took some of his customers there, because the atmosphere is friendly and peaceful. A block away, near to the embassy area, there are more unrest, some people are demonstrating with a bit more agression. But that’s just a small square close to a small park. So not much to worry about right now.

Dmitry Portnov, our director in Kiev shared his view too:

As you know, now we have a demonstration in Kiev, and in some other big Ukrainian cities. In Kiev the demonstration is going on in the 2 main streets and it doesn’t  affect the operation of companies. All businesses still work in the same way as they worked 1-2-12-… months ago. Also our government is in a process of negotiations with the demonstrators, so it is not now in a very active phase and I hope that they will be able to find a good decision. So, the situation doesn’t affect me and our employees in Kiev, except one programmer who asked me last week about vacation and he took part in the demonstrations.
About the labor market: it also doesn’t affect the labor market and the situation on the market is still the same as 1-2-12-… months ago. I also monitor the community of IT outsourcing companies and it shows that the requests for services have increased in comparison with the last quarter of last year. As I have seen in Q4 2013, many companies had people on the bench and were looking for projects, but now we have the situation that they need new people and ask other companies for subcontracting. 
If you want to know more about the history of Ukraine that lead to the current situation, watch this 2 minute Washington Post video










]]> 0
How to prepare for managing a remote team? Mon, 03 Feb 2014 04:25:19 +0000 Hugo Messer Continue reading ]]> We recently launched our new ebook about offshoring and nearshoring: ‘How to prepare for managing a remote team?’ We found that many people skip some very important steps when they move work offshore. Most companies spend a lot of time on country and supplier selection and once that’s fixed, they get going. Many problems in communication and collaboration can be prevented, by focussing on some essential steps before ‘doing it’. 

Where do you start when you plan to move work halfway across the globe, to a country and culture you don’t know, several time zones away? What can you do to prepare your company and your people to make offshoring a success? What have other people done in order to prepare for their offshore journey? Typical questions that come up while preparing, are:

·      Which country shall we outsource our work to?

  • What project shall we choose to start with?
  •   Which company suits our needs best?
  • Shall we set up our own captive center or outsource to a partner?
  •  Are we organized well enough to start offshoring work?

Though relevant, these questions are only part of the preparation story. Most people tend to focus a lot on these ‘initiation’ questions at the expense of wondering ‘how to organize’. Preparation is seen as selecting the right country and partner and then ‘just get going’. Many problems can be prevented by investing time in the right organization before the ‘real work’ starts. In the eBook, we try to provide advice on both perspectives, based on experiences from several experts around the globe.

In the first chapter, I describe how to get started. The main questions I answer in this chapter are related to ‘initiation’ and the questions above. The second chapter is written by Patrick van Dun, an experienced ‘offshore founder’. Patrick, a native Belgian, has set up several Asian offices for himself and for his employers. He provides guidelines on the choice of setting up your own remote office versus engaging a partner.

In chapter three, Zhenya Rozinskiy, discusses his best practices for getting the right people on your team. Zhenya has set up several teams around the world. Born in Ukraine, he has lived in the US for the past decade. He presents his views about setting up your own team as opposed to outsourcing work to a vendor. In the fourth chapter, I provide a checklist to determine whether you and your company are ‘ready’ to embark on an offshore adventure.

In the remainder of the book, focus is on the organizing part of preparation. Amanda Crouch from the UK has over 20 years of experience as a management consultant and researcher. She is specialized in collaboration and building partnerships. In the chapter Making Offshore Collaborations Work, she looks at stimulating collaboration at the company and individual level. The central theme is ‘trust’ and she proposes some tools and metrics related to building a real collaboration.

Ove Holmberg, an IT project manager and agile coach from Sweden, describes his concept of the virtual teamroom in chapter 6. He looks at both the tools that can be used for remote collaboration and the physical organization of the office on both sides. Andreas Brilling from Germany works as engagement manager for CapGemini and has led a large offshoring initiative from Australia. In the final chapter, I share my personal story of how I got started with setting up my own offices in India and Ukraine.

This is the second eBook in a series of eBooks that will be published within a couple of months’ interval and later on into one printed book. These eBooks are being written through a crowdwriting project and the authors are experts from all over the world.

If you are interested in the upcoming eBooks or are an experienced practitioner who would like to contribute with your knowledge, please send an e-mail to h.messer@bridge-

]]> 0
Project Management – The Base Rule Fri, 24 Jan 2014 04:45:20 +0000 Binu Kumar Any (company/individual) Project Manager cannot execute a project to meet three goals at once like “High speed-Low cost-Best Quality” !

Project Management Triangle

Any comments ?

]]> 1
Simply Scrum Thu, 23 Jan 2014 10:07:45 +0000 Binu Kumar Continue reading ]]> Scrum is an agile software development framework for managing software projects or application development. Agile just means an iterative, incremental development approach with realistic calculations and self-planned approach. A key principle of Scrum is its recognition that during a project the customers can change their minds about what they want and need.


In Scrum, projects are divided into work units, known as sprints, which are typically one week, two weeks, or three weeks in duration. At the end of each sprint, stakeholders and team members meet to assess the progress of a project and plan its next steps. This allows a project’s direction to be adjusted or reoriented based on completed work, not speculation or predictions. Scrum uses the real-world progress of a project — not a best guess or uninformed forecast — to plan and schedule releases.


Product Owner: In Scrum, the Product Owner is responsible for communicating the vision of the product to the development team. He or she must also represent the customer’s interests through requirements and prioritization.

Scrum Master: The ScrumMaster acts as a facilitator for the Product Owner and the team. The SM doesn’t manage the team. Instead, he/ she works to remove any impediments that are obstructing the team from achieving its sprint goals, and is not a traditional team lead or project manager. The SM ensures that the Scrum process is used as intended

Team Member: In the Scrum methodology, the team is responsible for completing work. Team consist of Developers, QA team members, GUI experts and Team lead. Team size in scrum should fall in between 3-9 peoples.


Sprint planning meeting

  • Happens at the beginning of the sprint cycle to select what works to be done.
  • Prepare the Sprint Backlog that details the time it will take to do that work, with the entire team
  • Identify and communicate how much of the work is likely to be done during the current sprint
  • Eight-hour time limit

Daily Scrum meeting

  • All members of the development team come prepared with the updates for the meeting.
  • The meeting starts precisely on time even if some development team members are missing.
  • The meeting should happen at the same location and same time every day.
  • The meeting length is set to max of 15 minutes.
  • All are welcome, but normally only the core roles speak.
  • During the meeting, each team member answers three questions:
  • What have you done since yesterday?
  • What are you planning to do today?
  • Any blocks or pressing issues? Any such item identified in this meeting is documented by the Scrum Master and worked towards resolution outside of this meeting. No detailed discussions shall happen in this meeting.

Sprint Review Meeting:

  • Review the work that was completed and the planned work that was not completed
  • Present the completed work to the stakeholders (a.k.a. “the demo”). Incomplete work cannot be demonstrated
  • Four-hour time limit, facilitated by Team Lead in presence of Scrum master

Sprint Retrospective:

  • All team members reflect on the past sprint
  • Make continuous process improvements
  • Two main questions are asked in the sprint retrospective:
  • Three-hour time limit, facilitated by Scrum master
  • What went well during the sprint?
  • What could be improved in the next sprint?


Product backlog (PBIs): is an ordered list of requirements that is maintained for a product. The product backlog and the business value of each backlog item is the responsibility of the Product Owner.

Sprint backlog: is the list of work the Development Team must address during the next sprint, those selected from PBIs, from the top of the product backlog by the Development Team. It’s the property of the Development Team

BurnDown Chart : The sprint burndown chart is a publicly displayed chart showing remaining work in the sprint backlog. Updated every day, it gives a simple view of the sprint progress.


]]> 0
Golden Rules for Agile Process Improvement Thu, 02 Jan 2014 12:57:04 +0000 Ben Linders Continue reading ]]> I’ve worked in a multi-site Process Improvement Team that adopted an Agile way of working.The team used a set of “Golden Rules”. These rules helped them to understand the agile approach, and to work together in a smooth, efficient and positive way. These golden rules were formulated based upon principles from the Agile ManifestoEVOOpen Space TechnologySolution FocusedRoot Cause Analysis, and Retrospectives.

The rules that we have used are:

  • Dare to share – As early as possible and frequently
  • The result depends on the team – Not the individual members
  • The one who checks out a task is not necessarily the one who has to finish it
  • The one’s working on a task are the right people
  • You may critique anything, but you may never criticize anyone

This simple set of rules was used throughout the project as a guideline on how we collaborated, they were our team values. They helped the team members to learn and adapt the agile approach, in a very practical way.

Dare to share – As early as possible and frequently

Team members often worked in short chunks of just a couple of hours, whenever time was available in their personal schedules (In Dutch, we applied Het Nieuwe Werken). They produced and updated slides and documents, web pages, news items, or other content. Work items were frequently reviewed, the feedback was visible for all team members. By sharing early we were able to continuously add value to our products, enabling delivery in short iterations.

This origins back to Agile and EVO, iteratively deliver value for your customer. You can use a a wiki as working space (as we did with our team), or a cloud solution like Google Sites, or Huddle. Recently I’ve started evaluating and using Worknetsas a collaboration environment, for the team of

 The result depends on the team – Not the individual members

Team members frequently asked other team members to support them, or to contribute their experience or results from their own R&D centre to the project. This rule helped the team members reminding that we all brought value to the team, at different times and in different ways, using our individual strengths. Since we were all also representing our local R&D centre, this was an important value which helped the team, and the stakeholders to focus upon the contribution to the business unit result, and be open for experiences from other R&D centers. We weren’t competitors but co-workers, and the way we collaborated was beneficial for all involved, and for the company as a whole.

This rule focuses on using strengths, as described in techniques like Theory UAngels AdvocatePerfection GameAppreciative Inquiry and Solution Focused. (I recently wrote an article in Dutch on this subject: Veranderen vanuit je Sterktes: Da’s Anders!).

 The one who checks out a task is not necessarily the one who has to finish it

Team members supported each other, and collaborated where possible. It was ok for a team member to contribute just a little bit to a product, and release it for others to work on. If somebody wanted to contribute to a product that was being updated, then (s)he picked it up when it became available, and then added his/her contribution.  Since work items were checked-in quickly (often within minutes or an hours after check-out), this worked very smoothly.

Also this rules is based upon using strengths, as described for instance by Alistair Cockburn in the Delta Method (which is based upon Solution Focused). To be effective, team members have to trust each other, and assume that everybody is doing the best job they can; this principle uses the Retrospectives Prime Directive.

 The one’s working on a task are the right people:

We saw that when team members had the time, and the energy to work on a certain task, then they added real value to the product or service that they were working on. Team members did not wait for others to pick up tasks, but contributed when they had the possibility to do it. The team members felt empowered to contribute to the result of the process improvement project in ways that we did not expect when we started the project. Their experience and knowledge came forward, simply by giving them the means to contribute, and setting the right culture to do it.

We learned this rule from Open Space Technology: “Whoever comes is the right people”. Team members that manage their contribution to the the result in an discplined way, they contribute what they have, when they can, in the best way that they can do it.

 You may critique anything, but you may never criticize anyone

This reminded the team to always focus on the products and services that were developed. Often it was just a matter of wording, how team members expressed their critique, but that didn’t make it less important to be aware how they did it. We always assumed that people were doing the best they could, based upon what they knew and were able to do at that point in time.

Criticizing the work, and not the person is an important rule that I learnt doing reviews and inspections. It creates an atmosphere where people can give feedback, and where receivers will be open for feedback. It also helps to do retrospectives and find the Root Causes of problems, and take actions to prevent similar problems from happening in the future. Assuming that people are doing the best job they can is again based upon the Retrospectives Prime Directive.


 These golden rules are something that my team members have learned in the project, and are still using in their current work. For them it is a way to collaborate effectively and efficiently in a team. Your rules will (and should) be different, depending on your needs and the situation at hand. But my expectation is that you can re-use from the principles that we have used to define our rules: The Agile Manifesto,  EVOOpen Space TechnologySolution Focused, and Retrospectives.

This article was originally published by Ben Linders in his blog post Golden Rules for Agile Process Improvement

]]> 0
Remote Managing: ‘The Practice Is Unruly’ Fri, 20 Dec 2013 11:24:34 +0000 John van Schagen Continue reading ]]> Due to the low wages in Eastern Europe, Dutch companies like to work with them. Yet there are pitfalls discovered by Hugo Messer.

Sometimes, accidental meetings are the start of a successful company. When Hugo Messer worked eight year ago in a printing office, he could not imagine that a meeting with two IT guys from Odessa (Ukraine) would turn his career upside down. ‘I already had seen enormous opportunities for IT-outsourcing in India. I just started my own company when those guys told me more about Ukraine. A country with 47 billion residents and a huge offer of highly educated IT-professionals. Every year, 7.000 to 10.000 young people graduate from technical universities. Next to that, there was no sight at all that the country would join the EU very soon and that is favorable for the wages.’


That was the start of Bridge Global IT Staffing in Ukraine. Messer started on a small scale, with IT-orders from Dutch internet bureaus that he is outsourcing to programmers in Ukraine. He is the intermediate that brings parties together and who sends a check afterwards. It sounds really simple, but in practice it is a lot more unruly. ‘In the internet world a customer hires an advertising agency to build a website. Their web partner calls us and hires technical people from Ukraine. That are a lot of shackles. If somebody is sloppy with communication, a lot of things are going suddenly wrong. Eight out of the ten projects went good, one of then became a long story and one ended up in a quarrel with the client. That was because we worked with fixed rates and due to that we ended up a lot between a rock and a hard place.

The right guy

That has to be different were the thoughts of Messer. The right guy for the right job and better communication between the client and the programmer are the most important ingredients for a change. ‘A client nowadays tells us what kind of programmer they need and we will search one for them. First in our own pool of people, but if we can’t find a match here, we will search beyond our own pool. Before the programmer starts working, he has to complete a test case and an interview with the client. If there is a match, the programmers will get on the payroll in Ukraine’.

Communication blue print

Learned from the mistakes in the past, Messer decided to change his guidance. ‘We start with a workshop which will become a blue print for the communication. This is where we decide together what code standard will be used and how the process of software development will look like. During this process, at least once a day a conversation about the project content will take place between the programmer and the client. Next to that, every week, a Skype-meeting between all the concerned project managers in the Netherlands and Urkaine will take place. This is mainly about the communication and a decision is made if the project needs adjustments’.


Meanwhile, the company has 30 people working in Ukraine and an office in India is added. Although the wages in Eastern Europe are higher than in Asia, about 2 to 4 times higher thinks Messer, the benefits of nearshoring should not be underestimated. Research shows that distance is an influential factor. Complex problems sometimes require a face-to-face solution and a return to Kiev sounds a little more attractive than a long flight to Mumbai. Next to that, the same culture makes a cooperation easier, at least in the perception of many people. Also, having the same office hours helps the tuning of the cooperation.

Doing homework

Messer is more than satisfied about the level of the programmers in Ukraine. ‘The level is generally really high. Besides that, a lot of senior IT’s with a minimal experience of 15 years are working here. Especially if I compare that with India’. Companies who want to make use of that expertise in Easter Europe have to do their homework is Messer’s advice. ‘Is looks easy to undertake everything on your own. You hire a programmer, tell him what to do and in no-time you will have your software or a website for half the price. But I can tell you from experience that in practice it won’t be that easy. You really need dedicated people who can take care of your business. One small with mistake with huge consequences is easily made’.

More tips and tricks for remote managing

An office abroad is an extra company. This will require knowledge of laws and regulations of the country in question and remote managing. How can you hold a grip? What are the requirement that you need to meet? What can or do you need to delegate? Sign it from the mouth of Jurjen Groot (lawyer at CMS Derks Star Busmann), Piet Bezemer and Patrick Schneider (CEO of IIC, Vacuvin). 

]]> 0
Do Soft Skills Really Matter in IT? Tue, 10 Dec 2013 12:23:02 +0000 Ben Linders Continue reading ]]> IT is viewed by many people as being something technical. They have a vision of managers with lot’s of plans, documents and spreadsheets, and nerds that are sitting behind their computer doing the “real work”.  It may be out there, but I don’t see that often. What I see are people working together to deliver software solutions that work, which help their customers in their daily work, and deliver business value to the company. Communication and collaboration is essential to make the people that are doing this successful.  So for me, soft skills really matter in IT!  What do you think?

I see every day how Soft Skills often make the difference between teams that are successful, and those who have problems. The ability the communicate, collaborate, reflect and give feedback, and continuously improve the way of working is crucial for team members to deliver value to their customers. Soft skills help to discuss and solve issues that come up, get rid of anything that frustrates team members. It is more fun to work in such a team, and yes, you can even measure how happy your professionals are with the Happiness Metric.

The evidence is there!

What convinces me that soft skills really matter? My Experiences! Most of the Root Causes that I have found when examining defects or project problems have to do with knowledge and soft skills. In agile retrospectives that I facilitate, people discuss how they communicate collaborate, and look for strengths in those areas that can be used to further increase team performance. Books like Peopleware and The Mythical Man Month make sense. Methods from the positive psychology, like Solution Focus, Theory U, and Appreciative Inquiry have evidence that recognizing and developing soft skills makes a difference (see my Golden Rules for Agile Process Improvement). The People-CMM, an accompanying model for the CMMI, has a level 2 process area on Communication and Coordination and can be used to empower your people. For me, that’s enough evidence!

What is your experience? Do soft skills really matter in IT? Have you seen benefits when professionals improved their soft skills? Is it worth investing time and money to make it possible that people can develop themselves? Please share your experiences!

]]> 0
How to hire a nerd? Wed, 13 Nov 2013 11:37:24 +0000 Hugo Messer Continue reading ]]> Two weeks ago, I wrote an article about lean distributed startups. The past months, one of the startups within our company that has taken most of my attention is ‘hire a nerd‘. The main goal of this project is making a product out of our current core service (building offshore and nearshore dedicated teams for software firms and departments). Yes the name is provoking, we’re also contemplating launching a second version under our Bridge brand. We try to achieve two things for our customers:

A. To make it incredibly easy to find your next favorite remote developer
To achieve this promise, we have created a vast database of programmers from Ukraine and India. These programmers are either ‘candidates’ or ‘qualified developers’. The qualification is done by us (we do extensive interviews and coding + analytical tests). It is easy to search the database for a programmer that you need. Having found someone, you can schedule an interview or ask us to qualify the person. The system will also provide overviews of availability and reviews from previous customers for the person.

B. To create a collaboration that feels as if the person is sitting next to you
This is a future part of the system. The vision here is to create a dashboard with easy access to tools that give you ‘control’ on the collaboration. We’ll use third party plugins for the core tools such as project management tools, time trackers and version control. And we’ll build tools to give you an overview of your team (hours billed, invoice overviews, availability), the communication process, access to trainers and coaches, a best practice area to share experience with other remote team managers. 

We have tried to follow the lean startup method as much as possible in this project. And having said that, I must admit that we deviated wildly. First of all, we have built the first version of the platform (partly) for internal use. In the first version, we enabled our sales people to search and share cv’s of our talent through a central database. Next, we made many iterations to support what we call the ‘search process’ (where recruiters and sales people cooperate closely to find the right person for a customer). And now we have reached the stage where the rest of the world can use our platform. 

And here’s the main challenge we face today: how to gather useful feedback. This challenge has two parts: where to find the people that can provide you with feedback and what to ask/do. There are two main ‘forms’ of getting feedback:

1. Ask someone ‘can you give me some feedback’ (as an open question or supported by a survey or interview)

2. Observe behavior of users (and measure using smart metrics)

I have found that asking ‘open feedback’ (please check my system and tell me what you think) doesn’t elicit useful information. It only generates lists of features as people start thinking what could be added to your product. Using a survey or interview with specific questions may work, but limits the feedback to the questions you ask. We are trying this now, so I can tell you more in a few weeks. 

The second feedback mechanism is observation. Most teams use google analytics, kissmetrics or some other tool to gather data. But to gather relevant data, you need to first get people to use your site (and so you need something that works in most cases). And you need to define what behavior you want to measure. An interesting case is described in the lean startup book, about Dropbox. The founder actually only launched a site, described what he was building using text and a simple video and got thousands of potential users to subscribe. This feedback tells you ‘my idea has viability’. But it doesn’t give you insight feedback on what exactly users value and what they don’t. 

We are experimenting with generating feedback, so I will write more in the weeks to come. If you have some similar experiences, it would be great if you can share them as a comment (and feel free to submit a guest blog article for this blog, just email me at

]]> 0