Agile Explained for dummies by Renatio

separator

You might have noticed, but lots of our posts are talking about Agile. While we emphasise all sorts of aspects, we realized we actually never really explained what agile is about.

 

We’ll rectify that….

 

Many people believe agile to just be ‘the latest management fad’. Very often they scoff at the idea of becoming agile because ‘something else will come along soon and replace it’. Well today I want to raise the retort, that it won’t be, and that it’s actually been around for a very long time, you just didn’t know it.

Officially, agile software development was born in February of 2001 when 17 developers all met at each other in Snowbird, Utah and dwelled about the values they cared about when building software. Noting that most software development just doesn’t deliver on what the user needs. These thoughts resulted in a manifesto for agile software development, that materialized in 4 core values and 12 principles by which they would like to live by when building software going forward.

That’s 17 years ago and in the grand scheme of things that’s pretty new, but in the world of technology that’s ancient. In that time frame, entire technologies were born, gained mainstream usage and deprecated by new technology. So the fact that agile has stuck around this long in an industry that moves faster than any other in history, is an indicator that it isn’t going anywhere soon.

 

Yet what exactly is agile? How do you explain agile when there are more than forty different variants of agile.

And what about all those Agile practices? There are more than 70 different Agile practices. Even the Agile Manifesto, with its four values and twelve principles can be a cognitive stretch for newcomers. How on earth can you explain such a bewildering blizzard of seemingly different ideas?

40 agile methods

by Lynne Cazaly (Australian designer)

Why agile?
Agile enables organizations to cope with continuous change. It permits them to flourish in a world that is increasingly volatile, uncertain, complex and ambiguous. The rise of agile is driven both by the passion of those who love working this way and by organizations that are making a life-changing discovery: the only way to cope sustainably with today’s marketplace is to embrace agile. Firms must become as nimble as the rapidly shifting context in which they find themselves. As managing software becomes central to the success of most businesses, agile is becoming a key to the management of everything.
Agile is about working smarter, rather than harder. It’s not about doing more work in less time: it’s about generating more value with less work.

Agile responds to the central challenge of business today: “how to provide instant, frictionless, intimate value at scale”.

While such performance, when it occurs, is enabled by technology, it’s driven by agile management. When top-down bureaucracies use digital technology, machine learning, platforms, blockchain technology or the Internet of Things, they typically get meager results. Delivering frictionless customer experience lies beyond the performance capability of an internally-focused bureaucracy. Internally-driven innovation with new technology often generates changes that customers don’t want or aren’t willing to pay for. Delivering frictionless customer experience requires both continuous collaboration across internal silos and interaction with customers–something that bureaucracies are not good at. Nor can bureaucracies, with their steep chains of command move fast enough to take advantage of opportunities in the marketplace as they emerge. In a competitive setting, it’s not technology itself that makes the difference, since the same technology is available to all firms. The key is how adroitly the firm uses the technology. The driver of sustained digital success is agile or agility.

 

What Does It Mean To Be Agile?
What does it mean for an organization to embrace agile? You probably wouldn’t think of a large organization—unwieldy, clunky, slow, out to make money from you, and fundamentally unfriendly. You generally don’t think of organizations as agile because generally they’re not. We’re accustomed to dealing with organizations that are frustratingly set in their ways and preoccupied with their own internal processes.
Their motto could be: “You take what we make and that’s the way it is.” The possibility that organizations could become agile and nimble is thus not obvious.
The truth is that when we look closely, we can see that organizations that have embraced agile have three core characteristics. 1st principle: Keep teams small and lean
The first universal characteristic of agile organizations is the principle of small teams. Agile practitioners share a mindset that work should in principle be done in small autonomous cross-functional teams working in short cycles on relatively small tasks and getting continuous feedback from the ultimate customer or end user.
For the first decade of the agile movement, much of the effort was spent on figuring out how to generate these high-performance teams on a systematic basis. Teams of course were not a new idea. Most of us know the magic. We have all at one time or another been involved in a small team where communications flow effortlessly and the group seems to think and act as one. When we are members of such a team, we can analyze a situation, decide, and act as though it is a single, uninterrupted motion. There is no one in charge telling us what to do. We trust the other members of the team. That trust is rewarded by performance. It’s almost as if the group has a mind of its own. Face-to-face conversation sorts out any differences in point of view. Work becomes fun.

Work in most 20th century organizations was very different. Big systems implemented big plans delivering large quantities of a standard product. Work was broken down into small meaningless pieces. Individuals reported to bosses who ensured consistent and accurate performance in accordance with the specifications. The boss’s boss did the same, and so on, up the line. Plans and budgets were generated and allocated, division by division. The connection between any particular piece of work and its impact on a customer was often hidden by immense internally-focused systems. The result? Only one in five workers is fully engaged in his or her work, and even fewer are truly passionate—a disaster for firms that increasingly depend on a motivated workforce.

Most organizations stay stubbornly bureaucratic. One reason was the management belief that the teams couldn’t deliver disciplined efficient performance at scale: they were useful for solving complex one-off problems, but for the run-of-the-mill work in a big organization, the conventional wisdom was that bureaucracy was better.
Another reason was that most teams in 20th century organizations were teams in name only. Most of them weren’t real teams at all. The team leader acted like any other boss in a bureaucracy. team organisations

Real self-organizing teams that achieved genuine high performance were and still are a rarity. The literature on teams often talked about high-performance teams—teams that were not just ten or twenty percent better, but two, three, or even ten times better.

The right people had to have come together. The personal chemistry had to be right. The context had to be conducive. You couldn’t plan it or make it happen. You could encourage it. But ultimately it was a happy accident.
It was in fact agile that figured out how to generate high-performance teams on a consistent basis. It is a breakthrough achievement, well accepted in the world of software development, even though it is still not widely understood or recognized in general management. 2nd Principle: customer at the center of everything
The second characteristic of agile organizations is the principle of customer-centricity.
Agile practitioners are obsessed with delivering value to customers.
The primary importance of the customer is recognized in the first principle of the agile manifesto for software development. But frankly, in the first decade of the agile movement, customer focus received secondary consideration among software developers: most of the attention was on getting the characteristics of the high-performance team right. In this period, teams often had very little contact with the actual customer. Instead the customer was represented by proxy representative who was called a “product owner,” and who mysteriously knew what customers wanted. Once agile had solved the problem of how to generate high-performance teams on a consistent basis, then attention turned to the shift in power in the marketplace from seller to buyer. Who were these product owners and how did they know what the customer wanted?
The question became urgent, because under the Law of the Customer, abruptly, suddenly, inexplicably, frighteningly, to the great surprise of 20th century organizations, the customer had become the boss. Globalization, deregulation, and new technology, particularly the Internet, provided the customer with choices, reliable information about those choices and the ability to connect with other customers. Suddenly the customer was in charge and expected value that is instant, frictionless and intimate.
As a result, firms had to think about the customer in a new way. 20th century firms had gotten used to the notion that they could exploit and manipulate customers. If a customer didn’t like something they were offering, the firm would say, “We hear what you’re saying, but that’s what we’re offering. We’ll consider introducing changes in our next model, mostly some years away.”
In today’s more competitive marketplace, in which customers expect instant, frictionless, intimate responsiveness at scale, this approach is steadily less effective. Our customers are used to instant gratification and are not willing to wait for longer periods of time.
Putting the customer in the center is the most obvious and at the same time the most difficult aspect of agile transformations.
One reason why it’s difficult is that 20th century managers had learned to parrot phrases like “the customer is number one,” while continuing to run the organization as an internally-focused top-down bureaucracy focused on delivering value to shareholders. It’s not that these bureaucratic organizations ignore the customer. They do what they can for the customer—but only within the limits and constraints of their own internal systems and processes. Firms may say they are customer-focused but if the information they need to answer simple questions from customers is hidden in multiple systems that don’t talk to each other, or if customer services must be cut in order to meet a quarterly profit target, then it’s too bad for the customer. The customer gets the short end of the stick.
In a top-down bureaucracy, “the customer is number one” is just a slogan: internal systems, processes and goals take precedence.
In an agile organization, “customer focus” means something very different. In truly agile organizations, everyone is passionately obsessed with delivering more value to customers. Everyone in the organization has a clear line of sight to the ultimate customer and can see how their work is adding value to that customer—or not. If their work isn’t adding value to any customer or user, then an immediate question arises as to why the work is being done at all. The firm adjusts everything—goals, values, principles, processes, systems, practices, data structures, incentives —
to generate continuous new value for customers and ruthlessly eliminate anything that doesn’t contribute. (Cfr. Our next publication “What is business value?”) 3rd Principle of collaboration
Agile practitioners view the organization as a fluid and transparent network of players that are collaborating towards a common goal of delighting customers.
In the early years of the agile movement, it was generally assumed that if you could get high-performance teams going, then the organization would be “agile.” It turned out not to be the case. It isn’t enough to have agile teams totally focused on delivering more value to the customer, if the rest of the organization is being run as a top-down bureaucracy focused on cutting costs or increasing the current stock price. The top-down dynamic undermines, and if continued, eventually kills the agile teams.
Moreover when agile teams are housed within a bureaucracy, collaboration between teams can be just as much a problem as it is between silos in a pure bureaucracy. The problem is widespread, even in organizations that are actively embracing Agile at the team level. In surveys that were conducted at Scrum Alliance, they found that some 80-90% of agile teams perceived tension between the way the agile team is run and the way the whole organization is run. In half of those cases, the tension was rated as “serious.” How to make the whole organization agile? It’s a tough nut to crack, because agile practices represents a radically different concept of an organization. At the heart of 20th century management thinking is the notion of a corporation as an efficient steady-state machine aimed at increasing the efficiency of the exploitation of its existing business model. “Traditional, MBA-style thinking,” as Google executives, Eric Schmidt and Jonathan Rosenberg, write in their book.
Quote “How Google Works”:
“dictates that you build up a sustainable competitive advantage over rivals and then close the fortress and defend it with boiling oil and flaming arrows.” The fortress is run from the top, with an assumption that the top knows best. The fortress is “built to minimize risk and keep people in their boxes and silos,” as business school professor John Kotter writes. People “are working with a system that is designed to get today’s job done—a system that asks most people, usually benignly, to be quiet, take orders, and do their jobs in a repetitive way.” Exploitation of the existing business model takes precedence over the exploration of new possibilities.
Over many decades, multiple fixes were explored to alleviate the static nature of the organization. But these were still fixes to the same concept of the corporation as a static machine with a vertical reporting dynamic. Big bosses continued to appoint little bosses, and so on down the line. The organization continued to operate like a giant warship—big and efficient but slow and hard to maneuver.
By contrast, when the whole organization truly embraces agility, the organization is less like a giant warship, and more like a flotilla of tiny speedboats. Instead of a steady state machine, the organization is an organic living network of high-performance teams.
In these organizations, managers recognize that competence resides throughout the organization and that innovation can come from anywhere. The whole organization, including the top, is obsessed with delivering more value to customers. Agile teams take initiative on their own, and interact with other agile teams to solve common problems.
In effect, the whole organization shares a common mindset in which organization is viewed and operated as a network of high-performance teams. Surprise: Agile Organizations Are Hierarchical!
One common misunderstanding is that agile organizations are necessarily flat or non-hierarchical. In agile organizations, the top management still has the important function of setting direction for the organization. People still get fired if they don’t get their job done. If anything, the drive for higher performance in an agile organization is even more relentless than in a bureaucracy. In the nooks and crannies of bureaucracy, poor performers can easily hide. In an agile organization, radical transparency enables peer-to-peer accountability.
The hierarchy in an agile organization is very different from the hierarchy of a bureaucracy. It’s a hierarchy of competence, not a hierarchy of authority. The performance question is not whether you have pleased your boss: the question is whether you have added value to your customer. The organization operates with an interactive communication dynamic, both horizontally and vertically. Anyone can talk to anyone. Ideas can come from anywhere, including customers. As a network, the organization becomes a growing, learning, adapting living organism that is in constant flux to exploit new opportunities and add new value for customers. When done right, continuous delivery of more value to customers from less work results in generous returns to the organization that provides it.
Agile thus explodes the distinction between exploitation and exploration. All parts of the organization are continuously exploring how to add more value to customers. In the early years of agile adoption, critics said that small teams would never be able to handle big complex problems. It turns out that once the teams are housed in a network driven by horizontal conversations focused on a common goal, and operating in a common cadence, then networks of small teams can handle large complex problems with the same agility as small teams—and much better than a bureaucracy. A Different Management Mindset
The above-mentioned 3 key principles is what enabled companies like Spotify to provide personalized music playlists to over a hundred million users every week, and Barclays to start becoming an agile bank that can provide easy, quick, convenient, personalized banking at scale.
For the traditional manager encountering agile practices for the first time, counter-intuitive ideas abound. Managers find they can’t tell people what to do. Companies make more money by not focusing on making money. Dealing with big issues requires building on tiny teams. Control is enhanced by letting go of control. Leaders are less like heroic conquering warriors and more like curators or gardeners.
That’s why agility cannot be implemented within the assumptions of mainstream management practices. Agile means embracing fundamentally different assumptions. For traditional managers, the process usually isn’t comfortable. It isn’t easy. At the outset, it feels just wrong. It’s like learning a strange foreign language. It is only over time and through actual experience and practice that agile becomes second nature and automatic. This is not about “doing agile.” It’s about “being agile.” The agile principles
Agile thus operates under 3 main principles —small teams; customer-centricity and collaborative mindset. Together they generate the basics of an agile organization. Practices may change, but the Agile mindset applying the three laws of Agile endures.
They offer a lasting guide to what’s involved in an organization becoming Agile. agile in short The 1st principle, meaning the notion that work in principle should be done in small teams working in short cycles—is the best known in the Agile world because that’s what received most of the attention of the early adopters of agile software developers.
The 2nd principle the idea is that the very purpose of a firm is to deliver value to the customer— is the most important, because it is the principle that makes sense of the other two principles and that permits the greatest insight into why an agile organization operates the way it does.
Yet the lynch-pin of agile is really the third principle: the impact of high-performance teams and the customer focus will be sub-optimal unless the whole organization operates as an interactive network. It is when the three elements combine together and focus on a common external goal that we get the explosive increment in value that comes from truly embracing agile. If I can summarise this into something succinct it would be this; Agile isn’t anything new, it’s just a re-emergence of something we already knew and it boils down to these 3 things:
• Focus on the real constraints and design the work to meet that schedule
• Give the team autonomy to innovate
• Deliver incrementally to validate and adjust as needed

So the next time someone tells you that “Agile is just a fad” and “will be replaced by something new soon”, tell them to have a read of this and hopefully we can help the re-emergence of common sense one person at a time.

we are renatio

Previous publications

Upcoming publication: [08.09.2020]
“What is business value?”