by Priyanshu Goyal (2007-07-17) permalink
Read the full article
With Agile practices a distributed team is so far yet so close. It is actually one team
A typical distributed development team works on a piece of software or sometimes entire system based on a set of requirements passed on to them either from the client or a team of guys working on a part of the same system onsite. This is generally referred as plan-based approach and the requirements are mostly document-driven.
They work day-in and day-out on these requirements for a good period of time without getting much chance to interact with the customer, or may be even with the team onsite making them feel really away from the where the action is.
They work and they deliver but is it the right stuff? How does a non-agile distributed team know that they are going to deliver sometime which is needed by the customer? How can they get the confidence that they do understand the project requirements? (Although told and documented but we all know how rarely it works that way)
Pretty sure when people came up with agile practices, they must have never thought they are really helping a distributed team come and take up a place at the center of the stage along with onsite team or may be they are not two teams but one with agile! Here is how agile supports one team feeling.
• Stand-up daily – Every member of the team be it onsite or offshore go through this at the same time together each day, thus very well aware of the current status of the project, who is doing what, what are the risks/impediments/issues and most importantly gets a feeling of what they are doing really matters a great deal for progress of the sprint. Many a times even the offshore team gets a chance to see the real stakeholders participate in such meetings as chickens
• Every one is an owner (Collective ownership) – The onsite and the offshore teams have a collective ownership of the code and deliverables and help them get a feeling of one team working towards one goal in real sense.
• Team participating in effort estimates – Whole team gets a chance and opportunity to estimate the stories and organize it and also to blame themselves if things do not go right. A progress/sprint burndown chart is good visible representation of how the team is doing during the sprint for the team as well as for the customers.
• Frequent check-ins and continuous integration – XP forces a team to do very frequent check-ins and with a good continuous integration process in place ensures a report is generated of good stuff and wrong doings of a team. This may impact the work of any member onsite or offshore in real time. There is no need for merging offshore and onshore pieces as they share the common code base.
• Automated Tests – Automated acceptance tests is a way to specify, clarify and verify requirements with a lot of team and customer involvement.
• Showcase what you have (Small releases, end sprint demo and sprint planning meetings) – Distributed teams gets to interact, clarify doubts, ask for feedback and do an exhaustive retro inspection very frequently as part of these meetings because of immediate access to the customer.
• Split it on functionality – Agile practice advocates that each team work on different pieces of functionality and not necessarily on different activities. So the distributed team is involved with important aspects of software development life cycle such as analysis and design as well.
• Communication is all what matters (Collaborative tools) – One of the value of XP is communication and with tools for VOIP, instant messaging, issue tracking and Wiki (confluence) frequent communication and collaboration is very much possible with the client and the onsite team. Good and frequent communication provides a platform for emerging requirements, technology and team capabilities.
• Taking it to extreme – Though difficult, distributed pair programming is possible or may be pair for a few time and then disperse. It is taking the one team feeling to the extreme.
• Dealing with reality and not artifacts – An agile distributed team feels that they are doing something for real and not just going through an archaic process of creating artifacts/deliverables one after the other. An agile distributed team knows a lot about what is actually happening and most of the times aware of how are they doing, in catering to client requirements because of short iterations build on the principle of inspect and adapt.
So all in all Agile principles, practices and tools can help to address the issues of distributed development to a very large extent bringing them closer to the onsite team.
Rating: 4.0 out of 5 (1 rating)
Source:
File Type: MS-Word
Owner: admin
Categories: Communication
Updated:
