Delve into Agile methodologies, compare them with Waterfall, explore planning techniques, and discover tools like SCRUM and Kanban. Gain insights into solving common problems with Agile.

This course is designed to help learners build an understanding of Agile’s process model and its different approaches and techniques.

To understand the advantages of implementing Agile techniques, the course begins with a comparison of Agile methods and the traditional Waterfall model. Then, you’ll get to know about different planning approaches to help users effectively adjust deadlines. Next, there’s a discussion on backlogs and different visual techniques, such as burn-down charts and burn-up charts, that help increase the efficiency of projects.

You will also learn Agile methodologies including SCRUM, eXtreme Programming, DSDM, Smart and Kanban, as well as the differences and similarities between these approaches. Finally, you’ll look at some common problems and learn ways to solve them using Agile methodologies.

Learn Agile Methodologies from Scratch

# Co-location vs. distributed teams

Co-location with the customer is the best choice for an Agile project. However, there are situations where this is impossible. Various organizations prefer to use offshore construction. The developers and testers can be located anywhere in the world.

There are different arguments for using offshore development. One argument is that there are insufficient local people with the necessary skills. It’s then plausible to search for those developers elsewhere.

In addition, there’s the assumption that offshore development is cheaper. Based purely on the hourly rates, this seems realistic. That said, the inevitable overhead and complex communication take away part of this advantage in offshore scenarios. Added to the fact that the domain of many projects is complex and full of local laws and regulations, this complicates offshore outsourcing enormously.


In the past, Waterfall was chosen unanimously for offshore projects. This seems easier. Analysis and design are done locally, and once they’re ready, the rest of the project is outsourced to an offshore location. Nonetheless, it’s striking that, in offshore Waterfall projects, the same problems arise as in local Waterfall projects.

The project’s delivery date is delayed, it goes over budget, and the delivered software meets the requirements defined prior to the project, but not the requirements that may be needed at the end of the project. It’s difficult to take a progressive insight into account. In addition, the project’s domain is often difficult to comprehend for offshore developers and testers. Finally, the customer usually chooses the technology.


The offshore developers aren’t always familiar with the chosen technology. This results in bad code, even though the capabilities of the offshore developers really are at par with local developers. The important question is: do offshore projects benefit from Agile? There’s an interesting comparison to be made between onshore and offshore by comparing the price per point.

# Recommendations to run distributed teams

In our view, if an organization chooses to perform a project in a distributed setup, it should do it using Agile. Of course, an Agile offshore project will pose additional challenges. Face-to-face communication becomes more complex, as does the use of dashboards. Organizing technology is also more difficult. This leads to the following recommendations:

## Become acquainted

It’s important that the team feels like a team. This is best achieved by everyone getting acquainted, face-to-face. For example, we can invite the offshore team to participate in the kickoff of the project at the location of the customer. Have the customer explain the purpose and context of the project. This will increase understanding.

Let the whole team participate in any necessary Agile training. Organize something social, like a dinner party or corporate event. This involves additional costs, but it strengthens the sense of community among the team tremendously and removes obstacles to future communication.


## Feature teams

If the project consists of multiple teams, it’s wise to divide the work based on features or work items. People onshore and offshore work together towards the same work item, called **feature teams**. Feature teams encourage collaboration and a heightened sense of responsibility to realize the work items together.


## Kick-off and evaluation

  Organize the kickoff and evaluation of iterations so that both the onshore and offshore people can participate. A quick video link is the simplest solution, with a set-up of screen and camera on both sides. Remember to take the different time zones in which the teams are located into account. Good facilitation by an Agile coach of the kickoff and evaluation is advisable. Video connections have some delay, which makes it necessary to take turns talking. We also recommend periodically rescheduling the starting time of kickoff and evaluation meetings. That way, everyone occasionally feels the pain of scheduling meetings at awkward moments. Nobody wants to feel like their schedules are never considered.

## Daily stand-up

  The daily stand-up is also best held by video connection to ensure that there’s still a form of face-to-face communication. Daily stand-ups through the telephone are much less effective. The quality of the line and the various English dialects make communication through phone suboptimal.

## Daily communication

  It’s important that everyone on either side of the ocean can ask questions at the time a reply is necessary. Regardless of time differences, it’s therefore important that communication is always possible. Many projects use messaging, such as Microsoft Live Messenger. We’ve even experienced Live Messenger being used for distributed forms of side-by-side programming.

## Online dashboards

  Although the sticky notes on the wall are the most practical dashboard, this doesn’t work as well for distributed teams. On one of our distributed projects, we posted a picture of the dashboard on the internet twice a day. Many distributed teams work with an online dashboard, as do many co-located teams. There are several tools on the market, some free and some paid, like Mingle or Capgemini’s Agile Dashboard. Teams also use shared tools to register bugs, for example, in Jira or directly into Team Foundation Server (TFS). Nowadays, such tools also offer digital dashboards.

## Standardize

  Especially with different cultures participating in the project, it’s very difficult to continue to work together in the same way. We recommend standardizing many aspects of the distributed Agile method without jeopardizing the project’s flexibility. For example, the unit of work should be the same whenever possible. This prevents misinterpretations.

In various distributed Agile projects, we use smart use cases. They’re always produced in the same way. In addition, there are over 30 standard types of smart use cases, which furthers standardization. Teams can then determine manages or what might be better implemented as a list detail than a master detail, for example.talk about “this is a manage” or “this is better implemented as a list detail than a master detail.”.

## Unit testing and continuous integration

  When code is spread over various locations, monitoring the quality is crucial. We recommend that all distributed projects develop unit tests and make continuous integration compulsory. This way, when code changes, it becomes immediately clear if it will cause errors.

Get an overview of the perks of co-location over distributed teams.

Getting Started

Why does the Waterfall Process model not work?

What is Agile?

Short Iterations in Agile

Collaboration in Teams

Collaborating Roles

Agile Requirements

Estimating

Planning

Implementing Agile

Issues in Using Agile

Choosing the Most Appropriate Process Model

Conclusion

Distributed Teams

Co-location vs. distributed teams