Have you ever tried to push heterogeneous groups of people to move in the same direction? It is quite a challenge, isn’t it? And now, imagine this situation in a distributed environment, with people whom you’ve never met, and who must be persuaded by means of phone calls or email. Welcome to our world. We have been doing leadership coaching to developers around the world for 5 years, and in that time, have learned to rethink many of the traditional approaches to training. When it comes to working with people scattered across the globe, we’re “not in Kansas anymore”.
Let me introduce this topic by clarifying some terms. If you ask people what is meant by coach, mentor, or trainer, they often intuitively come to definitions that are almost the same for all three. The same can be said for the terms offshore and nearshore. But these small differences in definitions make big differences when implementing and sustaining change.
By the term coaching, we mean a pure “challenging” approach, one that doesn’t necessarily provide teams any solutions or hints. A coach helps a person or team clarify the goal or current situation, or identify the way forward. He or she does this simply by asking the right questions. A coach does not provide any solution or best practices, and often doesn’t even need to have any knowledge of the subject. A mentor, on the other hand, can use coaching as one facilitation method, but extends it by his or her knowledge of the subject, teaching techniques, hands-on implementation support, etc. Thanks to knowledge of the subject matter, a mentor can share best practices (to avoid teams “reinventing the wheel”) and can gently coax mentored people to help them learn lessons quickly. Finally, a trainer is someone who conveys information and skill through instruction.
Offshoring strategy and terms are quite familiar for most readers. Nearshoring, however, may not be familiar: it means a form of delivery involving teams in different countries but with only small time zone shifts, and with cultural and geographical proximity. Offshoring, by contrast, means delivery with teams settled in distant geographical locations and with bigger time zone shifts (with few or no overlapping working hours). People in offshore teams very often also have quite disparate cultural backgrounds.
Our team itself originated in 2006 from a nearshore location in the Czech Republic, beginning with local mentors focused on the implementation of specific software design (SWD) practices such as Agile planning, continuous integration, test driven development, and pair work. Today, we are coaches driving corporate change in a learning organization. This evolution has had significant impact on the way we deal with change. Most significantly, our mindset has shifted from trying to enforce a solution, to enabling change in a learning organization; from “the solution is obvious, why do they not implement it?” to “human change management optimizing the whole process”, as is shown in Fig. 1.
Figure 1: Shift of the mindset and implementation approach (from local mentoring to global coaching).
The key aspects of two key approaches to coaching in a distributed environment which we’ve learned, and now apply, are the following:
1. Having a Local change agent (a.k.a. internal coach) for hands-on support and sustainability.
2. Conducting a Kaizen workshop as a tool to overcoming the dispersion of teams, identifying common goals, and empowering the teams.
Local Change Agent
A local change agent can be a team leader, scrum master, architect, service manager, line manager or specialist in the local team having the right mindset. “Right mindset” in this case means understanding and living Agile and Lean principles. Position or role as such is not so important; more essential is having the “same language and thoughts”. The change agent drives the change locally and provides daily support to local teams. Local change agents synchronize with us on a regular basis to ensure we’re pulling the same end of the rope (sort of Scrum of Scrums). This synchronization among change agents only (not among all teams) is more efficient thanks to all possessing the same mindsets, lived principles, experience and vocabulary. Narrowband communication (phone, live meeting, email) used for coaches’ synchronization is not such a big constraint in this environment. (You know, it is a pretty hard task to explain the value of Agile to a waterfall-ish guy over the phone).
Our first activities when travelling to remote locations are focused on identification and education of potential change agent candidates.
Kaizen Workshop
The Kaizen workshop is a very powerful tool for helping us overcome the distribution of teams, identify common goals, deliver value and, finally, empower teams for the change. The concept of the Kaizen workshop is nothing new; it is well-established as part of Lean thinking (see e.g., Liker: The Toyota Way). But the way we use it in distributed environments brings additional value. The workshop usually lasts for two days and has following agenda:
Figure 2: Kaizen workshop agenda.
One factor crucial to ensuring the success of a Kaizen workshop is to choose the right people. These are people who must be motivated for change, have decision-making power, play different roles (managers, technical people, developers, operations and testers) and offer different perspectives. We choose people from all locations involved in a project or service delivery in order to construct a full, big picture, and so that they may impact the entire end-to-end value chain. Ideally, that also means customer involvement, but if we are in really big trouble it may pay to sweep our mess up before exposing the customer to it. An efficient limit for a workshop is about 15 participants in total. Further communication of workshop achievements and actions among those not directly involved is the natural responsibility of the managers.
The first day of a workshop starts with a discussion and agreement on a common goal, and of what constitutes “real value” for the customer. Different stakeholders have different expectations, needs and interests, and we need to reach a consensus for a successful workshop. Without this, it risks becoming just another talking club with people digging their heels in on their positions.
After the common goal is established, we can continue with construction of the map of current reality for a selected area (e.g. the development process or problem management process). The outcome of this activity is a Value Stream Map (VSM), synchronization on current status and a list of perceived issues (see Figure 3).
Figure 3: Value Stream Mapping and list of top perceived issues.
The next step is selection of two topics for further elaboration. This selection is important to the goals of staying focused and limiting work in progress – one of the key Lean principles. For these issues, teams investigate root causes using either the Five Whys or the Fishbone technique.
The last step of the workshop is the definition of the ideal state and the related steps, called Kaizen steps, leading towards that state. Kaizen steps are small actions that can help us achieve the ideal state. They can involve just a check of agreed attributes in the contract, creation of checklist(s), an update of the sales offering, or knowledge-sharing with the team. Usually such activities take from a few minutes to one full day at maximum. They should not be perceived as additional or extra work, because doing and improving the work is part of every position description. Some improvement actions will have already been identified during the discussions about the current flow. On top of that, we use the brainstorming or the world café technique to bring up additional possible improvements. Proposed Kaizen steps should address and improve uncovered root causes (Service Level Agreement (SLA) measures in our example). Respected actions designed to improve the situation are:
- Define needs for reports following trends across different teams. Have a few people committed to this activity in their respective teams.
- Implement defined trend measures in existing reports. Have one specialist managing reports committed to this activity.
- Define the problem manager role – discussion with HR.
- Define measures for problem management as well.
To summarize the Kaizen workshop’s key points:
- It focuses on synchronization of people, uncovering common goals, and finding possible long term (ideally) as well as short term solutions (so called Kaizen steps).
- It focuses on the daily problems being experienced by participants, not on tackling high level management problems (common goal).
- It focuses on a few issues, but solvable ones. We regularly prioritize the list of issues to stay focused on only the few most important ones. The goal is to really implement some solution. The philosophy is that it is better to successfully implement something with a smaller impact than to attempt to tackle many big things with bigger potential results, the solutions for which will likely still be in progress by the end of the workshop (limited work in progress).
- Participants design small achievable steps (solutions) that can be applied today with not too much effort (Kaizen steps). No general solutions are proposed (you cannot ensure world peace in one week!), but pretty complex changes can happen when implementing incrementally small refinements (e.g., contracting, the way services are delivered, measurement mechanisms).
- Regular face to face as well as offline meetings for information sharing, and presentation of achieved steps and results, are key activities to get participants and teams engaged, and to successfully implement sustainable change.
Two of the commonly underestimated dynamics in software development and service delivery are social relationships and human nature. People need to meet physically in order to create personal relationships. We need to see faces behind names in order to build trust (it is often called “overcoming the layers of resistance”). Smaller groups are needed in the beginning to break the ice, set up a work hierarchy, and overcome natural human shyness.
Also, do not overlook the importance of social events as communication openers. We strongly recommend a joint dinner before or during the workshop; this is where groups become the teams and when open communication begins. You can find more about human nature in IT in one of my presentations, www.slideshare.net/xprochaz/human-it.
Conclusions
To summarize our lessons with coaching in a distributed environment, I would name following three points:
First, coaching is about coaching people. People and their needs should always come first, with the system and its limitations second. Although people see it as logical to perform this or that activity, they will not do it if it doesn’t solve their issues. Soft skills are crucial; be a role model and practice what you preach. We use Agile and Lean principles and practices to support Agile and Lean implementations.
Second, our proven methods to overcome distribution challenges consist of following:
- Motivate people to pull (push is not sustainable even if you achieve some improvements… really!).
- Face-to-face intensive sharing kick-off or Kaizen workshops.
- Focus on built-in continuous improvement (driven by the teams, not by Agile/Lean coaches).
Third, remember our story and mindset shift. Actions need to correspond with people’s mindsets, needs and environmental readiness; otherwise you push them into change that can overwhelm in an unsustainable environment. ■
About Jaroslav
Jaroslav Prochazka works as an Agile/Lean coach at Tieto Corporation and has been in IT for the past 11 years, starting as Java developer. He has more than five years of experience coaching and mentoring in distributed environments: coaching development, support and maintenance teams inside and outside Tieto. He has worked with about 400 people and has trained more than 800 to date.
Jaroslav earned his PhD at the University of Ostrava in 2007 and now teaches software development and information systems there. He speaks at international conferences like IBM RSDC 2009, Information Systems Development 2010, and the International Conference on Global Software Engineering 2011.
Jaroslav is an author of the recently published book, Operate IT Differently: Agile and Lean Support and Maintenance of IT Services and Information Systems (in Czech) and runs the blog www.differ.cz, which features articles, eBooks and templates in both Czech and English.
You can contact author at jaroslav.prochazka@tieto.com
