Exploring Agile, Part I

Photo by Pierre Châtel-Innocenti on Unsplash

Explaining the meaning of Agile or “” is no easy task. The saying “” definitely applies to this topic. In an attempt to demystify its different meanings, this article will be exploring Agile from three different perspectives, concluding with a fourth, holistic perspective. This is the first of two articles, the second part will explore and the typical characteristics of Agile organizations.

A brief History of Agile

Agile has its roots in software development. A landscape historically dominated bythe Taylorist conviction of separating from (separating the people that from the decisions on ).

A predictive approach like waterfall works towards a predicted and predefined output or product, leaving little room to address changing requirements and expectations

This was exemplified by the widely adopted use of the A linear and sequential method, promoting upfront planning with a focus on predictability and control. The adoption of this industrial paradigm in software development eventually revealed its flaws, in some cases contributing to projects running massively over budget.

In a search fora meeting was organised between a group of leading software development professionals that shared a sympathy for the more software development methods they were using at the time. Collectively they outlined a set of that captured the shared characteristics of these lightweight approaches and the mindset of their practitioners. This meeting resulted in the well-known (2001)

As , one of the original Manifesto signatories recalls:

Over time, the word started to be used as a . Agile methods were packaged and sold as a management revolution with big “A” as a brand name describes the birth of an “Agile Industry” in his article :

As the article goes on, it describes how the original intentions and spirit of the Agile Manifesto turned out to be difficult to understand for executives that were looking for ready-to-implement solutions promised by the business of the Agile Industry.

This transition from to could be described as Pournelle’s Law in action (). In his blog post(2006), one of the original Manifesto signatories expresses his concerns:

Despite all misconceptions and oversimplifications of agile (which persist to this day), the manifesto has managed to remain impressively relevant due to the timeless concepts it promotes. Not necessarily intended as such by its creators, the Agile Manifesto has grown into a landmark in the history of Software Development and the Agile community in general. In response to the , we see more and more initiatives (like agnostic agile) emerging that aim to point back to the original intentions and spirit of the Manifesto’s creators instead of zooming in on specific technical implementations or frameworks.

Even though Agile originated in software development, some of its beliefs have been exported outside of it. Most notably, the that combines Agile and Lean to rapidly discover the viability of a proposed business model (test-driven development at company level). Successes demonstrated in the startup community have inspired an increasing number of larger companies to embark on their own

The IT Perspective

The IT perspective on Agile is strongly influenced by the Ironically, while some of the contributors of the manifesto shared a motive to heal the divide between technology and the business, it partly resulted in the adverse effect of people outside of the software development community starting to perceive agile as “an ”.

Adaptive approaches to Software Development have largely become the norm (even though waterfall approaches still persist). with being the most widely used Agile Software Development Framework (next to and ).

The adaptive approach to software development is based on multiple iterations, incrementally building an emerging product, aligning with a client’s expectations along the way

Adaptive approaches acknowledge that Software Development lives in the empirical world and complex domain (you can only know how long something took after it has been completed). Agile software projects have a fixed schedule and resources while the scope varies and its delivery is as opposed to . Success is defined by value delivery, and course correction is based on empirical evidence gained from user testing.

source: atlassian.com

Another notable difference is that adaptive approaches like Scrum, don’t have a classic role, instead, these responsibilities are distributed across the , making for a self-organised development team that is focussed on delivering maximum business value, supported by a . A “manages” the Scrum process (as opposed to managing people), and coaches the team into self-organization.

Many things have greatly evolved since the creation of the Agile Manifesto, like the vast optimisation of and The manifesto already mentioned in one of its principles:

Continuous Integration and Continuous Deployment (CI/CD) has evolved to a level where continuously integrating and deploying software has now become effortless (or jokingly described as ).

The “” has somewhat distorted the , narrowing Agile Software Development down to “. This led to a popularisation of “” Agile approaches, imposing them on teams and enforcing structure in order to increase efficiency without understanding the underlying values. These dogmatic, approaches to Agile practices have left many developers (and companies) with a bad taste for Agile.

However, (focussing on early user value creation through iterative delivery and continuous improvement through learning)generally leads to better results and happier teams. Successful, motivated and self-organised teams that operate in healthy Agile environments, are increasingly multi-disciplined and focused on instead of These teams want to go beyond just delivering working software for their clients, moving from a to a . This evolution is reflected in initiatives like , making the idea behind the Agile Manifesto more universally applicable with a focus beyond software practitioners.

How the Agile Manifesto Values compare to the Modern Agile Principles

The Design Perspective

Agile from a design perspective is often mixed with scepticism since most of the Agile practices emerged from within the development community. A great example is the Scrum Framework prescribing that a should be cross-functional (should have all the skills necessary to create a product Increment) but doesn’t recognise titles for Development Team members. Effectively this would mean that designers should join a Scrum Team, but would be called…

To some degree, this is understandable since most of today’s digital design disciplines simply didn’t exist at the time that Scrum, and later, the Manifesto were created. From a designer’s perspective, Agile Frameworks that have their roots in Software Development can be experienced as restrictive due to its incrementalism and focus on output and delivery, leaving relatively little room for ideation and creative processes, let alone a holistic design approach. Creativity simply doesn’t scale that well.

In traditional and linear approaches (waterfall) designers were positioned upstream from the development process, creating , handing them over to a development team in order to turn these designs into a working product (often resulting in a )

In an adaptive and iterative approach, design-skills are required at all levels of the process, offering (or at least encouraging) the right design activities at the right moment and at the right speed (considering both short-term and long-term goals). Arguably the biggest “agile challenge” from a design perspective is that of breaking free from a silo’d approach, making good design everyone’s responsibility by explaining its business value and help agile software development practices move to a more design-driven approach.

Not many designers would necessarily refer to their practices as Because of the strong connotation with the design perspective on Agile is commonly reduced to a . In reality, Agile (in the broader sense) is much more than that and the most used framework, Scrum, is actually the opposite of a methodology. When exploring fundamental beliefs behind Agile like , , (, one can‘t help noticing a large overlap with the values associated with Design Thinking (and to be fair, it’s easy to see how a designer would more likely gravitate towards a name like that).

The Business Perspective

Agile from a Business perspective is probably closest to the literal meaning of the word. Organizations are increasingly striving for an ability to adapt to a changing (business) environment.

Large traditional corporations are starting to acknowledge that last centuries management approaches and rigid organizational structures are no longer serving them well in an increasingly service-based economy. They are increasingly experiencing serious competition from “small players” in their market with the agility to outpace them in terms of innovation and time-to-market. In a faster moving and more demanding world, organizations need to be increasingly customer-oriented, moving from silo-based to team-based organizational structures.

However, true agile transformations are hard and typically underestimated and misunderstood. is often falsely perceived as something that can be , or by an as if it was another management methodology. This has resulted in a lot of “” going around. Many agile transformations are exclusively focussing on (the most commonly mentioned reason for adopting Agile). The adopted practices to achieve this goal are often only and rarely render the expected results.

In his article “” Agile Consultant describes one of the most common reasons for agile transitions to fail; the lack of executive sponsorship:

This could be compared to paying a personal trainer, but not understanding you are expected to break a sweat. When traditional corporate hierarchy and politics remain unchanged, no real transition will ever take place. For managers that have longtime operated in a traditional (vertical) management culture of top-down decision making, the concept of Agile can be hard to grasp. In his article “e accurately describes these two different worlds:

The reality is, that creating an environment and culture required for high performance might require a drastic reduction, or even an absence of traditional management culture and the adoption of supportive leadership with the courage and trust to empower teams by decentralising decision making and distributing authority. Leaving the vertical dynamic of top-down behind and embracing a network of small autonomous teams.

A truly successful transformation might simply start with some form of organizational self-reflection, identifying organizational patterns or behaviours that could be considered and laying out a plan to discontinue, un-learn and transform these, moving from to .

The Holistic Perspective

The , and on Agile provide some insight into the different meanings of Agile. Because some of these perspectives commonly originate from certain disciplines or theories, they often have a strong focus on specific tools or processes.

Agile practitioners that view agile from a apply a wider focus on Agile, considering an (enterprise-wide) shift in mindset as the ultimate goal (an almost of Agility). This mindset is based on the belief that is , not . Any practices, tools or processes are a natural expression of that mindset, not a goal by itself.

In the second part of this article, we’ll be exploring the what defines organizations that have this mindset and whether or not this mindset can be adopted.

Scrum Master, Management 3.0 practitioner, Agile enthusiast