Distributed Agile: 8 ways to get more from your distributed teams

A change in understanding

Over the last few years I have been fortunate to have had several agile consulting 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, I came to the conclusion that if agile is to thrive over the next 10 years then it not only has to work in a distributed environment (i.e. an environment where we do not all work in the same place), but it has to work well in order to deliver the most value to an organisation.

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

To put this another way, ‘when is the way we work not distributed?’ My company KRC currently have a customer who is based in Yorkshire and London with several London offices. How different is this to several of our customers who have offshore operations in Europe and Asia? Slightly different, yes, but significantly different, perhaps not.

I can always 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; 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 well over a decade 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.

It was on this recent trip to India that I felt I cemented a lot of my understanding of how to get this to work and to get this to work well. I’ve often had ideas and concepts and listened to other people’s opinions and suggestions but I think I have now reached the stage where I can see what needs to happen with a lot more clarity. My last trip to India changed how I viewed ‘distributed working’.

Where do organisations need to focus?

A common feeling that it’s all about ‘communication’ and 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 feel it is how a project is structured and the teamwork 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!

Another assumption I find it is important to fight against and to pull away from is the stereotypical ‘coding factory’ model that resembles a Chinese takeaway in that 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, from what I have seen and read, it is a recipe for disaster. I believe that frequent interaction with ‘the techies’ (either located in India or on the third floor) can add incredible levels of value to the project outcome.

As usual in the drive to be agile things are often missed regarding, 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 the IT explosion in India. I would guess that 99% of the people in the UK and Europe have no idea of how vast the IT operation is in places like India, China and Eastern Europe. We are talking of cities that are hosting hundreds of thousands of highly skilled professionals and the need to get agile to function fruitfully and productively in this climate as the world’s use digital information grows exponentially is not a case of ‘a nice to have’ it becomes a commercial necessity.

The main recommendations

What follows are 8 suggestions on how to improve distributed working and this applies 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 and 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 as they apply to any form of distributed working, agile or not. So the eight ways to get more from your distributed teams are:

1. Ensure that teamwork and collaboration are working well by removing cultural and process limitations

This is the most important thing to get right and 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 needs to function in a collaborative manner and teamwork is at the centre of this.

The complicated bit is that this collaboration needs to 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 the collaboration has many contexts.

The areas to get working are:

• The collaboration and culture within each distributed team – is it predominantly a partnership or is it adversarial?
• The prevailing ‘way of working’ within each team – is it predominantly linear, or is it iterative and incremental?
• The collaboration and culture between each distributed team – as before, is it predominantly a partnership or is it adversarial?
• 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, needs to be happening in all parts of the machinery and not just some 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 the iterative and incremental way of working and this therefore leads to the scary fact that this creates as a minimum a 2x3 grid where if just one part fails it creates a bottleneck…and this assumes only two teams!

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 and 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 and some of these reasons are deep cultural ones, for example the wish to avoid letting someone down.

However, this does need to be taken 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 needs to be seen 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 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 and one of them 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 a lot of 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 but 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, then 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 this 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 attacking 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 seen as 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 particular 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 still 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; 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 and 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 needs to have a strategy that needs to be planned and managed. It would be ideal if at all times 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 need to be reached in order 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 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.

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

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 distributed needs to 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 is very 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 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 with distributed working in particular.

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 processes with defined roles and responsibilities, along with 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 clear 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 ‘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 the project as a whole 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 situations. 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.

• 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.
• 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). How advanced an organisation is depends on how far this delivery goes. 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:

i) 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.

ii) 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 in the area 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.

In summary

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 the IT explosion in India. I would guess that 99% of the people in the UK and Europe have no idea of how vast the IT operation is in places like India, China and Eastern Europe. We are talking of cities that are hosting hundreds of thousands of highly skilled professionals and the need to get agile to function fruitfully and productively in this climate as the world’s use digital information grows exponentially is not a case of ‘a nice to have’ it becomes a commercial necessity.

But is that where the story ends? Are we missing a problem that is right under our nose? A lot of effort is put into the distributed situations involving teams sometimes thousands of miles apart but there is a lot that can be done nearer to home that can reap similar if not greater benefits…and all that involves is walking up the stairs!

There is a webinar associated with this document here.

About the Author

Keith Richards has over 30 years’ experience in IT and project management, and specialises in using agile approaches to improve the way organisations work, and increase the benefits they deliver. He hosts a very popular webinar series that not only gets behind the hype surrounding agile, but also helps people understand what agile can do in real world situations. He is the author of ‘Agile Project Management’ (published by TSO) and in 2011 was awarded “Most Valuable Agile Player UK” at the UK Agile Awards in London. An award recognising a decade of thought leadership, innovation and above all delivery. His contact: k.richards@agilekrc.com.