The Power of India and Distributed Agile

The past decade, I’ve been learning how to manage distributed teams in a productive way. In 2004, I made a trip to India and fell in love with the country. I had decided to start my own company and one of the ideas I had was to offer outsourcing services to Dutch companies (I’m from Holland). In the early 2000s, it was mainly US enterprises outsourcing to India. In Europe, just a few pioneers were taking their first steps. When I walked around in India, I was amazed by the energy the IT industry had at that moment. I did see that as a Dutch, there’d be some challenges in working with people from such a different culture.

When I started out in 2005, there was no scrum and agile (they were there, but not used by many companies yet and I was not aware). Everything was fixed dates, price and traditional project management, waterfall based development. I had decided to work with teams in Ukraine, because it felt a bit closer and was easier to travel to for Dutch people (no visa, short trip, 1 hour time difference). My company started taking off in 2006-2007 and I was getting more work than my partner in Ukraine could serve. So in 2008 I decided to move to India and setup our office there.

I had no corporate budgets available to setup my Indian office, so I did everything bootstrapped. A simple office, hiring programmers one by one based on customer demand. Apart from the challenges in learning how India works, my main challenge was to make Europe-India collaborations work out. Two big challenges I faced:

1. Cultural alignment

Most countries vary in the degree of hierarchy that governs families, society, companies. In India, hierarchy plays a big role. People are used to having fathers, teachers and bosses give ‘instructions’. Because of that, the level of ‘proactiveness’ is often low. Questioning authority and challenging superiors assumptions is not done. In the US and Europe, many countries have a ‘flat’ structure. In the Netherlands for example, people are expected to question assumptions and encouraged to come up with their own ideas. It doesn’t matter what level within an organization the idea originates from. Another example is the level of openness. As a Dutch person, if I have a problem with the way you behave, I will tell you what’s on my mind. My belief is that by sharing my concern, we can find a way to solve it together. In India, people are not used to this. They’d rather polish a story, speak around the concern they have without addressing it heads on. Or they’ll say yes in all cases. As a Dutch I might not understand the message the person is giving me because I am used to getting it unpolished, straight into my face.

All the above made it challenging for us to create stable relationships between our European clients and our Indian teams.

2. The black box

When we were doing projects, the second big challenges we faced was around customers see your development organization as a black box. They don’t know who’s working on your project and they don’t know how the work gets done. Because the contract states when things need to be delivered and at what cost, they often don’t care to connect with the team members. The distance between the customer and your team are very big. Now this is the case in any software project, but the distributed nature magnifies the impact. Because the distance is big, teams often don’t have an emotional bond with the product they’re building. They don’t interact enough with the customer and are busy with the tasks assigned to them.

Things started changing for me, when we started working in teams that were ‘one’ with our customers teams. To achieve that, we used scrum. One of the biggest benefits of agile for distributed teams is the close collaboration with the product owner (who should be on the customer side in my view). If product owners are engaged, join the scrum events and make themselves available throughout the work, things change for the better. Relationships and understanding evolve from this, which leads to better quality and smoother work.

Fast forward a decade. Agile India is the biggest Agile conference in Asia. I see more agile coaches and agile transformations going on in India than anywhere else. I’m currently living in Indonesia and India is miles ahead with agility. I have learned the hard way that without agile, it’s very challenging to make distributed collaboration work. What you want to achieve is self organizing (collocated) teams in India who are empowered to use their minds to come up with their own solutions. Teams that have the freedom to do what they believe is best instead of the traditional command and control that is common in India (and many other places). You want collaborations between onshore and offshore team members that are based on the idea of ‘one team’. True partnerships instead of ‘us versus them’.
I believe India has come a long way in the past decade. Many companies have gone through the challenges I faced and have learned how to deal with them. The IT population grew more mature (and with that the availability of senior developers and leaders). It’s not only the ‘outsourcing destination’ of the world, but it’s a tech powerhouse, producing valuable products for companies across the globe.

To Scale or Not To Scale, that is the Question

Don’t miss our podcast discussing this topic on the Agile India Podcast – RSS

Register Today to Agile India 2017

How to scale Scrum and agile to large organizations has been a hot topic in the community since 2012. The advent of new team level practices has leveled off and the industry has more or less settled on a set of standard practices, whereas how to organize teams of hundreds or thousands of people was less defined.

In the past several years, a handful of scaling frameworks has emerged: Nexus, SAFe, LeSS, DAD. They’re all trying to tackle the same problem: How do you improve agility in a complex system with interwoven dependencies over a large organization?

To an organization attempting to select a scaling framework, the choices can feel overwhelming. To compound competition in the scaling arena, there exists an active community who insist scaling simply doesn’t work.

Jez Humble falls into the latter camp; At Agile India 2017, Jez will be giving a talk on “Why Scaling Agile Doesn’t Work.” In this talk, Jez will explore the pitfalls he sees with existing scaling frameworks. In Jez’s previous talks, he has railed against the trend of taking large projects, splitting them into small pieces, and farming them off to teams. One of the biggest risks with large projects is that it doesn’t tackle the underlying uncertainty in software development by validating hypotheses before spending large amounts of money.

The other pitfall Jez identifies is disconnecting measurable outcomes from the people doing the work. This can lead to a decrease in employee morale if they don’t understand the purpose behind the work they’re doing, and also removes the opportunity to leverage the brainpower of your development team to come up with innovative solutions and to raise issues with the approach. As Esther Derby puts it, we “separate the head from the hands.”

By developers and product managers working together to find solutions toward a particular outcome and running experiments to validate hypotheses, teams will be more engaged and can avoid waste in development. This is a topic Jeff Patton, an Agile India Keynote alumnus, talks about in his book User Story Mapping.”

To look at the value of scaling frameworks, we first have to understand some of the common problems they are trying to address:

  • How can we reduce dependencies between teams and manage dependencies where we cannot eliminate them?
  • How can we identify bottlenecks in the system and improve flow?
  • How can we address cultural issues in an organization to reduce handoffs and increase a shared sense of ownership?

These frameworks contain a wealth of practical tools to help organizations enhance their agility. At the outset, this looks daunting, and for the uninitiated, it could be challenging to find a place to start. For organizations looking to shift their approach, it is helpful to have some patterns to follow.

The risk can come if an overly prescriptive approach is taken. These frameworks come with a plethora of tools. However, much of this can be situation dependent, just as it is at the team level. For example, Scrum may work great if you have a single client that you can meet with on a regular cadence. You may want to consider Kanban instead if there is high variability in the rate at which work arrives. In complex systems, there are more variables to consider. One size does not fit all.

Don’t Miss the Panel Discussion at Agile India 2017

Agile Scaling Frameworks and their Eco-System – Boon or Bane?

Over the last few years, as agile has gained traction inside the enterprises, we’ve seen many scaling frameworks have sprung up. These scaling frameworks claim to retain the core agile values & principles and aim to provide a simple yet comprehensive way to scale agility across the organization. There have been several success case-studies that have been published. We also hear and see many horror stories of failed scaling attempts.

In this panel, let’s have a critical view of the entire scaling framework eco-system.


  • Jutta Eckstein – Independent Coach, Consultant – Germany
  • Scott Ambler – Co-creator of Disciplined Agile – Canada
  • Bas Vodde – Creator of LeSS (Large-Scale Scrum) – Singapore
  • Kurt Bittner – VPEnterprise Solutions @ – United States
  • Jez Humble – Owner @ Jez Humble & Associates – United States
  • Francis Kelly – VP @ Scaled Agile Inc – United States

Register Today to Agile India 2017

Docker: 3 Ways to Improve Agility Using Containers

Container technologies such as Docker are rapidly changing the landscape of development and infrastructure. Finding practical, achievable ways to start leveraging containerization technologies may seem daunting. Fortunately, there are a few simple and accessible options to start reaping early benefits without requiring an overhaul of your entire infrastructure.

Rapid Technology Evaluation

A subtle barrier to trying new technologies is the step to download, install, and ultimately clean your machine up if the technology doesn’t pan out.  

Docker enables technology innovation by providing developers with a quick sandbox to try new technologies. Say you want to try Node.js? Just pull the Node container and start coding. Didn’t like it? Throw out the container a move on. The diversity of official images on Docker Hub lowers the barrier to evaluating technologies, accelerating experiments and spikes.

Consistent, repeatable development environments

The phrase “it works on my machine” should mean something. How much time do developers spend debugging issues that result from having slightly different environments on dev, test, and prod? Docker forces environment parity, allowing developers to focus their time adding value rather than fixing bugs.

Containerizing your dev environment can be as straightforward as adding a simple Dockerfile in the root of your source tree. IDEs such as Visual Studio and IntelliJ are rapidly improving their support for remote building and debugging with containers.

Scalable continuous integration pipelines

An obstacle to scaling a continuous integration system is time spent configuring and maintaining build agents. The phrase “cattle, not pets” was coined by Gavin McCance. Docker makes it easy to have environment parity across build agents.

ConcourseCI Screenshot

ConcourseCI uses containers to make build pipelines first-class citizens.

We’re keenly watching technologies such as ConcourseCI that use containers as a first-class citizens of build pipelines. Adding more developers to your team? Looking for more better feedback through more frequent CI builds? ConcourseCI is the first continuous integration system that easily scales.  As each task in the build pipeline is run from within its own container, the build agents themselves do not require specific configuration, making scaling much easier.

Want to learn more?

Come join us at Agile India 2017, 6-12 March in Bengaluru for more talks and demonstrations on containers, Docker and agility.  

Agile India 2017 Speaker Announcements

Conference planning is in full-gear and we have just released the first list of speakers for Agile India 2017.

We will be interviewing a number of speakers leading up to the conference.

Our first was with Woody Zuill where we delved into the topics of #noestimates and Mob Programming. Woody tells the story of how the #noestimates movement originated and goes into depth on the potential benefits of Mob Programming.

Subscribe to the Agile India Podcast for more interviews on iTunes, Google Play, or through your favorite podcasting app. Our RSS Feed is:

Upcoming interviews:

  • Esther Derby – Co-Author of “Agile Retrospectives:Making Good Teams Great” and “Behind Closed Doors: Secrets of Great Management”
  • Benji Portwin & Joakim Sundin – Agile Coaches @ Spotify
  • Evan Leybourn – Author of “Directing the Agile Organisation”

Please spread the word:

Agile India 2016 – 5 Conferences + 16 Pre/Post Conf Workshops (March, Bangalore)

Agile India 2016 Conference

Over the last 9 months, our program team of 26 volunteers from 8 different countries have worked together to put together a fantastic program for you.

We got a total of 333 proposals and have selected 108 proposals spread over 10 days.

Proposed vs. Accepted Proposals for Agile India 2016 Conference

Conference Speakers

We are happy to confirm that we’ve 86 Speakers from 18 countries presenting at this very conference.

Agile India 2016 Speakers

Conference Program

The team has worked very hard to make sure we’ve a nice balance of topics selected for you at the conference.

Agile India 2016 Proposal Type

Online Registration

Choose from 5 Conferences:

And 16 Pre/Post Conference Workshops:

Register here:

Agile India 2016 Sponsors

Big thanks to our sponsors for supporting the conference.

We’ve a couple of more sponsorship opportunities available.


Social Links:

Yuval Yeret Interview

Yuval Yeret is a senior enterprise Agile Coach at AgileSparks. He has substantial experience in coaching and leading the teams through Agile ways-of-working. He has led many long term strategic initiatives and one of the leading Kanban practitioners on the enterprise product development world.

He published ‘Holy land of Kanban’ and is the recipient of the Brickell Key Award for Lean Kanban community excellence. His experience in leadership/management along with his experience in  networking, security, storage in both Dev and Ops of IT/Product development gives him an edge in DevOps trend.

Yuval Yeret

Here is an excerpt from the conversations we had with him.

1. You received the Brickell Key Award for Lean Kanban community excellence, driving Kanban adoption in Israel. Tell us a bit about your experience popularising Kanban in Israel.

Well, It has certainly been an interesting journey so far. It is hard to popularise a disruptive innovation like Kanban under a strong incumbent like Scrum. I found that the best way to get traction for the ideas behind kanban was to focus on what job it could do better than scrum for people. Turns out Kanban is quite good at doing the job of educating leadership about Lean/Flow since its language is more explicitly connected to the Lean/Flow concepts. It is also quite good at helping organizations who like to “build their own agile” rather than following a methodology religiously. It is also a great “gateway drug” method to get you going towards a lean/agile way of doing things. The visibility and mindset you use catalyzes the right kinds of behaviors and structures. I’ve seen several cases of teams starting with Kanban on top of their waterfallish structures and processes and starting to use more agile structures and processes like Feature teams, User Stories, ATDD, CI as they learned about the potential value these changes might provide when considered through a flow perspective

2. You claim that Kanban is a match made in heaven with DevOps. Tell us why?

DevOps talks about System Thinking, End to End Flow, Closing and amplifying feedback loops. All of those can be done with an iterative approach but in most real-world scenarios are a bit hard to fit into a sprint and are better managed as a flow using something like a Kanban pull-system. At the other end, the highly mature teams with Continuous Delivery capabilities balk at the “slowness/inflexibility” of the scrum iteration and prefer a fast-flow kanban system. In addition, DevOps is typically a journey for most organizations. The most popular description of that journey is found in “The Pheonix Project” by Gene Kim (which is highly recommended btw). And that journey’s steps – System Thinking, Amplify Feedback Loops, Continuously Experiment towards improvement map very well to Kanban’s principles of starting with where you are with respect to how things are done and by who as well as the practices of Visualization, Flow Management, Different levels of feedback loops

3. What is the biggest challenge in implementing Kanban on DevOps?

I would say the biggest challenge is having the discipline and resolve to get to an end to end visualization of the workflow (especially if this is only in your sphere of influence, not your sphere of control) not to mention move to Pull mode and WIP limits. You step into dangerous territory when you convey messages like “we will not pull this, we’ve reached our WIP limit”.

Another challenge that is even more extreme in DevOps compared to typical Agile situations is the need for end to end leadership looking at the performance of the entire value stream. (Agile only needs to bridge the Product/Dev/Test)

4. DevOps and Continuous Delivery is becoming pretty mainstream. At companies where these approaches are used, what metrics are they capturing to prove the ROI?

I wouldn’t necessarily say DevOps and/or Continuous Delivery is mainstream. I think there is a big chasm to cross. The Innovators who were typically web companies like NetFlix, Flickr, Etsy, Flickr, Amazon, Google. Then came early adopter companies which ranged from other web companies to companies with adventurous IT organizations with a real need to innovate faster in order to compete and/or a real sustainability crisis to deal with. Based on these problems/reasons for DevOps the typical metrics are deployment frequency, lead time for changes, and mean time to recover from failure.

Early adopters by their nature are less interested in metrics and ROI since they went into DevOps with an urgent business problem to solve. So initially data wasn’t readily available. But as DevOps is trying to cross this chasm it indeed needs to make a stronger business case as the mainstream market typically looks for this kind of proof as well as the validation that DevOps indeed works for a similar context to the one they are in. People like Gene Kim and some others in the DevOps community realized this some time ago and started issuing “State of DevOps” reports yearly. The 2014 report goes beyond reporting on the benefits for these operational metrics and is able to show a correlation between these leaner operational metrics and better IT performance overall as well as even better business results.

5. What is your favorite DevOps principles? Anything that changed the way you view software development?

I’m a Kanban guy. So I like Systems Thinking and Visualization of the end to end flow. Every time I help a group look end to end and see the light bulbs turn on just by seeing the initial kanban board view of their current situation it is a very satisfying moment. Asking them to play “what if” and simulate the future or a past scenario makes it even more realistic and drives the understanding of the lean/DevOps principles even deeper. I also like to help people understand the cost of the delayed feedback in the way they are currently doing things and use it to reduce the batch sizes in their processes and justify investment in various practices and even structural changes. This combines the “Amplify Feedback Loops” principle together with Don Reinertsen’s Cost of Delay/Flow principles.

6. What are some of the common problems, while applying DevOps concepts to Enterprise IT/ Product Development as compared to hosted-web apps?

Well the toughest problem is that Continuous Delivery is much harder and sometimes even an unrealistic goal. This makes it harder to close the feedback loop. It also makes it harder to justify tighter internal loops as people will tell you “why bother”. The way I deal with that is emphasize the cost of delayed feedback not just the cost of delayed time to market. I also insist the organization try to find creative ways to close the feedback loop like a cloud-based lab, early access programs, etc. I also emphasize that DevOps!=CD. You can benefit a lot from the DevOps thinking, principles and practices without going all the way to CD. I find Reinertsen’s principles of flow very useful in this context.

7. Is there any special advice you would provide to people applying WIP limits to DevOps projects?

Especially when talking about enterprise DevOps your end to end flow will probably NOT be at the user story level. It will probably more at the “MMF”/Feature”/”Epic” level, whatever you want to call that unit beyond the story that DOES make some sense at the business level to deploy and enable for users. In these cases people should make sure that their WIP limits and their flow visualization in general apply at this level. In fact, in several enterprise DevOps cases we started from agile teams using some process like Scrum/Kanban/Scrumban and DevOps was one of the triggers for starting to actively manage the end to end flow of Epics/Features. To learn more, come to my workshop at Agile India 2015 conference.

This workshop has limited seats. Book early to avoid disappointments:

Mark Lines Interview

Mark Lines along with Scott Ambler, co-created the Disciplined Agile Delivery (DAD) which is a process decision framework designed to help organizations apply agile and lean for their unique contexts.  It provides guidance for “disciplined” application of agile across the enterprise.

Mark Lines

He show teams how to extend Scrum with other supplementary practices from a variety of methods such as Extreme programming, Kanban, Agile Modelling and the Unified Agile Process. He help teams apply DAD with its hybrid approach that is suitable to the unique needs of the organization. Mark has over twenty five years of experience in delivering software solutions.

Mark co-authored “Disciplined Agile Delivery: A Practitioner’s Guide to Agile Software Delivery in the Enterprise”. Also co-founded the Disciplined Agile Consortium, the certification body for Disciplined Agile.

Disciplined Agile Delivery

Here is an excerpt from the conversations we had with him.

1. What are the challenges in implementing Scrum for large complex projects?

Software development is hard.  Scrum is described by a 16 page guide.  Clearly that is not enough guidance to deliver enterprise, mission critical applications.  So in the past it has been left up to the practitioner to try and supplement Scrum with ideas from other methods such as Extreme Programming, Lean, Kanban, and others.  But even if one has the experience to piece together practices from these methods into something that makes sense, that is still only effective for individual, small project teams.  Once you are successful at the team level, scaling it across many teams, on projects of many different types can be very challenging.  Indeed, without a solid foundation that DAD provides it is very difficult to be successful applying agile across an organization.

2. How does DAD address the challenges highlighted above?

To address the challenges of being effective at the team level DAD is comprised of a hybrid of proven practices from the leading agile methods.  It provides a cohesive approach that addresses the complete lifecycle, not just the construction aspect that mainstream methods such as Scrum focus on.  Having applied the DAD framework properly, then we are ready to address scaling concerns such as distributed teams, compliance and regulatory situations, domain complexity, and large teams.

One of the flaws we see with other scaling approaches such as Large-Scale Scrum (LeSS) is that they rely on Scrum itself.  Although scaling based on Scrum makes sense in many cases DAD doesn’t prescribe Scrum.  In fact DAD has four different lifecycles which address other needs such as Lean, Exploratory (Lean startup) and Continuous Delivery.

One thing I would like to point out is that people often misinterpret DAD as being a scaling framework.  While it certainly is applicable for scaling, it is more often used for small and medium sized teams.  It is a “process decision framework”, providing guidance to customize your approach for the vast variety of contexts that organizations find themselves in.  One scaling framework will not be best in all situations.  Fortunately DAD is flexible.  We like to call it “pragmatic agile”.

To learn more, come to my workshop at Agile India 2015 conference.

3. Tell us a bit about what got you started with DAD?

That is an excellent question.  Both Scott and I have been using agile techniques long before the agile manifesto was written.  We had different names for things but we have been build software iteratively and incrementally for many years prior to 2001.  While Scott was at IBM he consolidated his own past work as well as harvested proven techniques from other methods into DAD.  It was during that time that we agreed to write a book on the framework.  Contrary to what many believe however, DAD is not IBM’s.  The Disciplined Agile Consortium is responsible for maintaining and evolving DAD.

4. Based on your experience coaching teams, how do they react to the hybrid approach suggested by DAD?

Without reservation I can tell you that teams that take time to understand what DAD really is and are very happy with DAD.  It bridges the gap between what project teams need to be effective with agile and lean and what the enterprises need for effective cross-team and program collaboration.

5. What is your take on certifications? How do they help the practitioners?

Scott and I have openly criticized agile certification schemes in the past so some people were surprised that we developed a certification program for DAD.  We decided that certification can be a valuable thing but the program needs to be credible.  As such, we have a multi-level Belt program that shows the progress of knowledge, experience, through to community involvement.  Lower level belts demonstrate experience on DAD projects while higher belts reflect coaching and organizational DAD transformations experience.

Regarding how certifications help practitioners, we have found that some organizations want to hire people that have demonstrated a commitment to learning what DAD is all about, and sometimes they want evidence that they have actually applied the DAD principles on projects.  In this regard it becomes a valuable thing for an agile practitioner to have on their CV.

Although not required, attending a DAD workshop is an excellent way to prepare for the Yellow Belt certification test.  Additionally, most DAD workshops include a free certification test.  More information on the certification program can be found at

This workshop has limited seats. Book early to avoid disappointments: