Practical Agile: Flexibility, Directedness, and Human Interests

Practical Agile Website Banner

Practical Agile: Flexibility, Directedness, and Human Interests – Reading time: 15 minutes

Introduction: “vague theory, concrete practice”? 

This blog is a follow-up to another we published not long ago, “(Even) More Rules, or Back to Basics?” (hereinafter “Getting the Most out of Agile” or just “blog 1”). In a nutshell, blog 1 argued that, given attempts to impose new rules and even “Laws” (written like that) on the Agile framework, it’s important to get back to basics—that is, to the original Agile Manifesto, which is, as it turns out, remarkably rule-free. But the piece did claim to discern a characteristic that has been present all along in the Manifesto but that has been under-appreciated: the organic—marked primarily by flexible but well-directed creativity. 

But that’s just a principle, and like any other principle it thus offers no guarantee that things won’t go “awry”, as the authors of a Harvard Business Review article we cited put it. That said, keeping it in mind as one attends to practical implementation can only help avoid both the pitfalls we saw in the last blog and point to practical fixes other than the often misguided rules and regulations produced in response. 

A couple of points before we proceed: 

Toothless theory? 

First, it might have looked as though blog 1 was opposing some realm of theoretical flexibility on the one hand to a domain of hands-on practicality where rules and restrictions apply. Why? Because it seemed to oppose the organic character of the original principles in the Manifesto to a lot of practical rules and regulations. But that’s not the case. It is important to flesh out what the organic principle might look like in practice and thus to claim ground that the last blog might have seemed to be giving up on: there is no reason why the realm of the practical should be all about rules and fixes, or why going back to basics should be about retreating to some realm of vague and toothless theory. Rather, what we need to do is identify practically focused tips that still respect, as they elaborate on it, the principle of well-guided, creative flexibility. More on this in a moment. 
 

Unhelpful lists 

The second point might seem to be a minor detail, but it is still worth making. If we look at the rules that have been proposed to start doing Agile right again, one thing stands out (or should): they are presented as lists: six guidelines, five rules, or three Laws, seven steps—all presented as the way to get “back” to Agile the way it was meant to be. 
 
Here’s why that matters. Lists are easily digestible and require little reflection. They are like recipes—a set of instructions that someone else has worked on in order to come to a pre-ordained result. They encourage passivity. By contrast, the authors of the Manifesto set out a number of principles, thus seeking to encourage critical engagement, and to promote a style or mode of activity. They were not calling for formulas. And they never said that that approach would be easy. (“Here’s one we made earlier—ta-daaa!”) 
 
Thus there’s nothing about the realm of the practical that entails “simple steps” that will in turn lead to some magic result. 
 

Out with lists out, in with engagement 

What we need, rather, is a practical fleshing out of the approach called for in the original Manifesto—an elaboration that shows the same sort of critical spirit that motivated the authors. Such an approach would reject quick fixes set out in a list, and instead encourage practitioners to be guided by the original principles and their own creativity—to keep their efforts organically agile. 
 
So let’s see what that might look like. 
 
Thankfully, there are already some practitioners out there whose practical guidance has an organic aspect to it. One example is a piece by Sam McAfee, You Aren’t Really Agile If You Aren’t Doing These 9 Things.
 
Yes, it’s a list—but in this case that’s just a cosmetic difference. One of the practices McAfee proposes is test-driven development (TDD). In a nutshell, TDD is
 
an evolutionary approach to development which combines test-first development where you write a test before you write just enough production code to fulfill that test and refactoring. 
 
On one view, which the author of this definition favors, TDD offers a way to “think through your requirements or design before your write your functional code (implying that TDD is both an important agile requirement and agile design technique). And one advantage it offers is that the coder develops “organically, with the running code providing feedback between decisions.” With TDD, “when a test fails you have made progress because you now know that you need to resolve the problem.” This is what is known, in non-specialist terms, as trial and error. 
 

Organic teamwork 

One aspect of Agile that “Getting the Most out of Agile” touched on only in passing was working in teams. It noted, somewhat dismissively, the obvious point that development should take place “collaboratively” (as though anyone should suggest that teams should not work collaboratively). “Work collaboratively” is not wrong—it’s just far too high-level. 
 
But since so much development does in fact depend on the quality of the teamwork involved, for present purposes it is worth looking at the practicalities of how teamwork can best reflect the principles in the Manifesto, and ratchet up progress efficiently—that is, in a well-directed but flexible fashion. 
 
McAfee has a couple of interesting prescriptions for teams that want to work in an effective, agile way. The first is that everyone on the team “shares a common goal” and “can easily and simply articulate that goal to any outsider who inquires.” The “easily and simply” is an especially apt way of putting it: note that McAfee did not say, “every member of the team will have the common goal drilled into them so they can articulate.” If you ask a non-specialist what their hands are for, for instance, they’re not going to go looking for a Manual on Hands. Rather, it’ll be, “Oh well, I can point, and pick things up, and look at this sketch I just drew,” and so on. 
 
McAfee also makes a point here that hits a false note but that actually help sharpen the present argument. The first is his insistence that each member of a team must “subjugate their own interests for the interests of the team”. We have to be clear that the subjugation of individual to collective interests is entirely alien to Agile. Moreover, in a professional setting there should of course be no contradiction, or even tension, between the interests of any group and those of the individuals that comprise it. 
 
Jim Highsmith writes of the group that produced the Agile Manifesto that “bigger gathering of organizational anarchists would be hard to find”—and it would be really difficult to convince anyone that such a group would call for, or ever put up with, the subjugation of individual interests for anything, let alone some group-level set of interests. Everything the group wrote indicates, rather, that the collective interest is the expression and the outgrowth of the interests (and views, and styles) of the individuals that make up the group in question.
 
In one sense, McAfee seems to be regarding a team as a functionally complete, organic whole. And of course that can be the case. Thus he’s implicitly appealing to a functional or processual organicity. But since, as we have just seen, what he’s calling for is not always possible, we must recognize that these conceptual frameworks have their limits. Just as we saw in Getting the Most out of Agile (1), descriptive terms that try to capture the essential characteristics of one or another approach are in the end merely attempts to achieve referential purchase, so that what we say actually refers to things in the world. In this case, the literal understanding of a team as an organic whole that has “living” parts rather than modular components does not serve us well: there’s an important sense in which we sometimes have to be über-practical and simply go with whatever works. 
 

From “organic” to “organism” 

All of which brings us to another piece that stands out from the thicket of articles on efforts to get back to Agile: The five trademarks of agile organizations, by Aghina et al. The article betrays some of the clunkiness we have seen elsewhere. But one statement seems, at first, to set it apart: 
 
agile organizations mobilize quickly, are nimble, empowered to act, and make it easy to act. In short, they respond like a living organism. 
 
Indeed, this latter assertion is presented as a major finding, highlighted in a subheading: by contrast with what they call the “[t]he old paradigm: Organizations as machines”, they trumpet “[t]he new paradigm: Organizations as living organisms.” 
 
We’ll leave aside certain elements of their finding as they present it, such as the assertion that being “empowered to act” or “making it easy to act” (whatever either phrase might mean here) could be a defining feature of being an organism. What is key for present purposes is the assertion that agile organizations respond like living organisms.” 
 
Unfortunately, having trumpeted this feature, the authors more or less leave it at that. One finding they highlight immediately after the above quote reads as follows: 
 
When pressure is applied, the agile organization reacts by being more than just robust; performance actually improves as more pressure is exerted. Research shows that agile organizations have a 70 percent chance of being in the top quartile of organizational health, the best indicator of long-term performance. 
 
What the authors mean by “living organism”, then, boils down to just one statement in the piece:  
 
We are now seeing a paradigm shift in the ways that organizations balance stability and dynamism. 
 
We look in vain for further clues to what the “living organism” metaphor (because that’s what it is) might mean. The five characteristics the authors attribute to agile organizations do not enlighten us any further. 
 
Worse yet, while each of these characteristics could presumably be seen as positive in some way, none of them has any discernible connection to the approach called for in the Agile Manifesto. 
 
All of this said, there is one aspect of the “living organism” metaphor that is worth highlighting here, and that builds on the organic character of Agile organizations that this piece and its predecessor have been arguing for—and here we pick up on the false note McAfee struck above. Blog 1 had it that the organic refers, in the present context, to human activity that is free to develop within a category we can call human creativity and self-development.” Producers cannot be creative in the Taylorist or Fordist environments that typify, for Aghina et al, organizations as machines. The assembly line, for instance, is designed to maximize, not creativity, but the intensity of labor and thus the quantity of deliverables, whether these are widgets or batches of code. 
 

A new cluster of features 

Under these conditions, labor is alienated labor, and that means we cannot speak about an organization as an organism, because within it there are two sets of competing interests: those of the producers themselves, whose labor is being controlled, and those of the owners of production, whose immediate interests lie in the maximization of productive output. These two sets of interests are, by definition, in competition with one another under such arrangements. 
 
We can thus see the interconnections among the organic, the fostering of human creativity (where “production is the unforeseeable”) and, crucially, the absence of any competition regarding interests within an organization, which can only then be said to be like a living organism. That’s because, in its default state, all parts of such an organism work in unison towards the promotion of a single set of interests. As any medical practitioner knows, an organism will turn on itself only when it is experiencing an immune disorder, such as result from multiple sclerosis, for instance. 
 
If taken to its logical conclusion then, the agility called for in outline in the Agile Manifesto covers more than just an approach to producing, whether software code or widgets. And it’s about more than just working arrangements: how teams are put together, how members collaborate, and so on. As hinted at (though, as we have seen, only vaguely) by Aghina et al, the agile approach covers not only ways of working marked by open-ended but well-directed creativity (where the directedness is coming from the associated producers themselves), but agility in the set-up of the organization itself. The agile organization must foster the well-directed pursuit of a single set of interests by all of its parts, in an arrangement where internal competition between sets of interests, which brings about alienated labor, for instance, cannot take place. This is, ultimately, the value of Aghina et al’s promotion of the “organism” simile. An organization that functions like an organism will not act against itself (just as an actual living organism will act against itself only in extraordinary circumstances).  
 

Numbers give the lie 

Now, while Aghina et al trumpet “organizations as organisms” as a new paradigm, the numbers they quote point to a less-than-remarkable uptake of any fully fledged agile approach, anywhere. They write that “agility, while still in its early days, is catching fire,” but we realize that that is putting things too strongly when we read, for instance: 
 
According to the results, few companies have achieved organization-wide agility, but many have already started pursuing it in performance units. 
 
The statistics they cite tell a similarly unimpressive story: 
 
  • “nearly one-quarter of performance units are agile” 
  • “less than ten percent of respondents have completed an agility transformation at the company or performance-unit level” 
 
The other statistics they cite in this connection are purely aspirational: “More than half of the respondents who have not begun agile transformations say they have plans in the works to begin one,” and so on. 
 
Why is it, then, that the actual rate of adoption should be so low (Aghina et al) or have so many problems (everyone else we’ve looked at)?  
 
One answer is that the conditions for the adoption of a truly agile approach cannot simply be willed into existence in the present environment. This is where the work of transformative (not gradual or partial) change needs to take place: only an organization that is fundamentally geared towards enhancing creativity and flexibility among all of its people, and that is itself the expression of a single set of interests, can rightfully be called agile. That is a necessary though not a sufficient condition for agile production, but it is the best we have. 
 
Now, just in case these statements seem to be a step too far, perhaps some qualification is in order: it may be possible to create some islands of agility, where individual teams create enough of an agile-like environment in order to produce in accordance with the principles set out in the Agile Manifesto. In such environments, the local pursuit of the agile method may yield the highest-quality output that has been produced iteratively and is delivered on time. 
 
But the uneven record of adoption that seems to be driving organizations and commentators alike round the bend is almost certain to continue until organizations themselves become truly agile. They must be able not only to marshal labor towards specific ends but do so in ways that promote the interests, and thus enhance and leverage the creativity, of the producers. Part of that (though only part) has to do with ending hierarchy as much as possible
 

Practical Agile 

A sampling of the prescriptions out there on fixing Agile, with their rules, regulations, and Laws, makes it clear that most of these authors are thinking at the level of the bug fixes, whereas it is clear that, if an entire sequence of code is compromised from the get-go, it needs to be thrown out and a fresh start made that respects best practice. Without such an overhaul, we simply won’t see the transformative change needed. 
 
With all this in mind, then, we can pick through the kinds of fixes that have been proposed and readily identify those that meet the criteria we have set out above. The watchword is creative, well-guided change pursued in accordance with a common set of interests and rendered excellently. As we have already seen, only a small few “fixes” meet these criteria. 
 
To sum up, then, here are some of the practical elements of an agile approach that can help us cut through the prescriptive fog that has been produced over the years by so many well-meaning but slightly befuddled commentators: 
 
  • Producers (developers and others) should do all of the common-sense things practical things that are often presented as insights but that should just go without saying: they should collaborate and be open to questioning, for instance, as the authors of the Harvard Business Review article suggest. 
  • They should work together with customers and be customer-centric: this is an interesting one, because it creates the idea that, rather than being seen as an adversary on the other side of a transactional relationship, a customer, too, could be viewed as part of a (larger) organism, so that, in turn, its interests and those of the organism could be seen as one and the same, at least for the purposes of the project. 
  • As a general matter, they should work iteratively, testing as they go.  
  • They should each see to it that the goals of the team and the project are the natural expression of the drive and creativity of the team’s members. 
  • Similarly, they should ensure that the interests of the team and, crucially, of the organization itself—are aligned with those of all members (employees, contractors, and so on).  
  • Finally, they should ignore irrelevant and unhelpful laws and rules such as (taking a list more or less at random) “Network of empowered teams”, “Dynamic people model that ignites passion” and “Next-generation enabling technology.” 
 
One irony that this list highlights is that, in order to get to the lightness of agile, quite a lot of heavy lifting is required at the practical level. Thankfully, the point of all the lifting is to declutter and realize the kind of simplicity that the authors of the Manifesto had in mind, such as when they wrote: 
 
Simplicity—the art of maximizing the amount of work not done—is essential