The Danish physicist and Nobel Laureate Niels Bohr believed that any concept, no matter how complex, should be explainable in plain, simple language. Bohr was instrumental in aiding understanding of Quantum Theory, a very complex subject indeed. He believed that once the heavy lifting was completed as to any theory, the key to advancement was in a collective understanding of what something generally is and its associated benefits. Not everyone was equally an expert in Quantum Theory. And there was only one Niels Bohr. Although he could have a conversation with others in his field on an equal footing, others needed to have some basic understanding of what these complex and abstract ideas could practically accomplish. Institutions and governments funded research, but sanction and funding were ultimately implemented by people; people who weren't on the same intellectual plane as Niels Bohr.
Simple does not mean dumbed-down. Simple means not complex. We can understand, in general terms, how a clock, a car, or a computer works without knowing how to build those things. Think of an elevator pitch and what's required for it to work. If an elevator ride lasts no more than 15 seconds, in that time, to get to the next step, the idea or concept must be expressed in language that anybody can understand. Understanding does not require expertise. If getting to the next step required equal footing on the same expertise, nothing would ever be accomplished. We're just trying to get to the next step, not solve every problem immediately.
What, then, qualifies as “plain, simple language?” That very much depends on your point of view and how that point of view meshes with other points of view. Those points of view must be reconciled for it to seem simple to all parties.
A specific area in software development where a common language between developers and users is in Domain Driven Design (DDD), an approach developed by Eric Evans. In that work, he coined the term Ubiquitous Language. Evans stated:
Domain experts should object to terms or structures that are awkward or inadequate to convey domain understanding; developers should watch for ambiguity or inconsistency that will trip up design.
DDD is a very good book for outlining what the two sides of the software development coin, developers and users, should do. If it were only that easy, to just speak the same language, to use common terms that reference the same commonly accepted thing. Bounded contexts and well-defined domain models sound good. Those things, which are DDD elements, are themselves the end-result of some other process. It begs the question of how we, the two sides, build “quality” software.
Quality can be a bit of a subjective, loaded term. In this context, is the software easy to understand? Does it work according to customer's expectations? That's a practical, not a theoretical concern. If the software doesn't work, all the theory in the world won't matter. The art of software development, as I see it, is the proper mix of theory and pragmatism. There's a lot of good theory in the DDD book and other resources, with some of it being useful in a pragmatic sense. It's always important to remember that the value of theory is a function of its application in the real world.
One possible answer to address how to employ plain, simple language is the Agile Manifesto and its 12 Principles (http://www.agilemanifesto.org/principles.html), in which the principles themselves are based on the Agile Manifesto (http://www.agilemanifesto.org). (Editor's note: The previous two URLs are not on secure pages, so may be initially blocked by your browser.) The Agile Manifesto and its 12 Principles are abstract concepts and are arguably written in plain, simple language. That's a subjective call based on a shared point of view.
The one thing I always found interesting about the Agile principles is the relative position of principle numbers One and Seven:
- Principle One: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Principle Seven: Working software is the primary measure of progress.
Why aren't these two principles adjacent to one another? Is that important? The only way software can deliver value to the business is if it's A): delivered, and B): works per the business's requirements. Reading the principles, the two are disconnected. Their relative position to one other is itself important context that aids understanding and thus goes to whether the language is truly “plain, and simple!” This is where having a good editor matters.
Then there's Principle Four: Business people and developers must work together daily throughout the project.
Does this mean that developers aren't or can't be business people? Are these mutually exclusive? What does it mean to “work together?” What about understanding each other?
How about Principle Three: Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale.
A couple of weeks vs. a couple of months? The term “couple” is more idiomatic English than a precise ordinal measure. Is it two weeks?
The principles declare a preference for “the shorter timescale.” Scrum, an agile-based framework, arguably conflicts, or, at the very least, makes ambiguous, whether Principle Three is a bona-fide agile requirement because at the conclusion of each sprint, the aim is to deliver “potentially releasable software.” If you don't release software, it isn't delivered. And if it isn't delivered, it isn't delivering any value. Just ask any businessperson who's funding the project with a budget and business objectives! The conflict here is that on one hand, scrum is based on Agile Principles. On the other hand, arguably, scrum, via the Scrum Guide (https://www.scrumguides.org) appears to throw this Agile principle out the window! In other words, as plain and simple as the language appears, when the one thing (the collection of principles) conflicts with the other thing (the manifesto) it's based upon, is the language really plain and simple? To the contrary, the language is ambiguous and becomes less and less useful. In such a case, the gulf between the theory and its practical usefulness increases. Theory, without any sort of practical application in the business context, is useless. In my opinion, Agile has drifted away from its roots in the manifesto, in part because of a lack of the plain, simple language that leads to better understanding.
I've always adhered to one basic principle: When in doubt, go back to basics. This isn't a rant against Agile. But of late, there has been some revolt against Agile and its progeny - scrum, in particular - citing that Agile just doesn't work. The Scrum Guide, where scrum is codified, has been “tinkered” with over the years. Once upon a time, it stated that scrum was simple to understand but difficult to master. I believed that when it was written, and I still believe that today, because it's true. The problem with the Scrum Guide is that it no longer states that simple, plain truth.
Scrum is simple to understand but difficult to master.
In the 2020 version, that statement was reduced to “scrum is simple.” The 2020 guide also states that Scrum is “purposely incomplete.” When the revision history between 2017 and 2020 is reviewed (https://www.scrumguides.org/revisions.html), you can note that, among other things, scrum has become less prescriptive.
There's also the change in wording from self-managing to self-organizing. Is that a distinction without a difference? Is that plain, simple language that leads to better understanding? No. That's a subjective call. It's one that each team and organization must answer for itself.
This is also not a rant against scrum, whether it's the scrum.org camp or the scrumalliance.org camp. Although there are two different organizations, and they both point to the same Scrum Guide (www.scrumguides.org) and the Agile Manifesto (www.agilemanifesto.org). (Editor's note: As noted above, the agile Manifesto page is not secure, so your browser may blcok the page.) How each camp describes scrum isn't always consistent. Heck, I've been practicing Agile principles in one form or another for over 20 years and I'm confused. It's for that reason that I've decided to use the Agile Manifesto as my sole basis to define Agile, which bears repeating in its entirety here:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work, we have come to value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items on the right (processes and tools), we value the items on the left (individuals and interactions) more.
The Agile Manifesto nailed it as far as A): plain, simple language, and B): what could be built from it.
Is Agile alone enough to build software? Of course not. Agile doesn't exist in a vacuum. Software development doesn't exist in a vacuum either. Business doesn't exist in a vacuum. If an organization is to adopt Agile, software development and the business must converge so that they can work consistently toward the same goals and objectives.
What is your software supposed to do? What is it not supposed to do? There are two essential elements; two sides of the software development coin: A): IT, and B): the business. Between the two, there's a chasm that must be spanned. The notion of a Ubiquitous Language, a term coined in the software development context in 2002, was on the right track but missed the mark through all its mechanics and ceremony. And it should be noted that IT serves the business, period.
All software has business requirements. Such requirements are going to be articulated in business terms by the business, as they should be, because it's the business that owns the software and will be the arbiter of whether the software works and consequently, whether it delivers value. It's incumbent on software developers to be the Rosetta Stone to make the translation. We must become experts enough in the business to do that. The business isn't going to be experts in software development.
In my experience, open, honest, and transparent communications is a great place to start. At the beginning of every project, people want the same thing. Agile may or may not be better than Waterfall in a given context; it all depends on your organization. After all, context is a necessary factor in assessing whether language is plain and simple. We must always consider who the audience is. It's an obvious point perhaps, but it's one worth repeating. Employing plain, simple language where individuals and interactions work and collaborate to build, modify, and deliver working software that yields value is, in my opinion, a more straightforward way of articulating the Agile Manifesto's true meaning and intent. As for the Agile Principles, that's up to you and your organization. There is, or at least there should be, a shared goal of getting things accomplished. Only you and your team can assess what those goals and objectives should be. Principles, absent context and what they are supposed to mean, despite what appears to be plain, simple language, are useless.
Every successful project has one thing in common: good people that had a shared goal. Yes, mistakes along the way are made. We never get it right the first or second time in most cases. For us techies, let's avoid tech talk. And if the business is lacking clarity on something, ask for more clarity. If something isn't feasible, explain why not in plain, simple language that conveys the right concerns that the business can act upon. If we don't do that, then how will we understand each other? And if we can't do that, how will we ever build and deliver working software that delivers value?
