Endless development cycles with Agile and how to avoid them

Overview

Some agile teams are facing an endless development cycle. This is caused mainly by two types of stakeholders and customers. Those who are sticked to traditional waterfall methods or by those that misinterpret the agile approach in a way that they try to use it as a vehicle for continuous new product development. This article presents this commonly faced problems and some health check and suggestions to help teams for teams early detect them

Problem description

While Agile provides an iterative approach for project management, promoting change, collaboration, adaptive planning, and flexibility in responses, often it is misused as a non-ending sprint loop. In principle agile methodologies like Scrum, clearly define that at every sprint, the team is building a potentially releasable increment. In this manner, the team, while in a short term, is delivering value to the customer. However, many stakeholders or customers that are sticked to the traditional project management, fail to actively participate in this iterative development approach.

Symptoms

Here are two main symptoms that are usually noticed across agile teams.

• Stakeholders waiting for something “complete” at every sprint to move on. It has to be very clear that this will never happen. Each sprint ensures that a small increment is built- and potentially released. Even if that happens, that means that either the product was too simple, or that something is really missing. Here is crucial to elicitate feedback from the stakeholders and feedback from actual releases.
• Stakeholders never stop asking for improvements and introduce new features/products There is also the trap of continuously asking for new features or even changing the specification. While this is normal as new features naturally arise in agile development, the team has to acknowledge that new features should arise if and only if they are mandatory in order to address the defined objective. Otherwise, customers/stakeholders will always raise the bar by hiding behind the “deliver value to the customer” excuse.

Proposed actions

Agile, and in particular Scrum is based on the pillars of Transparency, Inspection and Adaptation. If followed thoroughly all parties will benefit by the flexibility provided by the framework. Here are some recommendations/ health-checks for teams following the Agile development methodology

• Make sure that your increments reach the real customers
• Don’t delay releases if and only if the concern is expressed by some stackeholders, team members
• If someone is causing the team to procrastinate the release try to understand what are his/hers concerns
• Agile applies for the whole product. If one (sub) team is using different approach make sure this is not intervening to the agile process
• Don’t judge agile development cycles with a traditional project management perspective
• Discovery is part of progress.
• If the team is not delivering something useful, try to communicate that in the review
• Ask the team if the increment is providing new features o
• Check the acceptance criteria- if need to update to maximize value make sure that this is not by adding a new feature

Hope this will help you in your agile journey!