• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar

Agile Buddha

Demystifying Agile, Getting to its Core

  • Our Blog – Agile Buddha
  • Agile Workshops and Certifications
  • Agile Commune – Join Here!
  • Webinars
  • Contact
  • About Us
  • Show Search
Hide Search

Distributed Agile

The First Law of Distributed Agile

by ShriKant Vashishtha Leave a Comment

With the advent of communication revolution, people looking for nomad life and orgs looking for skilled knowledge works irrespective of geographical boundaries, distribution of teams has become a norm rather than exception.

However, distribution of teams has a lot more pitfalls than many people realize, especially when people do them just because they can or it’s convenient.

This article is about putting team distribution in a perspective and show why every possible distribution is no fun.

Once, I was working with a distributed team which had half of its team members working from  Bangalore and the other half from CA, USA.

While speaking to the team members, I came to know that team members were struggling to work in distributed mode as they had to collaborate with their distributed partners in a completely opposite timezone (12 hours of time difference).

It had started affecting their personal lives as they used to take their meetings to their home as well.

Apart from conducting their distributed daily Scrum in the night, Bangalore team-members had to have a call in the morning too when CA based folks used to hand-over the work to their counter parts in India. Other sprint events as well used to happen in this time period.

Team tried different ideas coming from their retrospectives to make it work. But the situation didn’t improve.

During one such conversations, I asked if it’s possible to have two separate geographical teams working on independent features and collaborate on integration points. Essentially one team in CA focuses on one set of features and other team in Bangalore focuses on other set of features.

It turned out that it was certainly possible but the option was never thought through before.

The work could certainly be distributed without distributing the team geographically. That’s how we get to The First Law of Distributed Agile

Don’t Distribute Your Team in the First Place

Irrespective of the available tools and remote communication channels, face to face communication is much more powerful than its remote counterpart.

Remote communication by default brings a bunch of overheads along. Because of high transaction cost associated with remote communication, people start hoarding the inventory in form of working on only READY stories and in turn introducing waste.

Face-to-face interactions on the other hand speed up building the high-trust environment leading towards self-organized teams.

In a given context, it’s recommended to form a collocated team. Sometimes, it may not be possible to form a collocated team considering some constraints. But we should be keep going to the First Law and try to make it happen.

One such example was a case of a Scrum team in a large bank. Most of its developers were working from India but testers were working from Malaysia. In short term, it was not possible to form a collocated team considering the testing team-members working from Malaysia only had relevant domain knowledge.

However in the long term, the domain knowledge could be transferred to development team based in India. Eventually the leadership helped in resolving this problem and it became a completely collocated team.

Summary

  • First law of Distributed Agile – don’t distribute if you can avoid distributing in the first place.
  • If you really need to distribute, prefer forming local cross-functional teams and let the representatives from a number of individual Scrum teams collaborate through Scrum of Scrums.

References

  • The First Law of Distributed Objects Design
  • Co-location still matters
  • Why “Definition of Ready” is Mandatory in Distributed Agile?

Overcoming Cultural Differences in Distributed Agile Teams – A Case Study

by ShriKant Vashishtha 1 Comment

Overcoming Cultural Differences

Recently I had a discussion with one of my dutch friends who has a company based in India. He mentioned that sometimes it gets very difficult to understand and handle cultural issues with his Indian colleagues. Issues which he mentioned are not new and people from western countries interacting Indian teams must be very well aware of what I’ll mention here. Some examples:

  • One person speaking on behalf of the entire team and other people either keep silent or just reply in terms of yes and no
  • Always saying yes to everything even though even customer may already be aware that the task may be difficult to achieve.

As you investigate further, these instances are very common in the team coming from hierarchy centric cultures where only senior and so-called senior people have a say, while the rest just follow what’s asked them to do.
[Read more…] about Overcoming Cultural Differences in Distributed Agile Teams – A Case Study

#NoStandup – Remote Team Collaboration Patterns

by ShriKant Vashishtha 2 Comments


What happens when each team-member of your team works from a remote location (possibly from a different time-zone and country).

How do you sync-up in such a team?

[Read more…] about #NoStandup – Remote Team Collaboration Patterns

Why “Definition of Ready” is Mandatory in Distributed Agile?

by ShriKant Vashishtha 1 Comment

In one of our earlier posts I discussed the elements and benefits of “Definition of Ready”. However it’s quite common to see totally opposite views of purists as they believe that Definition of Ready is not required at all.

quote-lack-of-clarity-is-the-number-one-time-waster-always-be-asking-what-am-i-trying-to-do-brian-tracy-121-38-84

I agree to their views to some extent if it’s all about collocated teams supported by dedicated product owner in the same time zone.

However, distributed Agile is a different beast altogether. It’s quite common in India to work with customers in opposite time-zones. Distributed communication essentially is an overhead. So the clarification which you receive in minutes face-to-face with collocated product-owner may require multiple iterations of distributed communication. Multiple iterations essentially mean multiple days.

So a READY user-story which could be finished in 2 hours now takes days to complete because of to and fro communication between distributed team-members to resolve unresolved queries.

Definition of Ready in such cases helps in bringing clarity and in keeping team members and product owner on the same page. Any absence of clarity essentially complicates the cycle time and throughput of a sprint.

More on Backlog Refinement, Story Points and Agile Estimation

This post is a part of a blog post series on story points and agile estimation. To read rest of the posts on the subject, please navigate to All About Story Points and Agile Estimation Series.

Distributed Agile Patterns : Define Overlap Time

by ShriKant Vashishtha Leave a Comment

Distributed Agile teams are reality these days. For sure there are overheads. But it’s all about trade-off between ‘distributed Agile overheads’ vs combination of availability of talent at any given time, scaling teams at will and lower cost.

Communication overheads are mitigated through phone/Skype/hangout calls with screen-share. It’s usual for people to do remote pair programming. However many times, collaboration fails.

Distributed members/stakeholders are not available in time. Work, which could be finished within hours takes days/weeks of cycle time in to-and-fro communication. Product Owner is a busy person all the time. Getting hold of her becomes a very difficult task.

How to mitigate these challenges?

[Read more…] about Distributed Agile Patterns : Define Overlap Time

  • Page 1
  • Page 2
  • Page 3
  • Go to Next Page »

Primary Sidebar

LikeBox

Tags

5 Whys Acceptance Criteria Adoption agile Agile Culture Agile Estimation Agile Offshore Agile Teams agile testing Agile Thinking Agile Transformation Agility Appraisals ATDD Automation Backlog Grooming BDD Big Picture business analyst Capacity Planning case-study code quality Collaboration Daily Scrum DevOps distributed agile Distributed Scrum Estimation Good Practices kanban kanban-mythbusters lean Metrics Planning Poker Prioritisation product owner Scrum ScrumMaster Sprint Sprint Demo Sprint Retrospective Story Point Story Points Sustainable Pace User Story

Categories

  • Agile
  • Agile Leadership
  • Agile Testing
  • Agile Transformation
  • ATDD
  • BDD
  • Continuous Inspection
  • Culture
  • DevOps
  • Distributed Agile
  • Estimation
  • In Conversation with Tim Ottinger
  • Java
  • Jira
  • Kanban
  • Lean
  • noprojects
  • Patterns
  • Presentation
  • Product Owner
  • Scaled Agile
  • Scrum
  • Software Metrics
  • Testing
  • Testing Practices
  • User Story

Copyright © 2025 · Malonus Consulting LLP

  • Email
  • LinkedIn
  • Twitter
  • Facebook
  • Privacy Policy