work-blog/articles/Agile-Or-Whatever-You-Call-It.md

Over the course of my career on the development side of tech, I’ve worked in a wide variety of different environments, and been a participant in many different kinds of work processes. Some great, some not so great. Some extremely rigid, some extremely fluid. Some entirely paperwork bound, others completely undocumented. But one thing they all had in common, was the wide-eyed insistence that “*We’re an Agile shop!*” The one question that always comes to mind when they tell me this, especially after seeing how they actually work, is: “*but… why?*”

## Where Is The Evidence?

As a tech nerd, I’ve always been partial to very utilitarian answers to my problems. If you give me something that actually solves my problem, I’m satisfied. End of story. More to the point here, I’ve always had a natural suspicion of trends within the tech field that “smell” ideological, and at first the so-called “Agile Methodology” was one of the smelliest of these trends. The fact that it comes complete with it’s own “Manifesto” is certainly not helping its case. If your solution fixes my problem, it doesn’t need a “manifesto”, and if your “manifesto” doesn’t appear to be solving any problems, then it kind of doesn’t matter how pretty it looks on paper.

As a tester, I am partial to empirical methods, and my “facts on the ground” experience of Agile in practice has been very mixed. Some organisations policed themselves excessively, with product owners and scrum masters functioning as ersatz clergy enforcing very meticulous doctrines considered “Agile”, chastising transgressors, and turning the metaphor of the “ceremony” into a barely tolerable literal reality. Other organisations took “Agile” to mean whatever the organisation wanted it to mean, using the label it as a hollow “bat signal” to the kinds of engineering candidates the organisation believed it needed to attract.

Somewhere in between must lie a “golden mean”, as it were. An engineering team that is motivated and disciplined will certainly want to consistently employ practices that are conducive to building better products. But following practices for their own sake, or because they have a trendy label on them, is not actually the point of Agile.

It is true that, for a few organisations, the Agile methodology is obviously not going to work (the military, for example). It’s also true that for certain projects, the iterative Agile approach would be ridiculous (building a bridge, for example). However, it’s also true that, for the vast majority of business ventures (particularly tech-focused businesses), where uncertainty is high, creativity is essential, and the product landscape is constantly changing, the Agile methodology is the single best tool of success.

This is not the mere assertion of an enthusiast. There are hundreds of [examples](https://www.mckinsey.com/industries/financial-services/our-insights/ings-agile-transformation "https://www.mckinsey.com/industries/financial-services/our-insights/ings-agile-transformation") of [companies](https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/a-tale-of-two-agile-paths-how-a-pair-of-operators-set-up-their-organizational-transformations#/ "https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/a-tale-of-two-agile-paths-how-a-pair-of-operators-set-up-their-organizational-transformations#/") over the [last](https://www.fosway.com/innovation-profile-sky/ "https://www.fosway.com/innovation-profile-sky/") twenty five years that [have](https://www.forbes.com/sites/stevedenning/2018/04/06/transforming-hr-as-agile-business-partner-the-case-of-vistaprint/ "https://www.forbes.com/sites/stevedenning/2018/04/06/transforming-hr-as-agile-business-partner-the-case-of-vistaprint/") employed [Agile methodologies](https://www.techwell.com/2012/03/jp-morgan-chase-going-agile "https://www.techwell.com/2012/03/jp-morgan-chase-going-agile") (often coupled with Scrum practices) to improve their businesses and benefit their customers. Some are not even tech-focused. One particular example that might be relevant to us (because of our focus on audits), is [Mission Bell Winery, a California wine manufacturer](https://hyperdriveagile.com/videos/agile-in-wine-how-an-agile-mindset-transforms-traditional-manufacturing-67 "https://hyperdriveagile.com/videos/agile-in-wine-how-an-agile-mindset-transforms-traditional-manufacturing-67") that used Agile and Scrum to attain both [Safe Quality Food Institute certification](https://www.sqfi.com/ "https://www.sqfi.com/") and an ISO 9001 certification. But if anecdotes are not enough, there are [loads](https://www.sciencedirect.com/science/article/abs/pii/S0263786315000071 "https://www.sciencedirect.com/science/article/abs/pii/S0263786315000071") of actual [academic](https://www.sciencedirect.com/science/article/pii/S0164121212000532 "https://www.sciencedirect.com/science/article/pii/S0164121212000532") studies that [argue for it’s value](https://www.forbes.com/sites/tracybrower/2019/10/06/is-agile-really-worth-it-evidence-says-yes-if-you-do-these-4-things/ "https://www.forbes.com/sites/tracybrower/2019/10/06/is-agile-really-worth-it-evidence-says-yes-if-you-do-these-4-things/") as well, or at least [take it seriously](https://www.sciencedirect.com/science/article/abs/pii/S0263786315000071 "https://www.sciencedirect.com/science/article/abs/pii/S0263786315000071").

So, whether we’re talking about hypotheticals, real world case studies, or academic statistical analyses, the evidence is fairly clear: at worst, it suggests potential improvements to a business may be possible; at best, it has the potential to completely transform a business. But what about here at Perspectum? Would it have the same effect on us?

## Which End of Pareto Are We On?

Academic abstracts and hypotheticals aside, the question remains: Is Perspectum a place where Agile would (a) reasonably apply, and (b) add value to the business as an internal practice?

Some have already told me, unequivocally, no, it is not. They cite the regulatory regime within which Perspectum operates, they argue that Agile is too “casual” or “imprecise” to meet the demands of an exacting medical industry clientele, they argue that the academic nature of R&D does not lend itself to Agile processes, and they insist that Agile is just “an engineering thing”, not relevant to the rest of the business.

As simple facts, *some* of these things are true: Perspectum does operate in a highly regulated industry, Perspectum’s customers are very particular in their expectations, and R&D is heavily involved in the execution and publication of academic research studies. But it’s not at all clear to me how these facts are connected to any argument against Agile as a practice. Rather, each appears to be nothing more than an attempt to avoid the potential changes that correctly enacting the methodology would require.

Still, is asking for this change reasonable? Perhaps Agile at Perspectum is just a “solution in search of a problem”, as it were. Even if what we do might be amenable to Agile practices, perhaps the practices we already have, though not perfect, are “good enough” – and even if we work in a field of businesses that are typically structured along Agile lines, maybe doing what everyone else is doing, is not a great plan for us. Perhaps we are indeed among the exceptional 20%, who cannot make good use of Agile practices, for various circumstantial or structural reasons.

## Yes, Agile Applies To Us

I do not think it is the case that we are special, with regard to the particular product development practices we adopt internally. Even the academic R&D is something that could feed into an Agile approach to product development. Indeed, I think we are actually situated as precisely the kind of industry “disrupter” that everyone in tech was fawning over a decade ago, and precisely the kind of organisation that could benefit from a more serious commitment to Agile practices.

Let us address the claim above that Agile practices necessarily encourage sloppy, inexact, or low-quality product development. Near as I can tell from my three months in the company so far, is that this complaint comes directly out of a move toward agility internally that has largely taken place without any vision for what structure would replace the old command-and-control approach – and yet, everyone is still calling whatever this new approach is, an “agile” approach.

While the relaxation of command-and-control structures and the reduction of bureaucratic oversight processes may make the firm more responsive to market demands and more nimble with regard to its competitors, that doesn’t necessarily make it an “agile” business. Those who see rigid structural oversight as synonymous with a high quality product are going to protest at the relaxation, and because the relaxation of these structures is being called “agile”, they will necessarily associate the Agile methodology with a diminishment of the product offering.

The point of Agile is not the avoidance of bureaucratic overhead, the liberation of workers from command-and-control structures, or the avoidance of rigorous quality standards. The point of Agile is *delivering maximum value to customers*, in t*he best possible way*. Depending on the market, that very often requires incredibly exacting quality standards, and very demanding delivery schedules. Neither of which necessarily makes Agile an ill-fitting approach to the business. An excellent example of the fact that Agile does not by itself encourage low quality or inexact standards, is Apple computer.

After Steve Jobs return to Apple in the early 2000’s, the bulk of Apple’s development efforts – from the iMac, to the iPhone, to the MacBook – were guided by Agile practices. At the same time, over that period (particularly during the tenure of Jony Ive), Apple was *infamous* both among its customers and its manufacturing partners, for its extremely demanding quality standards. Apple engineers are some of the most sought after in the tech field, for their capacity for creative collaboration, and for their technical competency and attention to detail. And yet, they worked in an Agile way.

There is no question that what we do at Perspectum is both technically sophisticated and high stakes, and that the nature of the business demands exacting standards for products in which the total landscape of risk includes life and death (at least, indirectly). That is certainly nothing at which to thumb one’s nose. But it is a mistake to think that the only way to insure a quality product is to anticipate every risk, and avoid every error before the product leaves the paper stage. It is to make fear the primary motivation of the company, rather than the desire to do good.

It is true that Agile development, which is an iterative process of self-correction over time, *expects* errors and mistakes to be made as part of the process. It is also true that Agile development discourages attempting to “plan” your way out of those mistakes. Indeed, one of the four primary Agile principles is “*Responding to change **over** following a plan*”. However, this is not a counsel of despair. Agile is not suggesting that you abandon care and do whatever feels good in the moment. Rather, it is suggesting that our impulsive response to risk might not be the best answer to the problem of risk, and that *deliberate adaptation* is preferable. To [paraphrase the stoic Epictetus](https://www.instagram.com/p/BurJYwhgm4t/ "https://www.instagram.com/p/BurJYwhgm4t/"): *“You cannot control what happens, but you can control how you react to what happens.”*

Near as I can tell, there is nothing we do at Perspectum that suggests that this approach to product development is not a possibility for us. We are in the business of providing high quality information to medical practitioners, through the use of computing technologies. Abstracting the specific customers, the same could be said of any number of other businesses in the tech space – from sports betting to space travel. The vast majority of which, employ Agile processes of some sort or another.

Certainly, being in the medical market requires us to comply with various legal and regulatory demands. But this is also true of almost every consumer product manufacturer and food producer, and many kinds of service business. From frisbees to automobiles, taco stands to tax consultants, there are a wide array of legal and regulatory expectations that these businesses must comply with, in order to remain in business. That doesn’t stop many of them from adopting Agile practices – including such top-heavy examples as [JP Morgan Chase](https://www.techwell.com/2012/03/jp-morgan-chase-going-agile "https://www.techwell.com/2012/03/jp-morgan-chase-going-agile"). So, why ***not*** us?

## What Are We Talking About, Exactly?

<img title="" src="file:///Users/gregory.gauthier/Documents/BlogPosts/76bbc630-67bf-4c78-9343-543f6a32786f.png" alt="" width="599" data-align="center">

For all my suspicion of “manifestos”, if we actually inspect [the Agile Manifesto](https://agilemanifesto.org/ "https://agilemanifesto.org/") what we find is not an ideological doctrine, but a list of *pragmatic* value preferences around the way that the authors work on software projects. The primary statement of the four values is also mercifully short. Let’s have a look at them here:

This is an interesting list. Let’s examine it in broad strokes to begin with:

- The first thing we notice (unlike ideological manifestos), is that the language is extremely *terse*, and *very nonspecific*. Which individuals? What processes? What sorts of changes? Who’s plans? This, it turns out, is by design. One of the central features of Agile, is that while the manifesto is meant to express a *value judgment*, it was not meant (also unlike ideological manifestos) to *prescribe solutions*.

- Another thing we notice immediately: the value statements are neither categorical, nor absolute. While there will be more absolute assertions later (in the 12 principles), these initial assertions are *value preferences*, not edicts or rules or even a procedure for choosing between them. What’s more, the authors make this explicit in the final clarification: “*we value the items on the left more than we value the items on the right*”. The language is intentionally “more” and “less”, not “shall” and “shan't”.

- Finally, what stands out, is the de-emphasis of *transactional* ways of working, and the emphasis on *relational* ways of working. The first and third principle speak directly to this. Processes, tools, and contracts, all suggest a highly transactional environment: I advertise a service. You make a request. I agree to satisfy the request in a certain way at a certain time. I employ certain tools and processes to satisfy the request. You receive the output according to the agreed upon conditions. This is the way we engage with vending machines, coffee makers, and ATMs. But the authors of the manifesto are recommending an *interpersonal* approach to software development: “individuals”, “interactions”, “helping people”, and “collaboration” all evoke an image of conversational engagement, rather than service window processing.

## The Underlying Principle

This short list of primary values opens into [a more specific list of 12 “principles”](https://agilemanifesto.org/principles.html "https://agilemanifesto.org/principles.html"), each one providing a more pointed clarification of the value set. The first principle in the list demonstrates this:

<img title="" src="file:///Users/gregory.gauthier/Documents/BlogPosts/faf64c11-e473-487e-8e61-b1b37bf1a0bb.png" alt="" width="491" data-align="center">

Here we have the value of “***working software***”, implemented in the principle of “continuous delivery”, culminating in *customer* *value*. Implicit in this principle, is the value of “***customer collaboration***”. The customer is necessary to determine what “valuable” actually means. However, as put by one Agile author, what the customer wants is not what the customer needs. The customer wants his problem solved. He is best placed to understand what that problem is, but not what the solution to it should be. What the engineer is best placed to understand, is how to solve that problem. This is where the “collaboration” part of the “customer collaboration” comes in. Conversations about wants and needs, priorities and preferences, constraints and possibilities, end in a shared idea of a solution to a problem. That is not one conversation, that is many. And it happens in frequent iterations through the continuous delivery of working software.

In this principle, you can also see the implicit appeal to the value of “***individuals and interactions***”. Developers and customers are motivated by the same desire to solve a problem, and interactions refining that solution will occur organically if the software is delivered frequently. While not entirely eliminated, there will naturally be far less need for fixed schedules of meetings, and far less dependency on the legalese of requirement specifications, in such an environment.

The remaining eleven principles all orbit around the four values, and this initial principle: working software, frequent iterations, frequent collaborations (between business and engineering, as well as between business and customer), self-organisation, simplicity, regular self-correction, technical excellence, good design – all of these are part of the principles, and all of them lead back to one thing: *value to customer*.

Fundamentally, it doesn’t matter how skilled, how fast, or how efficient you are as a team, apart from one additional metric: does it solve your customer’s problem? If you want to solve your customer’s problem, you would certainly be better off with these attributes than without. However, putting them to good use requires *collaboration*.

For example, principle 7 of the manifesto says, “***Working software is the primary measure of progress***”. The question the development team needs to ask itself, is “*what does ‘working’ mean?*” It cannot answer that question in isolation. It can only be answered in the context of the first principle: working software is *valuable* software, and valuable software is software that *solves a problem for a customer*, and we know when that problem is solved, when we have a conversation with the customer over the software we have delivered to him, and he expresses *satisfaction*. Without regular collaboration with the customer, this is not possible. Without regular delivery of software, the collaboration would be pointless. Hence, *working software is the primary measure of progress*, because working software is the manifestation of customer satisfaction.

## The Value For Perspectum

The most interesting feature of the Agile Manifesto (and its accompanying methodologies - e.g. Scrum and Kanban), is that it has demonstrated the utility of its principles not merely in the successfully delivered software products of other organisations, but also in the fact that the Agile organisational approach is itself *an effective solution to organisational problems*. It’s very practice is intentionally introspective and adaptive (something that ideological doctrines *rarely ever* are). It is meant to be structured enough to offer a principled approach to praxis, but fluid enough to enable working relationships of enormous variety and quality, all with the same goal: *delivering value to customers*. Far from being a “solution in search of a problem”, Agile has the potential to be one of an organisation’s most valuable assets.

But can it be so valuable to Perspectum? Very simply put, Perspectum is still primarily a “plan-driven” development organisation. “Plan-driven” is the polite new way to say “Waterfall”. As I’ve mentioned above, this isn’t *necessarily* a “bad” thing. It could be that top-down plan-driven solution development is the best approach for us, given the nature of our customers (largely hospitals, clinics, and commercial Pharma research organisations). But I wonder (aloud now, via this blog post) if that is actually the case.

I have heard Banjo say things in our Update Meetings that heavily suggest he may be sympathetic to the “Agile” approach to what we do. But this is in some sense, paradoxical. One of the principles of Agile is “self-organisation”. Specifically, principle 11: “T***he best architectures, requirements, and designs emerge from self-organising teams.***” If this is true also for the architectures of organisations themselves, then a C-suite imposition is probably a bad idea. In short, having someone like Banjo impose a transformation plan from the top down, is a self-defeating desire in the face of the Agile principle. What’s more, if the outcome of self-organisation is precisely what I see around me now, then perhaps I am still too fresh to realise we’re already optimised.

Call me stubborn, but I remain unconvinced of this.