Frequent deliveries

In traditional projects, the work consists of conducting tasks defined by a long plan, which is usually fulfilled almost in its entirety before the product is delivered to its users to be used. Under these scenarios there is no concern about converging early on towards something deliverable, since there is the mistaken belief that “everything” should be created so we can deliver “something.” Thus, only one or a few deliveries are scheduled.

In software development, for example, it is common to order tasks so as to develop a product module after module, layer after layer, step after step, based on the product’s usage flow or, more often, using some combination of these possibilities. Something similar occurs with other types of products and services: the work is oriented towards complete fulfillment of the planned tasks.

This way of working takes us to the maximum risk of all or nothing for each planned delivery. In other words, either we arrive at the established date with everything done, or we will have nothing to deliver. Unfortunately, the worst-case scenario is the most likely to occur. It is not possible, for example, to deliver software without testing, or without the user interface layer, or without an essential step in its usage flow, such as the payment for a purchase made. As a result, we often generate delays in deliveries.

Moreover, the use of functional teams, a scenario in which each team performs a distinct and well-defined function, reinforces the problem in deliveries. These teams together are not usually able to frequently converge on something of value to their users. In such cases, the work to be conducted passes through a sequence of functional teams, each performing its part in developing the product, until it can be delivered. Whenever there is this transfer of responsibility for a work item (i.e., a passing of the baton), that item enters the work-to-be-done queue of the functional team that receives it. There is, consequently, a waiting time, as each team will be working based on their priorities when the item arrives. The same occurs when the last functional team passes the work item to the next team, and so on.

These delays significantly increase the time required to implement something that can be delivered to users and therefore reduce the delivery opportunities. They can also make the possibility of delivery even more unpredictable than it already is, increasing the risks of not making them on the scheduled dates. The problem becomes even worse when backflows occur – that is, when work items are returned to one of the previous functional teams, usually because of defects found (for example, by a quality control or audit team).

When working with Scrum, the product is built in short cycles and incrementally, beginning from what we believe to be its most important parts. In each cycle, the focus is not on simply fulfilling planned tasks, but on converging the work towards something deliverable. From cycle to cycle, the team produces something that is done, that works and that potentially represents value for the customers and users. Each increment produced in each cycle represents a safe step of done work, offering an opportunity to deliver. As a result, the product can even be introduced into the market in a very short time.

The teams that develop products with Scrum are cross-functional or multidisciplinary, which means that its members have all the knowledge and skills necessary to develop the product from end to end. These teams produce done and working parts of the product in short cycles of development. In this way, Scrum avoids the scenario where a team would have to wait for the work of other teams to be able to begin working on something. In software development, for instance, it is not uncommon for items to have to go through requirements validation, design, and security work before reaching the product development team. Here Scrum also prevents the work performed by this team from having to pass through other teams before reaching the users’ hands. That is, the work could still have to pass through, for example, the tests of a quality team, which in turn would return to the team a list of problems to be corrected and, only after passing new tests, would the product reach an operations team that, within its priorities, could finally put it in the hands of users.

The use of cross-functional teams therefore eliminates or at least minimizes external dependencies. In other words, we seek to eliminate unnecessary delays in product development, whether it is waiting for inputs or at the other end, for validation, thereby maximizing work efficiency. We therefore increase the chance of having parts of the product done in each cycle of its development. Continuing with the same idea, even if there is more than one team working on the development of the same product, each team will be cross-functional.

If a team identifies a necessary skill in which it is lacking, it will look for ways to incorporate enough learning to be able to develop the product. Furthermore, by working together and sharing responsibility for the product being developed, the team members learn from each other, thereby gradually disseminating knowledge among them. This shared knowledge helps minimize internal dependencies, further reducing possible queues and delays and increasing team efficiency.

In addition to often converging on something done, the work with Scrum is done according to an order and the scopes are flexible. Since the team is always working on the next most important parts of the product, and in short cycles, there is rarely the need to delay a delivery. By the time the pre-established date arrives, the chances are that the team will have produced enough value to meet the delivery’s business objectives. In other words, the problem is already sufficiently well resolved. If necessary, we will leave undone only the less important parts of what was imagined, and which are thus not essential to the delivery goals. Likewise, if a deadline has been defined for all product development work, it is natural to expect that when we arrive at it, the vision initially defined will have been sufficiently well accomplished, since we have done the work based on the most important parts of the most important problems.