Agile like Water

Agile like a river pouring water from the source to the sea.

Decades after the publication of the Agile Manifesto (2001), there is still much confusion about what agile development means.

Certainly, through a naive association of words, someone might think that agile development of software means fast development of software. Although this is not untrue, this association is insufficient because it does not explicitly state the main goal of delivering value constantly, in other words, delivering the correct product to the correct public as continously as possible.

More experienced technologists might suggest that agile development means applying XP or Scrum, using Jira or Trello, or ritualizing standups, plannings and retrospectives. Once again, this is only partially correct, since these practices are useless if the theory that underpins the agile mindset is not shared by the team or the organization.

Before diving into this theory, let's understand how we got here.

📉 Cascade (like a Waterfall)

Back in the early days of the technology industry, no one knew exactly how to build software.

Lacking particular processes and conventions, the Software Engineering field inherited standards and ways of working from other engineering fields and, as a result, established a rigid and linear process to plan and execute software projects, later known as Waterfall.

For decades, software products were built in the same way as cars or buildings: projects marked by distinct, timed, and chained phases that began with requirements gathering and architectural design, moved to code development and ended with quality assurance.

When all the steps occurred as expected, the product could reach the public on time and without defects. However, when something unexpected happened along the way - whether due to poorly gathered requirements or a change in market needs or, worse, a critical bug found in the already released product - building and shipping corrections was not trivial at all.

Since the process was set in stone - with distinct phases taking place sequentially (at different times) and separately (by different people with different roles) - there was no space or time for assuring quality along the way, gathering feedback, collaboration between roles, or experimenting on iterative ideas - it was all or nothing.

In the early 2000s, in an attempt to transform this archaic process into something more fluid, a group of technologists got together to write the Agile Manifesto (2001), a set of values and principles ​​that paved the way to a new era in software development and continues to evolve to this day.

🌊 Agile (like a River)

We can imagine agile software development like a river pouring from the source and daily discovering the best path to flow into the sea.

💧 Source (inception)

The beginning of an agile project can be compared to discovering the source of the river, where a collective of people interested in the product come together to discuss what this product does (and what it doesn't) and define a minimal viable path so that the first drops of water of river can start flowing into the sea.

In more practical terms, this means involving team members in activities such as inceptions (to align product goals) and team normings (to reach agreements on development workflows), performing user researches, designing interface prototypes, sketching an initial architecture for the system and developing iterative proofs of concept (POCs) that can potentially be delivered to the end user and start validating the feasibility of these ideas.

During daily standups, team members share their status and the team builds a shared vision of where we are now and where we are going, what are the immediate blockers and what are the needed adaptations.

Regular activities like retrospectives and showcases (with different crowds) should be performed to gather feedback about the team and the product. Along the way, discovered action items, bugs and improvements should be constantly added to a backlog regularly prioritized and refined during plannings.

Working in sync to build a path to take first drops of water to the sea, every team member understands why (and how) they are doing what they are doing (and not doing), and thus, are the best sources to constantly identify better ways of doing things.

🛶 Current (development)

Like in real life, a river rarely is able to flow in a straight line from the source to the sea: a change in weather conditions or some unexpected geographical challenges can pose a threat to the current flow of the river and require an adptable response from the team.

When a rock or a tree trunk appears in its course, the river responds in a naturally agile way, spreading itself between all the possible gaps in the scenery in order to find a path through which it can keep on flowing.

The river's agility is perceived more in the response time than in the speed at which it overcomes its obstacle. It is natural that greater challenges or new problems take longer to be overcome. But more important than getting to the other side quickly is getting there effectively, establishing a safe path so that more water can flow in the future.

For this to happen within a team, the team needs to be provided with material resources (computers, chairs, tables, snacks and post-its) and immaterial resources (data, access, security, training and autonomy). In interpersonal relationships, the team must act with empathy and generosity, encouraging the growth of colleagues, encouraging what is working well and accepting mistakes along the way as learning opportunities.

From source to sea, the flow of a river is rarely uniform. Different stretches of its path can have different characteristics. Although they do not always represent serious problems, teams and organizations need to be alert and act to avoid:

• murky water: poor visibility or lack of access to project information reduces the capacity for innovation and continuous improvement;
• rough water: recurring tensions when prioritizing tasks or deploying to production are symptoms of deeper misalignments;
• scarce water: a team always working at its limit loses the power needed to reorganize itself when new challenges arise;
• waterfall: lack of synergy between different roles and the formation of knowledge silos were small cascades in the process that directly impact the team's ability to respond to changes;
• standing water and bottlenecks: bureaucracy generated by the need to wait for specific dates or obtain hierarchical authorizations creates bottlenecks that reduce the team's flow and work output;

🌅 Sea (delivery)

From the moment the first drop of water gushes from the spring until it reaches the mouth of the river, a lot can change. An agile organization needs to know how to recognize and, whenever possible, leverage change.

Deep research with your audience may reveal that a feature is not as desired as imagined, thus allowing a product to be launched immediately. A different architectural design may mean that a microservice or screen component can be reused by multiple teams. An existing product, such as the engine created for a game that has already been released, can easily be reused to build a completely new product.

The more interconnected and flat the mouth of a river, the more possibilities for the emergence of new ways of delivering water from the source to the sea.

The life cycle of a river does not end when it flows into the ocean. By observing the waves of the sea, a river can take what it has learned at the mouth back to the source to facilitate the path of the next drops of water. In more technical terms, the more horizontal a process is, the more instantaneously feedback from its audience will be able to inform and direct the creation of the right products or the prioritization of truly expected features.

From end to end, the river must be understood as a unit. Agile chains limited by authoritarian leadership or rigid processes invariably end up building software in a cascade and run the risk of repeating the same mistakes of twenty years ago.

The digital transformation that organizations need to experience must happen beyond lines of code. Putting new iterations of agile (or Modern Agile) into practice requires courage to abandon ready-made manuals and pragmatically reevaluate work models - from recruiting new employees to monitoring production logs - to discover how to be naturally agile in each context, enhancing human relationships and ensuring that all stretches of the river are always able to deliver the best value to the sea.