Much has been written about the difficulty of using Agile software development methods in scattered sections. Some thoughts are that the obstacles are so great that Agile can never win; Others believe that while communication is challenging, the other benefits of Agile outweigh these difficulties.
We use Agile methods to manage software development and personally I would rather offer Scrum to many others as a management tool to track progress. With all agile methods, communication is key and it becomes harder the more dispersed distribution of the client, team and other owners are, but there are ways around it.
In my case, here is a good example. One of our customers is located in eastern central England, technology development is located in london (as I'm a technology manufacturer), me – scrum master – i'm on the south coast of england and our development team (who also supports live programming) India – could not be much more spread if we tried! Those in the "too hard" camp would never have taken this project, which is a shame as they had learned a lot about the management of assigned teams.
Let me take you through a typical day:
Let me first set the area. Our development and support team is based in India, 5 hours. Ahead of the UK. This gives the first subjects – the time zone difference. Given that the client is in the UK and that we need to support their application, the team in India has changed their working day. They arrive later in the morning and work in the evening to suit the day of work. This means, however, that they start working a few hours for us apart from the support group (which provides 9:00 to 17:00), setting up for us; This works for us and we fix our time when we need to work on a particular problem or issue. One of the advantages of this is that it reaches our development day – the team can work in trouble overnight and introduce a solution when the customer arrives in the office in the morning.
At the start of the day, I will check email first to see if the team has sent me something overnight and needs urgent action. At the same time, I will log in to our chosen chat tool, which we use as the primary communication in real-time communication. I can see who's online and contact them quickly if we need to discuss any issues at night. Conversely, they can see me at the desk and contact me. This time the customer's team usually logs in and again we will cover all major events or issues.
Our product catalog and client are managed in the Wiki project and this gives us all the best visibility. I will review this and review something new and discuss the key issues of my technical route in India.
We have a well-defined publishing process and this begins with the pre-press conference. As a Scrum Master, I will facilitate this and a conference call to bring everyone together. This usually includes me, the development team and the customer's team. We have all the goods open so we can quickly move through the products to go to the next Sprint. Teleconferencing brings your own task when you can not see those involved, and at first it took time to develop a rhythm conference, but we know each other very well now and so we have picked up the nuances of everybody who calls. I will lead and, as we proceed through the call, I continually confirm all those involved. This usually takes an hour or so and when I finish, I follow this with a very quick "action list" email. When we have finished the conference call, the technical guide will discuss the matter with his team and then produce Sprint Backlog, which he will share with us all.
Our Daily Scrum is a virtual meeting and is usually held at. 14:30. Again, we will use a conference call and each team member will then have the opportunity to update us. This meeting is a 15-minute call, and I've actually found it easier to keep this timing in real-life rather than face to face when it can sometimes be difficult to stop talking to people. We've turned away from normal Scrum rules, and if I get online, I try to get a problem, I'll get a technical way to produce (very simple) Daily Scrum written report – but I still require each team member to complete parts for their workplace, which must be requested by management. Not strictly within the spirit of a day-to-day event, but it works for us with a diversified team.
Daily progress is taken with Sprint Backlog & Burndown Chart, where each member works by updating the remaining tasks for each project they work on. We are constantly exploring how to improve our information sharing with our Distributed Customers and Development Team, something that I always increase on Sprint Retrospective.
When it comes to developing and reviewing the user interface, this is harder because of our geographical position. We use the open-source archive application as simple (not downloading software for those who join) and free. This allows the user designer to share his desk with all those involved in the review and we can easily proceed through the design; It also allows critics to monitor and mark real-time real-time UIs to show what they are looking at. On the other hand, we use conference space during review and we continually confirm the understanding of all participants.
Before the technical equipment goes out for the day, we will intervene and discuss what matters the team needs to work overnight. And before I close, I will make sure that all traffic from the customer is marked and passed to the port group.
Over time, we have refined and improved the diffusion of our communications. We have a customer who works very well with our development team; They trust each other and work well together to solve problems. We thank everyone for working in a distributed environment, but, rather than using this as an excuse for poor communication, we all strive to improve our work practices. Using agile methods with a distributed team is not easy, but it is possible.