By Belatrix Software | Topics: Software Development
Innovation, Product Development, User Experience, User Interface, UI, Visual Design, Usability
With the right knowledge and the right set of skills, Agile distributed teams will become an integral part of your development capabilities. However working with Agile teams distributed around the world is anything but easy. The key challenges such teams typically face are:
In order to overcome these challenges it is necessary to examine several key factors including the team size, team composition, and the workload distribution of the team. We will address each of these in turn.
There are two main factors to take into consideration when building your team:
Maintaining even workloads across the team is a critical component, but can quickly become complex. A quick overview of an Agile team in action:
User stories allow us to estimate the complexity of various story points- with the goal being to get an overview of the complexity of the project, but also to track the team velocity in a consistent way. As a result it is possible to gain an approximate measure of the complexity or size of the project. By calculating the team velocity and project size, it is possible to know how much time, effort or resources should be assigned to a particular project.
The result is a high level estimation- it is assumed to be erroneous. But it is better to be almost right, than completely wrong. It is simply an approach that will allow us to decide whether the project makes sense, considering the benefits it would provide to the organization and the investment it would require.
Although it is hard, there are some widely used tools and methods which help with sizing user stories. One of the most common methods is using the Fibonacci Sequence as a series of possible values. The idea behind using this sequence is to provide easy differentiation between a small user story and one than could be double or triple in size or complexity. But at the same time it is possible to jump quickly to higher numbers, avoiding useless discussion about whether a “big user story” is a little bigger or a little smaller.
Ultimately it is about trying to estimate volumes. For example you can probably do a good job estimating how many caps of water you need to fill a small bucket, but it´s tough to estimate how many caps of water you need to fill the building you are sitting in.
Creating accurate estimations of the size of the user story is a frequent challenge. The problem is that many individuals will simply repeat what more senior team members have stated. In Agile there isn’t time to give everyone the space to outline their thoughts in detail for every user story. Poker Planning is therefore a tool which forces everyone on the team to make their best effort on providing an accurate sizing.
The rules of Poker Planning are simple:
The benefit of Poker Planning is that everyone in the team has the same opportunities to express themselves, but also the same responsibility of providing an accurate estimation. If there is agreement, then that number can simply be assigned to the user story. But if there is a big difference in the selected sizes, then identify who has selected the smaller and the larger numbers and give them the opportunity of stating to others why they think it is that simple or complex. In many cases this will provide fresh information which enables everyone to review their estimations.
The rule is to move quickly when there is agreement, but take some time for discussion when there is disagreement. A second round of voting for the same user story can be completed to ensure all the team members are on the same page. After that move onto the next user story.
The simple secret to Planning Poker in distributed teams is to continue to ensure that votes are not influenced by other teammates. Therefore a platform is required. The good news is that there are many electronic platforms that can facilitate this process. Planningpoker.com is one of the most popular free tools available.
The on-going day-to-day management of distributed Agile teams can be challenging, particularly with regard to the communication between team members. Best practices for successful management include:
To manage the artifacts needed to enable working in a Scrum project, such as the product backlog and the sprint backlog, use a collaboration portal to support storing Scrum artifacts. This is particularly important for distributed teams where 100% transparency is required. To achieve this, together with real-time feedback and visibility throughout the development process, use Agile project management tools like JIRA with Green Hopper, Rally, VersionOne, Mingle or PivotalTracker.
In many cases for distributed Agile teams, the typical artifacts remain the same as for collocated teams. However in some cases these will differ, or specific artifacts gain additional importance, such as the burndown chart. The following section provides an outline of the typical artifacts.
The product backlog is an ordered list of requirements that is maintained for a product. The items are ordered based on considerations like risk, business value for the company, dependencies, and milestones. The product backlog is what will be delivered, ordered into the sequence in which it should be delivered. It is open and editable by anyone, but the Product Owner is ultimately responsible for ordering the items on the backlog for the team to choose. For distributed teams it is essential to use a virtual task board so that all members have clear visibility into the current status and progress of the team.
Items are estimated in hours or story points. These estimates help the Product Owner estimate the timeline and may influence the ordering of backlog items. The size (i.e. estimated complexity or effort) of each backlog item is, however, determined by the team, which contributes by sizing items, either in story points or in estimated hours.
The sprint backlog is a subset of the product backlog, and is the list of work the team must address during the next sprint. The list is derived by selecting product backlog items from the top of the product backlog until the team feels it has enough work to fill the sprint. This is done by the team asking “Can we also do this?” and adding product backlog items to the sprint backlog. The team should keep in mind its past performance assessing its capacity for the new sprint, and use this as a guideline of how much “effort” they can complete.
The product backlog items are broken down into tasks by the team. Tasks on the sprint backlog are never assigned; rather, tasks are signed up for by the team members as needed according to the set priority and the team member skills. This promotes self-organization of the development team.
The sprint backlog is the property of the team, and all included estimates are provided by the team. Often an accompanying task board is used to see and change the state of the tasks of the current sprint, like “to do”, “in progress” and “done”. Similar to the product backlog, for distributed teams, a virtual product backlog is required so that all team members have visibility.
Once a sprint backlog is committed, no additional functionality can be added to the sprint backlog except by the team. Once a sprint has been delivered, the product backlog is analyzed and reprioritized if necessary, and the next set of functionality is selected for the next sprint.
Another important artifact is the burndown chart, which is especially important in Agile distributed teams because of the visibility it offers on how the sprint workload is being achieved in one, or through several teams. The sprint burndown chart is a publicly displayed chart showing remaining work in the sprint backlog. Updated every day, it gives a simple view of the sprint progress. It also provides quick visualizations for reference.
The basics of a burndown chart are:
How can we assure the quality of the code delivered through teams across various locations? The answer is to do code reviews with video and screen sharing to increase the richness of the experience. Specific tools like Crucible, Gerrit or Code Collaborator of Smart Bear, will help here. Code comments are very important for team interaction. JIRA, for example, provides Crucible, which is a helpful plug-in that tracks comments and relates them to a particular ticket and also relates them to the specific piece of code being delivered.
Code reviews are mostly done peer-to-peer, but sometimes can also be done in groups, which is an excellent way to spread and extend the expertise concentrated in one site or in one person to the rest of the group.
A fundamental moment of a sprint is the sprint review, called the “Demo” because it is the moment when the team demonstrates what has been accomplished during sprint. This stage is particularly important for showing key stakeholders and sponsors of the project what has been achieved. Typically a desktop sharing tool will be used here (such as GoToMeeting or Join.me). Again, a desktop sharing tool helps bring together people who are not physically sitting together.
This report has outlined some of the challenges with distributed Agile teams, but also highlighted some key ways in which these challenges can be overcome. In many cases, there are simple solutions which can have a dramatic impact. For example, if you are having difficulty with quality assurance, simply get the local QA team to talk through the test cases with the distributed team members to help them understand the specific issues. The Scrum Master will play a vital role in ensuring the distributed team works well together – for example, setting the conditions for easy communication, and visibly sharing the progress of the team.
Many of the best practices for working with Scrum, such as Poker Planning, will work well in distributed teams, but you may need to modify them to your specific environment (such as by using an online tool) to ensure the best practice remains effective.