Problems large teams face with Agile: Product

Photo credit: Online Cup.

In the first part of this series, we said that an organization either makes its teams and culture adapt to Agile or make Agile suitable for its existing teams and culture. In this section, we will discuss the characteristics of a product that makes it more or less suitable for Agile methodologies.

The process one uses to build products should definitely depend on the type of the product. While there are benefits from following a standard methodology, it is important to realize that when it comes to the details of product development, one size does not fit all.

As you go through this article, think of your products’ characteristics and decide whether Agile is suitable for it. If not, consider tweaking Agile to suit your product.

User stories: bite-sized features

A user story is a feature that can be delivered to the customer when completed. Before we delve into why this is a problem, let’s look into how large software products are architected for robustness, re-usability, and sustainability.

A typical large software product may be represented by the diagram below. In most complex products, a large portion of these software components are developed in-house.

When you’re just starting with some architecture in mind without developed software yet, you might need a fairly large amount of software to develop, test, and deliver each of these layers.

It may often turn out that the very first user story would need a particular lower layer software to be fully developed. In most cases, these user stories are so large that they cannot fit in a sprint and might need way too many engineers to work on them. This is one of the first mental hurdles to cross when a team tries to adopt Agile.

Most of the time, in large software products, the projects at the latter stage of the product life cycle are about some smaller improvements or feature additions. The existing stable software in these projects are thought of as off the shelf, and the user stories can be small and achievable in a single sprint.

Let’s examine a case where Agile works out pretty well:

A lot of the layers and software pieces are off the shelf. Here, it might turn out that for each new user story, the net new software to be developed is limited such that a typical Scrum team can develop, test, and deliver within a typical sprint.

Top down vs bottom up

Functionality vs technology

Product or technology

First time or repeat show

Frequency of Scrum meetings

Duration of a sprint

Regulatory compliance