• 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

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?

Kanban Mythbusters: When to Use Scrum and When to Use Kanban?

by ShriKant Vashishtha 1 Comment

Kanban comes with the least prescriptions but then you find lots of fake implementations in practice.

Lots of times, people move to Kanban from Scrum just for the convenience.

It’s far easier to live with a process model with no time constraint, no pressure to improve continuously. Also some people get away with a Kanban board with no WIP limits. Even if they put WIP limits in place, you see no discipline in maintaining WIP limits or changing them when required.

Scrum is a Shu or Ha (Shu-Ha-Ri) kind of framework which can be immediately used by beginners. It has valid prescriptions to start with. It’s evident that the process model with the least prescriptions (Kanban) requires more discipline and should be in Ha or Ri category.

When to Use Scrum?

Scrum is useful when a cross-functional team works together within a timebox (sprint) towards a sprint goal. It doesn’t work when you don’t know on what item you’ll be working next and sprint can’t be planned.

[Read more…] about Kanban Mythbusters: When to Use Scrum and When to Use Kanban?

Kanban Mythbusters: Limiting WIP is NOT the Goal

by ShriKant Vashishtha Leave a Comment

Kanban comes with the least prescriptions but then you find lots of fake implementations. Kanban talks about visualising the workflow. These workflow steps are columns in Kanban visual.

In many fake implementations these columns become the siloed boundaries of the individuals working there. They maintain the WIP for their workflow step and just keep working within that boundary.

In software development for instance, developers may keep working within their WIP limit and may just want to limit work-scope to keep on development. Other workflow steps may become outside of their preview.

The WIP limit in such cases becomes static.

But such implementation of Kanban doesn’t help anyone.

Everything may be happening by the book, i.e. visualization of the workflow and limiting WIP. But still it may not help anyone just because visualisation and limiting WIP is not the goal. Limiting WIP is mere a mean to manage flow. In this story, people may be limiting WIP but if flow keeps stopping or keeps getting delayed at different workflow steps, it will not help anybody.

A workflow with lots of delays or bottlenecks
A workflow with lots of delays or bottlenecks

One may need to change WIP limits further to optimise flow and have a tab on the flow on continual basis.

The goal is not limiting the WIP. The goal is to have optimized flow.

Kanban Mythbusters Series

There are other posts on Kanban Mythbusters series which you may find interesting

  • If You Need Kanban in Scrum, You’re Probably Doing it All Wrong!!!
  • Kanban Mythbusters: When to Use Scrum and When to Use Kanban?

Our Sprint Velocity Never Seems to Change. We don’t Know Why!

by ShriKant Vashishtha 2 Comments

Story point is about size, not about time.

At best it can be about a range of time but not about absolute time. In many teams people map story point directly to time and may get into vicious cycle towards burnout.

Let’s try to understand why.

Let’s say, the team mapped 1 story point to 1 day. As they do that, the team velocity becomes almost constant. The reason being, the team capacity in terms of number of days remains constant.

As team mapped 1 story point to a day, the story points to be planned or achieved will always be around the capacity (number of business days available) of the team.

Management folks may complain that team throughput is not changing. Throughput might have already changed but it will never show up.

Instead of completing 10 similar sized stories, team may be finishing 14 already but that will never reflect as number of days required to accomplish them remain constant from sprint to sprint.

So never map a story point to time unit as that will create more problems than it solves.

More on 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.

Demystifying Continuous Delivery

by ShriKant Vashishtha Leave a Comment

We face real-world challenges where straightforward answers provided in rule books are in conflict with empirical evidence. That’s where Tim helps us understand these nuances and demystifies the problem space.

Our Slack group “Agile Commune” contains many insightful conversations with Tim. We’re publishing some as part of “In Conversation with Tim Ottinger” series. Looking forward to your comments and experiences on these topics.

People talk about CI (Continuous Integration) and CD (Continuous Delivery) in the same breath but may not be aware of their differences: Continuous Integration in itself is not Continuous Delivery.

Similarly, people used to releasing multiple features in a rollout may find it difficult the need of multiple deployments in a day OR multiple releases for a feature.

So let’s hear from Tim more on Continuous Integration, Continuous Delivery, and DevOps!

[Read more…] about Demystifying Continuous Delivery

  • « Go to Previous Page
  • Page 1
  • Page 2
  • Page 3
  • Page 4
  • Page 5
  • Page 6
  • Interim pages omitted …
  • Page 22
  • 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