Learning from Distributed Agile project


It's been quite some time that I am involved in a project, which involves distributed agile team. There is a lot I have learned being the project manager on the team and I would want to share here.
The project is distributed across Bangalore and Cincinnati. By the way a distributed team is the one, which is constrained from collaborating in person or face-to-face. Typical set up I am in is, smaller team onshore and a larger team offshore. Smaller team, which is onshore, has the advantage of being closer to Product Owner.

This post is mostly to share my experiences and learning from managing such a team and helping the team to deliver. One thing for sure is it's not easy to implement, it has its own challenges. Below are some of the items, which we need to take care a lot in a distributed agile mode:


  • Communication: As I mentioned earlier that there is a small team, which is present at onsite gets the advantage of sitting next to Product Owners. Apart from this there are other roles as well like architecture team, database team or 3rd party system experts present there. Communicating with these people are very critical for the product you are developing. Better communication would result in better decisions and eventually a better product. Communication between onsite team with offshore team would also be a challenge. At times the offshore team is just a part of the decision being made onsite and largely responsible for execution of that and they miss the whole discussion part which is enriching and learning in itself. Fundamental doctrine of agile is team collaboration, face-to-face communication, and recurring customer conversation. If you want to succeed you need to find ways to implement this. One thing which helped the dev team is having distributed dev huddle once a week and the whole team gets to discuss bunch of tech items and other stuffs which they prioritize. 
  • Trust: To deliver a goal you need a team bonded by trust. The offshore team needs to trust the onshore team and vice versa. Some of the key practices which helps build the trust are inception where you bring the whole team together for a common goal, travel plan on rotation basis. If the offshore team is small and there is a budget I would suggest to move the team to one location and run at least iteration together. This would really help build the trust. Otherwise if there are budget constraints then proper travel plan needs to be factored in. This should mostly be on rotation basis and across roles so that everyone gets a chance to interact with the onshore team, Product Owners, Architect team and establish trust and confidence. Having a developer travel is generally the followed practice but I feel even the QA and BA should travel. QA travelling onsite would actually understand how the Product Owners test the application and what they look for in before signing off the story. Similarly having a BA travel would help you accelerate on the analysis front and would result in creating a healthy analysis backlog.
  • Promoting Shared Vision in team: In agile there is a great importance of iteration planning, retrospectives and daily stand up. There should be an effort made that the whole team is available and take part in these activities. Participation brings in the sense of ownership.  Project management tool we use play a big role in promoting the shared vision. Using a common agile wall and developer picking up work from the same wall help diffuse the knowledge silos.  In distributed team there is a challenge to find that common time where the whole team could be present. Having the whole team present in the distributed stand up adds to this shared vision. Apart from Stand up, even Retrospective is a great place to bring up what's not working in the favor of team and what needs to be done. Ideally both the team should do a joint retro every iteration. Due to time constraints it might not be feasible to have one joint retro, then both the onshore and offshore team should share retro notes with each other.
  • Short Iterations and Continuous Integration: Short iterations help you track progress on a regular basis. It allows you to seek feedback regularly and track the progress. Short iterations also help you break the tasks down in a smaller step thereby helping you estimate more correctly. On almost all the projects I have worked in ThoughtWorks, implemented continuous integration. There could be a different blog post all together on the benefits of CI. However in distributed team CI proves really valuable. CI with a good test coverage is a must have for distributed team. It helps you find out the build issues immediately. Both the team endeavors towards a green build. Also CI is not about the tool it's more about the discipline and taking team responsibility to ensure a working application with every check in.

 Above listed are some of the items which played a a very crucial role in steering a distributed project to success and largely from my observations.

Popular posts from this blog

Defect Tracking System – Wastage of Money & Time ???

Image
As a QA I have been logging bugs since 5 years. But what do we do with that ? A typical flow: If this is the only thing we need to do then why taking so much of pain to have a defect tracking system . To log a standard bug (Standard Bug= Broken Functionality), we need to write steps to reproduce, pre-requisites (if any), expected result, actual result, priority, severity, snapshot (if any), Test environment details and finally save it. This takes around roughly 3-5 minutes to log a bug. To say truth, I have never seen any report coming out of defect tracking system which is of use in analyzing the pattern of bug or finding out any trend in them. All I have seen apart from tracking usage, is the summary of bugs with count based on Priority and Severity. Is that the only purpose of Defect Tracking System? If that is the case then why not use a Google spreadsheet rather then investing money of the company and time of QA in a bug logging system. I am sure if we mine the data which i
Read More »

The 3 qualities that will always help you become better at almost anything…

Image
Have we ever noticed how excited we are when we start anything? But it’s a sad fact that 70% of people abandon what they have started with so much energy and love. It could be as small as building a hobby or starting a pet project or even an activity or a side learning we started. “ Well begun is half done .” Aristotle did say this but we are judged for how we have finished something. You separate yourself fro m  the masses when you choose to give that task a finish.  The first quality is finishing off what you started and it helps develop mental stamina or willpower.   It builds confidence and inculcates as a habit in a long run. You don’t need to sign up for the mammoth activity to build this habit, even finishing mundane day-to-day routine tasks will help. Diligence — the quality of working carefully and with a lot of effort Diligence is a quality that almost never will get unnoticed. It’s one of the underlying traits of great works or success. The key to mediocrity on the o
Read More »

Test Case Paths : Happy, Sad & Bad

Image
I came back from the background of writing test cases which were categorized in either Positive or Negative test cases. Positive test cases were business flows which may or may not give any result but they will certainly not give any exception or error. Negative test cases are those test cases which were bound to result into some exception or better expressed as error causing scenarios.  Then those positive test cases were prioritized as High/Medium/Low . Finally it used to result in quite a comprehensive test case document. Then it will go through the process of review and few more updates or change of priority etc. Certainly it is a tedious process. Here in ThoughtWorks I got introduced to different way of categorizing test cases called “ Happy/Sad/Bad ”. A test case which results you in a positive result is a Happy path , for e.g. entering proper username and password on login page. A test case which yields no result like entering invalid username and invalid password on a logi
Read More »