I periodically get asked if my Lucid solution is “agile.” The answer, of course, is no. It’s a tool. The better question is whether Lucid, as a tool solution, supports practices that are usually referred to as agile. So let’s talk about that.

The values expressed in the Agile Manifesto are given as a set of four preferences.

• Individuals and interactions over processes and tools.
• Working software over comprehensive documentation.
• Customer collaboration over contract negotiation.
• Responding to change over following a plan.

And note that they are preferences. Some people treat them as either-or’s, suggesting that you should take the first to the exclusion of the second. That’s simply not what is intended by the preferences. So a way to operationalize the question I started off with is to look at whether those preferences fit within the Lucid context.

Individuals and interactions over processes and tools

In my post that introduced Lucid I talked about how tools like Lucid help with “building up a shared understanding of quality” but I also talked about how Lucid is just as much an approach as it is a tool. The approach just happens to be encoded, at least in part, within the tool. As such, a Lucid approach is all about individuals and interactions. There are no heavy tool sets, no complex configurations, and no elaborate processes required. Writing requirements and tests via a TDL can be done on Notepad or a napkin. You don’t need a programmer’s editor to write tests. Those tests are in low-impact formats that are easy to modify and place a minimum on structural requirements (such as necessary indentation or length restrictions). That said, the TDL specifications do use structuring motifs to keep the signal-to-noise ratio low.

Along with the medium upon which you write, you use a set of heuristics to guide the writing itself. Further, a Lucid approach means that you update your heuristics as need be. This ultimately leads to transparency; what you do is reflected immediately in what the customer sees. Note that your customer does not just refer to users, but also to business analysts, developers, and testers. Anyone who is a consumer of the specifications is a customer of the Lucid approach. Your specifications are your tests and they are written in a domain language that should, in fact, mirror the requirements which, in turn, should be mirroring how those best served by those requirements speak. This is an intrinsically interactive process.

That being said, this is not an either-or. Like similar tools, Lucid can feel like a very technical tool. By default, it’s run from the command line, and the specification files are designed to be checked into source control tools — ideally along with the code that they test. Yet Lucid is supposed to help the business stakeholders on a team feel more in control of the development process. However, when testers and developers tuck their requirements and tests away in source control, the business side of the team can feel as though their source of truth has been locked away in some cabinet where using the keys is problematic.

So that’s why a Lucid approach focuses on both the individuals working together but with a recognized need for certain processes (like spec workshops) and tools (like Lucid itself). The bridging element there is that you allow the tools and processes to streamline interactions between individuals and you provide humanizing interfaces so that technical and non-technical individuals can work together.

That seems to cover the first preference from the manifesto.

Working software over comprehensive documentation

One major focus on the language of a TDL is to make any requirements executable in form. What that means is that large specifications are not the goal of a Lucid approach because such specifications tend not to be fully read, tend to go out of date, and tend to contain a lot of non-actionable material. A Lucid approach is not about creating and reading large documents; instead, a Lucid approach is about developers, testers, and business analysts jointly exploring their needs and the possible ways of answering those needs.

Those needs are encapsulated in a set of actionable — meaning, executable — tests that can be performed against software. Those tests can even be used to drive the specific implementation of that software. This is how a Lucid approach caters more to working software than a focus on comprehensive documentation.

That being said, “comprehensive documentation” means a lot of things to different people in terms of what “comprehensive” means. A Lucid approach doesn’t dictate that. By way of example, since the ‘documents’ of a Lucid approach are nothing more than text files, it’s trivially easy to create documentation that can be situated with more formal requirements, such as might be required for an audit or other company-specific practices.

So a Lucid approach is not an either-or here. It’s about allowing both, but allowing you to offset certain elements that are actionable. If those actionable elements are all you need, great. You’re all set. If you need some more supporting documentation that is required for various reasons, again, feel free to produce it.

That should cover the second preference from the manifesto.

Customer collaboration over contract negotiation

One of the reasons that the format of Lucid documentation is purposely minimal is because you will find solutions change as both the developers/testers and the users become more experienced with the problems being solved. The tests are stated in such a way that users understand what is going to be delivered. While the executable specifications (i.e., tests) can serve as a contract and certainly can provide a focus for negotiation, the emphasis is on making sure that negotiation can take place “real time” or “in line”, as it were, during the construction of the specifications.

So as with the other points this is not an either-or: you can have both.

That should cover the third preference from the manifesto.

Responding to change over following a plan

When customers and users — whether internal or external — see just how quickly a project can respond to change, and have confidence that those changes are reflected in actionable requirements written as tests, they start to trust that the team can deliver what is actually required, and not just what has been requested. (As we all know, there are sometimes gaps that are chasms between what was asked for versus what was really needed.)

This is all tied to the idea of being able to respond to change. A Lucid approach that focuses on the use of a TDL means that concepts can be expressed accurately and concisely. Since the TDL encourages a feature-focused, specification-based approach, this means changes tend to be localized. Further, the TDL tends to be easy to write because as more examples (tests) are put in place, it becomes easier to see how everyone talks about the business domain and what everyone believes is acceptable functionality for a given level of desired quality.

This allows you to respond to change because what is acceptable and what is considered desirable can change, based on either business, market, or technical realities. You can certainly follow a plan — that dictated by your just-in-time specifications. But since those specifications tie requirements to manual tests to automated tests, you have the ability to more quickly change your approach, design or implementation as needs dictate.

Again, not an either-or — a balance.

That should cover the fourth preference.

So What Is The Lucid Approach?

I’ll be the first to admit that when I say “Lucid approach” I have a series of ideas in mind that I don’t always articulate as well as I should. In general, however, the Lucid approach ot me is a flexible, adaptive, situational process where you are working alongside your customers and jointly determining priorities and solutions to problems in a common language. Further, you have a way to encode that language that is structured and concise and also capable of being written quickly now while being easy to reference and modify later. You have a way to specify acceptable behavior with customers and have that behavior encoded as documentation, which serves as a requirement to do a task, and a test that proves the task can be done in the software as it is documented.

That builds the notion of “acceptance” into the process such that you don’t really have an acceptance “phase”, per se; rather you have ‘customer acceptance’ as one of your built-in core values. Those statements of acceptance, encoded as tests, provide a focus and a target for development activities. These specifications of acceptance do not prescribe how to build the system; they describe what to build.

Does All That Mean Lucid Supports Agile?

Well, needless to say, processes that put acceptance front-and-center tend to be considered more “agile” than those that do not or that relegate any notion of acceptance to a “User Acceptance Test” phase tacked on at the end of a development cycle.

So hopefully I’ve convinced you that Lucid can be used in environments that are considered “agile.” Whether it is or not is really a function of how people combine usage of the tool as an adjunct to active collaboration in the service of discovering a shared notion of quality. Lucid, like other such tools, is not going to solve your problems for you. What it can do is provide a context wherein those problems can be discovered, discussed, elaborated upon and where solutions can be made actionable in the form of tests that drive and verify development.