Distributed Agile – getting more from remote teams

Note: Since this article was first written, Covid-19 has brought huge changes to working, especially in the richer countries of the world. For millions of highly skilled, white collar staff performing technical roles, working from home has become the norm born out of necessity.

Nine months into the Covid pandemic, and it is likely that the ‘old ways’ of working from large offices in cities will likely not return.

Organizations therefore which never allowed remote working before, have had to accept that remote team working is now part of the present and the future. The ideas presented in this article therefore have even more relevance to the post-Covid world of distributed working and remote teams.

Change in understanding

A few years ago, I was fortunate to have several agile consulting and training opportunities in India.

I find India the most fascinating of places and it is great fun to meet so many people who are passionate about their work. Not only are they passionate but they are good at it too.

After my most recent trip, two things struck me which I thought were quite striking in an agile context.

Firstly, if agile is to thrive over the next 10 years then it has to work in a distributed environment (i.e. an environment where we do not all work in the same place). And it must also work well to deliver the most value to an organisation.

Secondly what struck me was that, perhaps, most of us are missing something obvious. This is that in some form or another, aren’t most things in our normal way of working ‘distributed’? Therefore, can we learn something from looking to improve this way of working?

To put this another way, ‘when is the way we work not distributed?’ agileKRC currently has customers based in Yorkshire and London with several London offices. How different is this to several customers having offshore operations in Europe and Asia? Slightly different, yes, but significantly different, perhaps not.

I can remember working for one of Ireland’s major banks and always thought it was funny that despite two offices being opposite each other, one on either side of the street, many people hadn’t ‘crossed the road’ in several years. In fact, with some companies it’s far worse than that. They haven’t even gone upstairs to the floor above for several years!

Most of the agile body of knowledge that has been written is based on the utopian situation of one team, one ‘product owner’ and one location. Although this is still often the case, is it the exception or is it the rule? Having worked for over two decades now on implementations of agile I find that multi-team, multi-location, multiple business area and even multi-time zone agile is more the norm.

Where should organisations focus?

A common feeling is that it is all about ‘communication’. Although I do think there is a lot of merit in this view, I find this can distract people from what the main problem really is.

It may surprise people, but I think it is how a project is structured and the teamwork that is involved that makes the BIG difference. I now think that ‘communication’ is not the most important thing to get right. In fact, I think it doesn’t even come close!

Coding factory model

Another assumption I find is important to fight against is the stereotypical ‘coding factory’ model. This is one that resembles a Chinese takeaway. You send over a ‘spec’ and the hatch opens and back comes the code!


Many people praise and welcome the ‘Waterscrumfall’ concept, but I do not believe this is best practice. To put this another way, in my experience it is a recipe for disaster. I believe that frequent interaction with ‘the techies’ can add incredible levels of value to the project outcome. This applies whether they are located either in India or on the third floor.

As usual in the drive to be agile things are often missed. Usually, these are what I would describe as, ‘project management basics’. Are the goals clear? What is the rationale? What is the context? A good start to any project is worth its weight in gold. The risks of confusion at start-up are greater in agile and therefore the need to be more vigilant and diligent becomes critical.

When you visit India and you visit the IT centres in cities such as Bangalore, Chennai, and Pune you are stunned by the sheer scale of them. I would guess that 99% of the people in the UK and Europe have no idea how vast the IT operations are in places like India, China and Eastern Europe.

We are talking here of cities that are hosting hundreds of thousands of highly skilled professionals. Getting agile to function fruitfully and productively in this framework is not a case of ‘a nice to have’ it becomes a commercial necessity.

Main recommendations

What follows are 8 suggestions on how to improve distributed working. These apply to any scenario where the whole team is not collocated, be that UK to India, London to Yorkshire or Canary Wharf to The City.

The UK to India scenario is often used as an example in this document but the same thinking applies to any combination of teams not in the same location.

Before outlining the main recommendations, it is important to make one distinction. Some of these recommendations refer to improving distributed working in general. They apply irrespective of whether agile is being used or not.

Other recommendations are specifically focused on distributed working in an agile context. Ironically, many of the problems apparently associated with agile in a distributed context are not problems with agile at all. In fact, they apply to any form of distributed working, agile or not.

The remainder of the article will now describe the eight ways to get more from your distributed teams.

1. Ensure teamwork and collaboration work well by removing cultural and process limitations

This is the most important thing to get right. It may be a surprise to many that ‘communication’ is not the most important as it is most frequently cited as the area for attention. However, for a high level of performance and for agile to work well in a distributed context the team must function in a collaborative manner. Teamwork is at the centre of this.

The complicated bit is that this collaboration must work at many levels. It needs to happen between the teams AND inside the teams too. This is not a straightforward case of ‘we need to collaborate’ as collaboration has many contexts.

The areas to get working are:

  1. The collaboration and culture within each distributed team – is it predominantly a partnership or is it adversarial?
  2. The prevailing ‘way of working’ within each team – is it predominantly linear, or is it iterative and incremental?
  3. The collaboration and culture between each distributed team – as before, is it predominantly a partnership or is it adversarial?
  4. The prevailing ‘way of working’ between each team – again, is it predominantly linear, or is it iterative and incremental?

The key point that this multi-faceted picture presents is that collaborative culture, and an iterative and incremental way of working, must happen in all parts of the machinery and not just some part of it. If teamwork and collaboration are working well in one area but not in another, this could take the whole process down to the weakest link.

The same applies to iterative and incremental ways of working. This leads to the scary fact that if just one part fails it creates a bottleneck…and this assumes only two teams!

Collaborative cultureIterative and incremental
Inside the onshore teamgood/average/poorgood/average/poor
Inside the offshore teamgood/average/poorgood/average/poor
Between onshore and offshoregood/average/poorgood/average/poor

As an example of something that breaks down culturally is the widely held perception that Indian software professionals will always say ‘yes’ to everything when asked a question such as ‘are you on schedule?’ or ‘Do you think you will hit the deadline?’

In reality, there is a lot of truth in this. When you discuss this with Indians they freely admit to it with a big grin (albeit sometimes a nervous one)!

This is an example of where the culture between distributed teams needs to be addressed and changed.

There are reasons why many Indians say yes when they mean no. Some of these reasons are deep cultural ones, for example the wish to avoid letting someone down.

However, this does need to be addressed head on. Any project manager knows that the sooner you are aware of a problem the more time you have to deal with it.

By discussing this very point with offshore teams and explaining that a problem shared is a problem halved, it can start to build an environment whereby ‘yes’ at least turns to ‘not sure’. It is almost certainly asking too much to transition to a culture where Indians in particular feel comfortable saying ‘no’!

This is where a UK person communicating with someone in India needs to carefully craft their questions and have a sixth sense regarding the reply. This is where face-to –face works so well. Words are only a part of a conversation; there is tone and body language as well.

The crux of all of this is to do with teamwork, collaboration and trust. This is more important than anything else with distributed working and the team behaviours need to fall into line with this. Team members anywhere need to feel safe to say ‘no’ or ‘not sure’. This must be viewed as good behaviour. To be agile there is a need to self-organise, be autonomous and be empowered; with that comes responsibilities to call it like it is.

Importantly, this should not be seen as an ‘Indian problem’. It can easily happen in an organisation based in the UK where the organisational culture creates the need to say ‘yes’. This is where the stereotypical ‘Indians always say yes’ obscures the fact that many organisations in the UK have a culture that produces the same result!

Also bear in mind that all nations have their foibles and idiosyncrasies. An example of the British mentality is to moan about something like a meal in a restaurant when no-one is around. But as soon as a waiter or waitress asks if the meal is OK – the response they normally get is …’it’s lovely thanks’. And don’t forget that Americans use the term ‘awesome’ for just about everything!

There are many ironies with moving to an agile way of working in a distributed context. One of these is the perception that it is difficult to change the culture of offshore organisations when in fact it is equally hard, if not harder, to change the culture of the onshore organisation! Some of these cultures are due to national behaviours but some are also due to ingrained institutional or corporate behaviours.

So, getting the culture and the collaboration right is one thing but what if the process and the underlying way of working strangles agile before it has a chance to get out of the starting blocks? Is the underlying process an agile and iterative and incremental one? Or is it more sequential and waterfall based? Put another way, is it based on the delivery of features or is it more based on technical phases such as analysis and design?

The key point here is that if you manage to get the cultural and collaborative side of a project to work but it is trapped inside the body of a sequential/waterfall process, are you much better off? Perhaps a little bit, but not a lot.

A final point to end on with respect to this first point is about multifunctional teams. I believe that agile is about introducing a degree of cross-skilling but there is a need to go carefully here as there is much debate about how much multi-skilling and cross-functional qualities a team should have.

There is an agile ideal to have a team of all-rounders. My preference is for what are described as ‘T-shaped’ people. This is a person who has a primary skill such as testing but can also develop code to a degree. This allows a team to self-organise how they go about the work they do with more flexibility.

However, there comes a point where multi-skilling becomes impractical in that it is hard to find an accomplished developer/tester/UX designer. A sports team full of all-rounders will not beat a team where individuals have primary areas of specialisation (e.g. cricket or American Football).

It may be stating the obvious but if you have two HTML coders in China, a project manager in America, a business analyst in Britain and developers in India and that is the team you are severely limited!

2. Create ‘rich’ communication channels to reduce the impact of low levels of ‘face-to-face’

Although I have said it is not the most important area to get right, it is still very important to get it right. Citing communication as an area to work on is very much stating the obvious. The remedy is not so obvious and there can be a temptation to ‘accept the inevitable’ and see this as a ‘fact of (distributed) life’.

Much has been written about how people interact, and the speed and quality of face-to-face communication is many times more effective by a large factor e.g. 5 times, 10 times, 25 times and this is a huge loss to a distributed project.

The problem is exacerbated by the fact that a project is, by definition, addressing a complicated situation where there are several ‘known unknowns’ and ‘unknown unknowns’.

The solution is to spend time and resources on improving the situation. The more you can simulate the high-speed high-quality of face-to-face discussions the better, even if these simulations are not perfect. Using video and webcams should be routine. Products such as WebEx and Skype can bring many advantages when trying to create this rich communication environment.

Unfortunately, a lot of everyday communication is carried out using documents or email. The written word is a very narrow ‘pipe’ in terms of communication when it comes to opinions, views, ideas and questions. For broadcasting factual information it is fine. But if dialogue is needed it has many limitations. When opinions are involved it can turn into a nightmare.

It is important to look closely at how everyone across the project is communicating. It may even be appropriate to assign a person to a role of ‘Communication Coordinator’ to look at what is happening and how well communication is taking place.

One style of communication that can have a detrimental effect on a distributed agile project is where certain key roles resort to high levels of email. This is particularly damaging if it is a person leading a team or even worse the project manager. The business analyst would also be a role that would suffer if the usual modus operandi was predominantly textual.

For some roles it would be less worrying, such as developers or testers using a wiki. But having said that, the best ways to communicate are face-to-face, over the phone and using visualisation.

Therefore, it is important for anyone in a team to spot if any individual has ‘gone over to the dark side’ and become an ‘email automaton’. They may look busy and they may think they are being productive. But not only are they strangling the communication flow of a project they are depersonalising the teamwork which is essential for agile when teams are not collocated.

This can be very destructive but potentially it can be far worse. It can be catastrophic if it sucks the life and spirit out of a team. It can, and often does, leave a trail of anger and disillusionment.

One of the most significant moves that can be taken when working apart is to invest in travel. Fly people from offshore and onshore at key moments of the project (e.g. fly developers and testers from India to the UK during the early ‘definition/foundation’ stages of a project). And equally fly onshore people offshore.

This serves two purposes. Firstly, high-speed high-quality interaction can take place which can easily repay the cost of the air fares or train fares in the form of shortening the early phases of a project.

Secondly, relationships are built. This pays back a very high dividend over the course of a project and may last for many years. It is a lot more than ‘putting a name to a face’, it is about an emotional and professional bond that leads to a more productive and collaborative relationship.

This requires a strategy that must be planned and managed. It would be ideal if continuously on a project there was always an onshore presence offshore, and similarly an offshore presence onshore. This creates a form of ‘project holiday rep’ where there is always a conduit for communication from someone who is ‘our foreign correspondent’.

Carefully managing and planning the time zone issue is very important. The time overlaps or ‘golden hours’ need to be clearly understood and they should be treated as being somewhat sacred. If time to communicate between countries is limited, then it should be maximised.

Can teams adjust their working hours albeit only partially e.g. on Tuesdays and Thursdays? UK to India overlaps are not too severe whereas USA to India can be in the region of 12 hours. So, compromises must be reached to help the communication.

Ensure that video sessions and calls are planned, set up correctly and start on time. Try to avoid sessions that are too long. Humans can only concentrate at certain levels for certain amounts of time. Teleconferencing is particularly difficult as there is nothing to look at.

3. Get into Ping-Pong! Go back and forth a few times

There are several success stories about large scale agile projects being showcased in the media and at conferences recently but some of these don’t sound very agile at all to me. Close examination of what is happening leads to a view that the model is more akin to a ‘coding factory’. That is not to say it is wrong to do this but either there is a lot of interaction between the buyer and the builder or there isn’t.

The offshore partner may be using Scrum but if the specification (or work package) is fixed, the quality level is fixed, the estimates are fixed and all of the risk is being taken by the offshore organisation, then this isn’t very agile in my opinion.

When working in an agile way a work package or statement of work (SoW) would have flexibility in what was being delivered. Not too much flexibility as it needs to meet certain criteria, but this flexibility is managed collaboratively between the technical side and the business/customer side.

The best way to do this is to risk share and have a little bit of ‘give and take’. This way the business/customer can come up with new requirements or adjust existing ones whilst working with the technical teams to see how best this can be done.

If the discussion goes back and forth the offshore teams can add a lot of value by describing what is possible. There will be several ways a requirement can be satisfied from a solution point of view. If this dialogue doesn’t take place in a collaborative way, then the accuracy of the final solution will be reduced.

4. Create frequent deliveries of deliverables to establish control

By incorporating several agile concepts, it is important to create an ‘evidence based’ picture of how a project is going. Ideally this would be a ‘real-time’ picture and causes an objective status report at all levels of a project. What needs to happen is to create a steady trickle of interim deliverables and not just wait for the end of a timebox or sprint.

If this is done well it can be quite brutal and uncompromising but if you are spending a lot of money on a complex project with distributed teams – you need to know where you are and where you should be.

Agile often eschews ‘plan–driven’ approaches stereotyping them as waterfall, but you have always got to have a plan. You do not need to blindly follow it, but you do need to know what you are trying to do, how you are going to do it and to know if you’ve done it!

Any plan when working in a distributed way must have several regular deliverables of any sort (e.g. working software, prototypes, environments set up) spread out across the duration of the plan be it one week or 3 months.

The secret to success here is to define acceptance criteria (perhaps using the ‘definition of done’ approach in Scrum) for each of these deliverables.

What then happens is that as time moves forward the deliverables are produced, and it becomes easy to evidence how the plan is proceeding by looking at 2 key factors. Firstly, was the deliverable delivered on time? Secondly, how good was the deliverable? This becomes unemotional and creates ‘moments of truth’ – it is either on time or it isn’t. It is either right or it isn’t.

The reason this can be quite brutal is that it creates an environment of ‘you can run, but you can’t hide’. The intention is not to create a pressure cooker environment or a command and control atmosphere.

In fact, quite the opposite – it is intended to create a culture of transparency and visibility where going off track is picked up quickly and importantly we can validate if ‘what we are being told’ is true.

So, for example if offshore is saying ‘yes we are on track, we have no blockers’ – we are hours or days away from backing this up with a deliverable that will confirm this.

A typical example of this is a ‘demo’ at the end of a sprint or timebox. Was it ready by the due date? How good was the deliverable?

However, it is important to have many more interim deliverables during the sprint or timebox to check progress on a daily or perhaps every-other-day basis.

What this is trying to achieve is a drip, drip, drip of progress information without the risks associated with the ‘big reveal’ on a fortnightly basis. A demo at the end of a sprint or timebox shouldn’t contain any surprises.

The frequent delivery of products/deliverables is not only good for control but also for getting an understanding of what the teams are trying build and what they are trying to solve.

The best agile teams focus on feedback as a general opportunity to learn. This can be described in many ways such as ‘plan, do, check, act’ or ‘plan, do, review’ but the key to maximising this feedback is to shorten the cycle time from planning it to receiving it. In simple terms, look to shorten the feedback loop.

5. Be clear about what agile is and what it can do (or else it will cause more problems than it solves)

The lure of ‘agile’ and the hype surrounding it have caused a lot of confusion in general and especially when it comes to distributed working with remote teams.

An India software developer said to me recently – ‘we know how to do agile – the problem is – we just don’t know what it is!’

Here are some common misunderstandings:

  • Agile and Scrum are the same thing – no they aren’t.
  • You can use Scrum to run a project – no you can’t.
  • Agile is quicker – not really – well, you won’t get a 6-month project finished in 3 months – but at least you may get it in 6 months!

In simple terms agile is about behaviours and techniques. Behaviours would cover such things as empowerment, collaboration and good communication. Techniques would cover areas such as having a clear process with defined roles and responsibilities, and practices such as timeboxing, iterative and incremental delivery and flexing the requirements.

It is often worth investing in training or delivering briefings to get everyone on a distributed project to have a common understanding of what agile is and most importantly, what it isn’t!

If you put 10 people in a room and ask them to define ‘agile’ you will normally get something approaching 10 different answers.

Not only is it good to get clarity on what agile is, it is also worthwhile to debunk the stereotypical view that ‘waterfall’ is bad. In today’s fast-moving marketplace it is far from ideal, but it is far safer than ‘fragile agile’ where adhocracy is allowed to run riot.

The principle problem with using agile in a distributed context is that most of what is written about agile is focussed on one team, collocated and working on an existing product. None of these three points apply to large multi-team distributed projects where a new product or service is being created.

This immediately counts out the most popular and well-known agile approach, Scrum. Well, it discounts it from running the project but not from being used on the project. The distinction is very important.

If Scrum and a lot of the standard agile disciplines are used at the delivery level, perhaps in distinct work packages then this is fine. But to manage several teams in different continents needs the role of a Project Manager.

Many supporters of agile see the role of a Project Manager as defunct, an irrelevance – if you are looking to use agile in a distributed context it is a necessity. You can give this role a label of any kind but if it is a complex piece of work that needs many people to create a deliverable to a business case – it needs to be managed by someone.

A frequent trap that distributed teams fall into is thinking that a concept called a ‘scrum of scrums’ fills this space. In my opinion it doesn’t. It is good technique for inter-team communications but as a control mechanism for a whole project it doesn’t have the single point of accountability. A collective group cannot manage a project and be accountable for it, on behalf of a sponsor only an individual with a clearly defined role can.

When applying agile in a distributed context it can be next to impossible to work out what roles apply if you are only using agile concepts that are aimed at ‘product environments’.

One agile method, DSDM sees agile in a project as well as product context and has several roles that can help in a distributed situation. There is no need to adopt the specific DSDM terminology but on a reasonably sized distributed project there will be a need for as many as a dozen roles so that it is clear as to who is doing what.

These roles will need to cover the customer/business domain, the technical (or supplier) domain and the project management domain.

This will involve blending high level views, detailed views and specialist views in order to understand the full picture of all of the stakeholders involved on, or impacted by, a project.

There is a lot more to managing business engagement on a project than just asking the question ‘so who is the product owner for this project?’

6. Get off to a good start – clear objectives and well written requirements

Agile is very good at responding to change by being ‘change friendly’. The fact is that as the project evolves, so does the understanding of the details which will inevitably cause change.

However, this is no excuse for starting off a project with incomplete or inaccurate high-level requirements. This causes agile a lot of pain and the best way to start involves some patience and a reluctance to get going before being ready.

There is a saying ‘go slow early to go fast later on’ and this is why the project needs a crystal-clear definition of the reason for the project and what it is to deliver. This should be in as few words as humanly possible as it creates a clear focus for everyone on the project.

The next step is to create the high level and intermediate level requirements that directly map on to this. With agile it is not necessary to define these requirements in detail as they will evolve but this intermediate baseline needs to be set.

If this is lacking it has a very damaging impact on the offshore teams. What typically happens is that the early delivery of incomplete requirements causes the offshore teams to build incorrect solutions that need rework and adjustments. Which is in effect using the offshore teams to drive our intermediate level requirements. This is very inefficient and a primary cause of frustration to the offshore operation.

Two agile considerations need to be addressed here. Firstly, if you are going to deliver a project on time then the flexibility in the requirements needs to be defined here. The MoSCoW approach where requirements are categorised as either Must Have, Should Have, Could Have or Won’t have this time, is ideal for project situations that involve dependencies and requirements clustering into functional groupings.

The second concerns the use of user stories. A very common and powerful agile technique but unfortunately much misused and misunderstood. It is highly unlikely that on a distributed project an offshore team could code from user stories no matter how well they are written. Two essentials need to be in place if user stories are to be used to communicate the requirements for a project.

  1. The user stories need to be complimented by other forms of documentation to further enhance the understanding of the requirements. Examples of this would be providing use cases, process flows/flowcharts and any other model or supporting diagrams or text that helps to illustrate what the requirements really are.
  2. The user story needs to be seen as a ‘conversation piece’ – it is not an end product. It is used to enable discussion, debate and clarification.

7. Assess your tools and working environment with respect to working in an agile way – invest in this area if it is needed

The tools you are using and the technical and physical environment in which the work is being done has a significant effect on the ability to work in an agile way. Although it is not true to say that good tools and a good environment will make for a good project, it is certainly true to say that poor tools and a poor environment can lead to a poor project.

For example, from a technical perspective one of the first considerations is to look at how software will be built, tested and deployed.

When agile software development is in full flow there will be automation of frequent testing and continuous integration. Depending on how far advanced an organisation’s TDD (Test Driven Development) and CI (Continuous Integration) is, this will dictate what is possible from the point of view of delivering software frequently to enable short feedback loops and early return on investment (ROI). Is this delivery to the live environment or to System Test and/or User Acceptance Test (UAT)?

With many teams working on one code base factors such as accessing the code and the time it takes to build it affects how frequently code can be committed and how easy it is to build and deliver iteratively and incrementally. This in turn affects how the project will be planned.

One of the most limiting factors to how agile an organisation can be is in this area of ‘is it to live or is it to a test environment’. If it is the latter, then this invariably slows down the ability to deliver frequently and often.

On top of this, progress through the test environments can often take ‘as long as it takes’ in the sense that the key variable in agile, i.e. the ability to flex the deliverable is not an option. This problem is further compounded by the inconvenience caused when an error is found in test because the code has now moved on.

Although the most important part of tooling to get right is in the build and test area there are many other areas where tools can add value.

However, there is a classic error with respect to tooling and it affects all projects and not just distributed ones. This concerns choosing tools and toolsets before deciding how to use them. In other words, the tools drive the process.

When looking at tooling it is important to break this down in to two areas:

  1. Different tools do different things so tools should be seen in a similar way to kitchen appliances – different jobs require different devices. There is no such thing as a generic tool for the kitchen that does everything.
  2. What do you need a tool for and what do you already have? There is often an existing tool perhaps a simple one that can fulfil a role without the need to purchase anything new.

I worked for one organisation where four teams decided to use Jira. Two teams were using it well, one team was using it badly and the fourth team should have been using a whiteboard instead.

When looking at tooling there are many areas that could benefit such as documentation, collaboration, communication, requirements management, planning, reporting, versioning and many more. An area that can have a significant effect on the inner workings of a project is where the build and testing of the software is happening. For example, if a build gets broken, is this a simple rollback in minutes or hours or does it involve branching and a day or two of ‘surgery’ to rectify? Agility is hampered if it is the latter.

8. Turn the expression ‘Inspect and adapt’ into a mantra

Organisations all around the world are at varying stages of their agile journey. Some are only just at the very beginning but for those organisations that have reached certain levels of agile maturity and are beginning to excel at it, it would be hard to believe that they do not have ‘Inspect and Adapt’ as the nucleus of their process.

In my opinion, this philosophy from Lean principles is at the heart of agile. Commonly people see Scrum as a timeboxed approach of sprints and daily stand-ups but the essence of Scrum, the kernel, is the idea of continually improving the process you are using little by little, time after time.

Continuously making small improvements will lead to big gains in the long run.

A simple technique is to look at every unexpected event or error and trace it back to the root cause (Root Cause Analysis). Was it to do with an unfinished User Story? Was it a misread email? For every problem see if the process can be changed to prevent it happening again (or at least reduce the likelihood or impact).

This can be very useful in distributed situations as many organisations are in the early days of working this way. It is new, so there will be mistakes, errors and things falling through the gaps. The key is to learn from these events – see them as learning opportunities and not a source pain and negativity.

An advanced step of ‘inspect and adapt’ is to build continuous review into the process.

Sometimes referred to as ‘self-optimising’ this is where the process itself has steps in it to check if the process itself needs to be improved. If bi-weekly or monthly retrospectives are taking place and the learnings are being fed back into the process, this is going a long way towards self-optimising’.

When inspect and adapt becomes almost real-time, a little bit like a reflex the process evolution becomes very fluid.


This article was prompted by my journeys to visit the huge Indian IT centres in cities such as Bangalore, Chennai and Pune.

But in 2020, the world has been stunned by the advent of Covid-91. Along with the tragedy of so many people losing their lives, businesses have had to adapt to distributed working with remote teams becoming the norm.

The recommendations I made to help you get the best out of your remote teams is as relevant now as it was several years ago when I first wrote this article.

In fact, today I would argue that managing remote teams and getting distributed working right is an absolute necessity today. Organizations that get this right will be the ones that will come out of the Covid pandemic stronger and better able to exploit the opportunities in the future.