Traditional approaches are plan-driven. It means that requirements are decided and fixed early in the development cycle. Projects focus on requirements realisation, even though it may take longer and cost more than expected. Any changes that appear later in the development cycle often lead to delays and/or budget overruns. Generally, traditional approaches have difficulties to accommodate changes.
Agile approaches are, in contrary, business value-driven. These assume from the start that requirements, which are developed at the beginning, are not fixed and will change. The agile philosophy also assumes delivery by a certain date. This approach fixes the time and resources and leaves the requirements undetermined. These requirements will be discovered and implemented during the development process.
The agile philosophy offers among other the following benefits:
More business value for less – due to prioritisation, the most valuable functionality in customer’s eyes is delivered first.
Shorter lead time – agile approaches deliver a working product iteratively. The customer can decide when a (partly) working product can be delivered.
Cancelling development efforts is a valid option – due to frequent feedback loops it will become obvious when the investment does not make sense. It will be possible to stop it in time, preventing loosing money.
Although many try to ‘simplify’ stating there are no requirements in agile approaches, it is a misconception.
However, requirements appear in a different form. It cannot be stressed enough that working agile with remote teams does not eliminate the need for managing requirements. In SCRUM development starts with defining a vision of a product-to-be. Roman Pichler  defines a Product Vision as:
The product vision is the overarching goal you are aiming for, the reason for creating the product. It provides a continued purpose in an ever-changing world, acts as the product’s true north, provides motivation when the going gets tough, and facilitates effective collaboration
The goals of the product are refined to epics/features/user stories that form a Product Backlog. It means that a Product Backlog is simply a prioritised list containing all functionality required. Customer owns it. They also prioritise and assign business value to Backlog items. The high priority items will be implemented first. The Product Backlog is a living document, that reflects the customer view on the product. During an iteration, a development team manages a Sprint Backlog, that contains dedicated work from the Product Backlog they committed to deliver during a sprint. During the feedback meetings, new insights may lead to changes in the Product Backlog. This adaptive approach focuses on developing requirements just-in-time. Refine only requirements that are needed for the iteration. All this is also true and valid while working agile with remote teams. The recent Agile Business Analysis training of EKIPA provides more comprehensive insights how requirements shall be developed and managed in an agile environment.
The success of agile approaches is related to dedicated teams, business ownership, small iterations which deliver working product and informal, face-to-face communication. The last may be an issue for remote teams. Research showed that agile remote team challenges stem mainly from different time zones, languages, and cultures .
In consequence, the amount of verbal communication may be lower in remote projects compared to onsite teams, which may result in miscommunication, misunderstandings, and confusion among team members. But don’t lose faith – these challenges can be overcome with:
“Seeding visits” to other sites at the beginning of the project as well as by “maintaining visits” in later stages; This allows to build trust between the team and the customer, or
Selecting the right communication tools for the task at hand. Supporting multiple communication types, including a variety of differing media, to comply with preferences of team members, e.g. video conferencing can be used for direct face-to-face communication because it most resembles natural communication.
As the rapport  showed, despite these barriers the number of agile remote teams increases every year. It’s just like in life: a perfect marriage does not exist. A good marriage does, and it takes some time and effort to make it work. The same is valid for agile remote teams. Knowing limitations of remote teams allows to act upon them and finding the communication model that will fit the customer and the team letting both sides benefit. Agile with remote teams seems to be not only possible but also the right approach to increase the chances of success.
 “The Role of Communication in Agile Systems Development” by Markus Hummel, MSc, Dr. Christoph Rosenkranz, Prof. Dr. Roland Holten Chair of Information Systems Engineering Institute of Business Informatics Goethe-University Frankfurt
One of the things that have surprised me in the past few years is the size of the ecosystem around startups. We see the same ecosystems evolve in all the major hubs across the globe, but we lack an ecosystem for scaling up.
In my own journey the past decade, I have learned that it’s a lot easier to start up than to scale up. I’m aware that part of the problem is my personal DNA. Some people are good at starting, and some are better at scaling. However, most founders need to hang around fo
Scrum masters are the spiders in the agile web. They coach the development team and remove their impediments. They spread scrum throughout the company. They teach customers how to work with their company using scrum. And they advice the product owner how to collaborate best with all people involved. In my