Published on: April, 2015
Topics:
- Methodologies
Published on: April, 2015
Mastering The Agile Method For Distributed Teams
By Belatrix Software | Topics: Software Development
Innovation, Product Development, User Experience, User Interface, UI, Visual Design, Usability
A Handbook For Achieving Success With Distributed Agile Teams
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:
- Communication. Software projects require a significant amount of communication, and even more when using Agile methodologies. It is probably the number one challenge that distributed Agile teams face, and needs to be addressed proactively.
- Leadership. Leaders are key to any successful project, but it becomes much harder to spread an organization´s culture and values to people in distributed teams.
- Culture. Cultural differences can play havoc in distributed teams. It is essential to develop empathy with other cultures and understand individual sensitivities and motivations. For example, countries within Latin America sometimes differ significantly with regard to their culture and typical organizational structure.
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.
Step 1: Build Your Team
There are two main factors to take into consideration when building your team:
- Team size. The team size will depend on the specific project scope, however typically it ranges from 5 to 12 members. These members will typically include one Scrum Master, development engineers, quality assurance (QA) engineers, and UX designer(s). A good rule of thumb is to add 1 QA for every two developers which is the sweet-spot for productivity.
- Personality traits. Some engineers aren’t a natural fit for distributed Agile. Specialized human resource teams can help with creating a framework for psychological insights on which to base your recruitment of engineers. This helps ensure they are well-suited to these kind of projects. In turn this will contribute to a stable team, helping to lower attrition.
Characteristics To Look For A Good Fit For Distributed Agile
Step 2: Getting Started And Distributing Workloads
Maintaining even workloads across the team is a critical component, but can quickly become complex. A quick overview of an Agile team in action:
- Start working with “Sprint 0”. During Sprint 0 the project is deconstructed into story points, sizing pieces of work according to the complexity.
- The team self organizes, assigning tasks depending on seniority and velocity, and planning to achieve viable software delivery at the end of the Sprint.
- Using the Agile iterative approach, at the end of each Sprint validate the team member’s delivery time rates to calibrate the plan for the next Sprint.
- At the end of the Sprint, all of the story points are measured and velocity calculated. The goal is to balance the workload for the team so all Sprint goals can be achieved.
Recap On Story Points
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.
The Fibonacci Sequence Helps With Sizing
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.
The Importance Of Poker In Your Sprint Planning
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.
Rules Of Poker Planning
The rules of Poker Planning are simple:
- A common understanding of what the values of the Fibonacci sequence mean. What does a value of 1, 2, 3, 5, 8, 13 etc mean? This is the basic step before starting the use of story points.
- The team takes one user story, and reviews its requirements. Then the team will take some time to think individually about the implications this user story has.
- All the team members simultaneously show the number or size that they have selected.
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 Distributed Planning Poker
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.
Step 3: Day-to-Day Management Of Distributed Agile Teams
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:
- A similar timezone helps tremendously. For distributed Agile, ideally make sure your offices are located in a time zone that maximizes team collaboration and efficiency for optimal delivery.
- Ensure everyone has immediate access to communication tools. Building on the time zone advantage, actively use communication tools for audio and instant messaging. There are numerous VOIP solutions available, minimizing the need for significant investments.
- Video conferencing and screen sharing will help efficiency. Make sure to have frequent face-to-face interactions by tapping into videoconferencing tools like Skype, Webex, Google Hangouts, Team Viewer, and Join.me. Also, screen sharing is a great way to help connect people, so make sure team members can simply and easily share their screens with each other at the touch of a button.
- Email is rarely the best option. Try to avoid relying on email as a communication tool as this typically slows down communication.
The Typical Artifacts To Sustain Distributed Agile Projects
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.
Product Backlog
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.
Sprint Backlog
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.
Burndown Chart
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:
- On planning day, all the estimates are added in hours, which gives us a total value. This is marked on the y axis. The Sprint end date is marked on the x axis. A red line is drawn, joining these two points. This red line indicates the ideal of hours of work achieved per day, to ensure all sprint stories will be completed. At the end of each day, the developers log their hours. This is the blue line, always increasing.
- When the developers log their hours, they must recalculate the remaining hours. This is the green line. This becomes a habit, and almost without realizing, developers are doing daily planning, which is an updated estimation. This updated estimation is reflected in the yellow line, which results from adding logged hours plus remaining hours. The ideal value would be a horizontal yellow line. When the yellow line increases, it is warning us that issues are taking longer than expected, and that provides us a warning on what might be the outcome of a sprint.
- Charts can be done by person, by team, or by location. This is a very quick and realistic way to know how teams are doing with their workload.
Code Reviews
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.
Sprint Reviews
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.
Key Takeaways: In Many Cases Simple Solutions Will Ensure Distributed Agile Success
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.