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 a lot of 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)

In the early days of the IT 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 team practices and 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.

Instead of a having a distinct dedicated phase for testing at the end, the quality of the project is rather assured every day through a variety of practices like code reviews, test driven development, monitoring, continuous integration, continuous delivery and/or continuous deploymeny.

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 and with short feedback cycles, every team member understands not only what, but also how and, more importantly, why they are doing what they are doing (and not doing), creating a fertile environment for not only reaching the sea but also collaboration, experimentation and innovation.

🛶 Current (development)

Like in real life, a river is rarely able to flow in a straight line from the source to the sea. A change in weather conditions or unexpected geographical challenges can pose a threat to the current flow of the river and will test its adaptation abilities.

When a rock or a tree trunk appears in its course, the river responds in a naturally agile way, never stopping but seamlessly spreading itself through all the possible gaps in the scenery in order to find the best path to keep the current flowing.

The agility of a river can be perceived more in how seamlessly it than in how fast it overcomes its obstacle. Harder challenges and new problems can take longer to be overcome. But more important than getting to the other side as soon as possible is getting there as effectively as possible, avoiding interruptions in the river flow and establishing a safe path so that more water can flow in the future. The river learns.

In dev terms, this means establishing effective monitoring and rollback strategies, documenting bugs as unit tests, releasing selected branches with blue/green deployments or canary releases, using feature toggles to protect experimental features and so on... When handling bigger incidents, activities like post-mortem retrospectives can help identify causes, lessons and action items.

A team needs to be provided not only with material resources (like computers, chairs, tables, snacks and post-its) but also immaterial resources (like information, training, access, security and autonomy). In a team, values like trust, empathy and curiosity help encourage mutual growth, support what is working and embrace mistakes as learning opportunities. Practices like regular 1:1 sessions and team outings can also help solidify interpersonal relationships, match talents and aspirations with existing work opportunities and also spark innovation with unexpected collaborations.

From the source to the sea, the current of a river is never uniform. Different stretches of a river will present different characteristics - a reflection of the conditions this river faced so far. Some of these conditions come from unfortunate external restrictions, but some are self-imposed and can be changed. Projects, teams, and organizations should be alert and act to avoid:

• rough water: from bug fix to big feature, the path to production should always be smooth - pressure and tensions are often symptoms of improvement opportunities.
• scarce water: an overworked team loses the flexibility needed to reorganize to face unseen challenges or engage in continuous improvement activities like refactoring;
• murky water: no access to necessary information and discussion forums reduces the feeling of ownership and the potential for innovation and contextual thinking;
• water puddle: lack of collaboration between different roles and seniority levels can make a team overly dependent on someone and reduce its ability to respond to unseen circunstances;
• bottlenecked water: bureaucracy and hierarchy can create artificial bottlenecks and reduce a team's flow and work output;

🌅 Sea (delivery)

From the moment the first drop of water rises on the source until it reaches the sea on mouth of the river, a lot of things can happen. An agile team needs to constantly be able to handle and, whenever possible, leverage change.

• fresh water: a very complex feature can mostly always be delivered in iterative slices of reliable code, properly tested and able to constantly evolve according to current requirements (instead of something we planned months ago before a single line of code was written);
• bottled water: usage metrics and data analysis might reveal that a planned feature is not as desired as imagined, allowing you to either change priorities or develop specific customization options for the correct clients;
• reusable water: from extracting web components to creating new teams to handle specific shared microservices or, even, partnering with an existing product from another company can help a company save resources or pave the way to new market opportunities.

A sustainable river is constantly delivering the best possible water from the source to the sea.

The life cycle of a river does not end when it flows into the sea. By following the waves, a river can take lessons from the mouth back to the source and improve the current of the water.

The shorter the feedback cycle, the better will be the product callibration - allowing an enginering team to create the correct products and priorize the truly expected features.

From end to end, the river must be understood as a unit. An agile team restricted by authoritarian leadership or rigid processes unable to reflect their current reality invariably end up building software in a cascade form and run the risk of repeating classic mistakes.

The digital transformation proposed by the Agile Manifesto (2001) takes place beyond the lines of code. To be agile today takes courage to abandon ready-made manuals and pragmatically reevaluate all work models - from talent recruitment to the monitoring of a deployed application - in order to discover how to be naturally agile (like a river) in every situation: responding to the ever changing business requirements with flexibility while always leveraging human potential to ensure that every stretch of the river is always able to deliver the best value to the sea.