Essence, an Antidote to Method Prisons

In Ivar Jacobson and Co’s new book, « The Essentials of Modern Software Engineering », it is abundantly clear that there is a powerful overarching message that grips not only the world of software engineering, but also the world of agile. This article serves as a review of the book but also expands some of its thinking beyond software engineering.

« The Essentials of Modern Software Engineering » is as triumphant in its effectively simple approach to teaching software engineering as it is progressive when applying critical thinking to methods and practices. 

Having worked as a professional with agile delivery, change and transformation expertise in large enterprises for over 10 years, the basic problem the book addresses head on, namely that of “freeing the practices from the method prisons” befittingly translate outside of the software engineering domain and into the domain of agile methods and practices. Hence this perspective is the one I am using to write this review of Ivar and Co’s brilliant book, « The Essentials of Modern Software Engineering ». Befittingly because the agile movement is rooted in software engineering and then evolved into the domains of business and organisations. So, 19 years later from the writing of the Agile Manifesto for Software Development, we have now come full circle; back to Software Engineering to solve our “method prisons” problem.

It was some of the most progressive software engineering minds that put that Manifesto together solving a very real problem of how we should think about developing software in an age where advancing technologies outpaced archaic management practices and tragically in many places still do. Whilst the Manifesto may have been successful to an extent and undoubtedly made software development thinking and practices better, agile has evolved beyond its previous confines of the software engineering domain and into business and organisations with the tour-de-force of a thousand management consultancies and training organisations eager to sell you an out of box agile solution. 

Today, agile is being used and taught sometimes without the slightest reference to software engineering with exception perhaps to its origins story. 

So it seems fitting then and perhaps even slightly ironic that a book comes along almost 20 years later, written by some of the most respected minds in software engineering professing a solid foundational “common ground” for software engineering that could actually be applied to business and organisations where agile delivery, change and transformation is concerned. The result is that utilising a common ground and language for expressing thoughts and ideas in either domain isn’t only a good idea, but entirely fundamental to the industry. Fantastic. We’re once again saved by Software Engineers.

This is the reason the book has a much more powerful message and is incredibly relevant for this day and age, than at first glance. Essence as a model enables the software engineer to define and pull in his or her own practices that best suit situational context over the proliferation of using canned methods and frameworks. It provides a succinct notation referred to as the Essence “language” for doing so. Usefully, we can employ the Essence notation to describe agile frameworks and pretty much anything that can be thought of as a method or process. Identifying the useful practices for you and your teams and creating a composition of practices that are effective in solving your everyday problems is consistently possible with the Essence language. Now this thinking is contrary to many agile frameworks and methods out there, one of which literally states that it is “immutable” and in all its glory implies that any such customisation means you’re not doing it properly – Essence’s answer to this would be “so what?” Learning Essence will therefore unlock peak potential in your software engineering teams enabling you to continuously optimise your ways of working, this is something both software engineers and agile professionals in general should always be striving for.

The last decade or so has taught this industry that one size doesn’t fit all. How often do we have to keep failing without taking on board the lessons and how much pain do we have to keep enduring to finally realise that something has to change? Canned methods within software engineering or agile transformations are not the answer and can impede progress. So to repeat, this book’s message is a powerful one and one that reaches beyond the bounds of software engineering and into related realms of business and organisational expressions and it is with this particular note that I highly recommend the book to non software engineers as well as to software engineers. As a software engineer you will learn modern ways of thinking about your field, the Kernel that houses the common ground for practices, and a clear and succinct language for expressing a way of working and other elements that will serve you. As a non software engineer you’ll learn about software engineering (and why software engineering is different to programming). You’ll go on a journey with a student of Software Engineering named Smith and follow his thinking, developments and learning along the way. One particularly effective device the book uses is elucidating Smith’s thinking to draw key differences between software engineering theory and real world practice, which is established quite early on in the book and runs through it as a motif – this is an excellent way of teaching – by empathising with the reader through asking questions that the reader would ask, makes learning familiar, safer and more effective. As a previous software engineer myself, both academically and professionally, I really appreciated the way Smith’s views were portrayed as a learning tool, especially as he moves from academia into a professional team. 

The book describes the use of Alpha State cards that capture the key concepts of software engineering. These Alphas are a user friendly way of representing complex ideas visually and succinctly, leaving little (if any) room for interpretation. They can also be gamified and act as a powerful teaching and learning tool. Additionally, they allow for the progress and health of any software engineering endeavor to be tracked and assessed and also provide the common ground for the definition of software engineering methods and practices. It is this last category that is of particular interest. Here we have a way of rescuing practices that are “trapped in method prisons” using the Essence language. To us non software engineers, this means we have a way of universally communicating and describing our physical ways of working. Imagine a growing world where despite environmental and technical complexity you have a common and consistent way of communicating how you work. In a world full of different but similar agile methods and frameworks, this is invaluable. Such language would become essential for “programming in your ways of working”. Essence calls this, “making practices explicit”. A practice in this definition would for example be Scrum. By making Scrum explicit (which the book does in chapter 14), we have access to its patterns, work products and other elements that may have utility outside the practice of using Scrum. This goes for any practice. Such a tool would be indispensable especially to large enterprises and their obsession with consistency, which can sometimes run contrary to achieving agility, for they would achieve consistency in how they define and communicate their ways of working across the enterprise and among teams by creating a practice library of foundational elements described in a common and consistent language. I can think of at least three large enterprises I have worked with that could have benefitted from this approach – and still can. Moreover, for agile methods and frameworks that continue to be iterated, Essence will create a collaborative environment for their authors and practitioners, providing a much needed common language that will be useful for teams and organisations adopting them in part or wholesale and bridge gaps where terms differ but refer to the same thing, which can be confusing to newcomers and experienced professionals alike.

The powerful message fuelling Essence could well be Ivar’s magnum opus in the agile and software engineering industry, however I do feel that Essence as a message and Essence as a powerful device may be too understated unless it gets the propulsion it needs and is effectively expounded across the industry especially among the software engineering and the agile communities. Students of software engineering “get it” and now it’s time for agile professionals to “get it”. There is a direct correlation to the www.AgnosticAgile.org message and principles. Both Essence and Agnostic Agile are two sides of the same coin, one side focussing on software engineering and the other on agile methods and practices that are not necessarily software engineering related. As a professional, I am going to start experimenting with Essence in my practice. The Agile Practitioner’s propensity and admiration for canned methods needs to end and the practices freed and communicated using a simple consistent language that anybody can learn to understand. 

To conclude, Ivar Jacobson and his co-authors have done a great job in creating « The Essentials of Modern Software Engineering », it has relevance well beyond software engineering and makes an important statement – that a common ground for communicating is needed now more than ever. Kudos to Ivar for bringing Essence into the higher education space as well, I have no doubt that Essence will engender the kind of thinking, mindsets and practical actions we need to take in order to propel this industry forward and especially move us out of this “method prisons phase” that we might not realise we’re in.

4 réponses sur “Essence, an Antidote to Method Prisons”

  1. Yes, Agnostic Agile and Essence are « two sides of the same coin, one side focussing on software engineering and the other on agile methods and practices that are not necessarily software engineering related ». Thanks for making this clear to talk the software world – both the industry and the academics.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *