This article is intended to people who are interested in successful adoption of agile methods / ways of working – an area of maybe as much as 50% failures.
Guidelines on how teams and organizations are suggested to work have been proposed since we started to develop software. Such guidelines have usually been called agile methods or lately “ways of working”. Over the years we have had a large number of published methods. Until now, all methods have had no other representation than as books in physical or electronic form (even web sites). Thus, methods are just let’s say theory. Once the users, such as developers, have got some training in the theory and are supposed to actually use the theory in practice, they are left alone. No support is actually given during the daily work to put theory into practice. This is one of the challenges that Essence, the OMG industry standard addresses.
1. Introduction
Methods for software development have been around for more than 50 years. The early methods such as SA/SD, SADT, SREM were mirroring how a computer worked and separated functions from data. These methods, probably not known to many of you, were popular until the next paradigm based on objects and components became popular at the end of the 1980s. The most popular of these methods became the Rational Unified Process (RUP). These methods became old-fashioned when around year 2000 the next paradigm, Agile, made its entrance. Agile is still the paradigm we follow and there is no shift on the horizon.
The number of published methods since 1960 is large[1]. Since every team or organization has its own way of working, documented or tacit, the total number of actual methods used in practice is huge. Whatever numbers we think it is, we know a few things:
• Methods have no common ground; the only thing we share is the English language, or the natural language the method is described in. We cannot even be sure that basic terms such as “testing” and “team” have the same meaning in different methods.
• Methods are controlled by method gurus. I was myself such a guru for RUP, and I thought it was a clear sign of the industry being immature.
• All methods are monolithic. This means that other methods can’t just reuse parts from a particular method without rewriting these parts.
As a consequence, we have been suffering from methods war for 50 years. The successful gurus don’t collaborate; they compete with one another. Since I, like most of you, truly believe in collaboration, I am flabbergasted that the software world has accepted to live under such primitive circumstances for so long, almost 50 years.
This was the original reason we created Essence, which has been adopted as a standard by OMG. It addresses these problems and many more. In doing so it will help us to create a more collaborative world and to essentially eliminate the methods war. We will still have debates between experts, but the need for gurus acting as competing methodology salesmen will be gone; they should be “collaborative evolvers of industry wisdom”.
However, in this article I will address a very different problem that Essence addresses.
2. Methods are only Theory
Most methods, even the widely used ones, are made accessible though media such as books, papers, slides, videos, etc. The learning cycle is basically up to the user (experienced developer or novice) herself or better by being taught in class with a quality certification by the method provider. The user has learnt the method theory.
However, when it comes to the delivery cycle – the user has to do something, such as develop software, the user is on her/his own. So far, the method creators have not provided any help when the users are actually doing the job. We, who create methods, have focused our efforts on developing fabulous methods (as we believe) with training, possibly complemented with consulting. That was true for RUP and it is true for the most modern and popular methods of today. It has not changed over the latest 20 years. In fact, it has not changed since the beginning of software development.
Thus, the user has to either remember what to do or go back to the study material and recall what to do. My long experience in software development – both as a developer but primarily as a coach and creator of methods, tells me this is where it fails. We should have known better. Already Confucius (also attributed to Benjamin Franklin) knew: “Tell me and I forget, teach me and I may remember, involve me and I learn.” This experience has since been developed into a science, “experiential learning.”
Some users may be passionate about the new method they have learnt and follow it as intended. Others, usually in majority, don’t care much about which way of working they have to use, but they care about having a way of working which they think is useful. Having no support when they actually work may make the task to follow the method overwhelming. Thus, they either protest quietly by instead of doing as suggested they do what they have done in the past, or they protest aggressively by pointing at the lack of real experience by the method creators – they are academics.
Essence is developed to give support not just for the learning cycle – methods in theory, but also for the delivery cycle - methods into practice.
3. Essence puts Methods into Practice
Essence with its use cases can be compared with the engine of a car. The normal user of a car doesn’t need to think about how the engine works in detail. She or he just needs to know how to drive the car with the steering wheel, accelerator pedal, brakes, etc. Likewise, a developer using a method designed using Essence as a platform doesn’t need to know how Essence works internally. What she or he needs to know is quite simple. However, to understand how it can be that simple, I will describe a bit more in detail how it works.
One of the unique properties of Essence is that it is, as we say, actionable - a word that has connotations to executable. However, since Essence is not software in its classical meaning we prefer a different word. This property comes from the way Essence reflects that endeavors move from a beginning (state) to an end (state) and in between work through many intermediate states. As an example, a software system may be seen as moving through these intermediate states: architecture selected, demonstrable, usable, ready and operational. With every state there is a list of checks to be achieved.
An essentialized method is described by using Essence as a platform on top of which the specifics of the method are described. How transitions from one state to another are achieved is usually method-specific and not part of Essence, being an international standard. The essentialized method will provide proposed guidelines for achieving these state transitions.
Thus, Essence and essentialized methods are actionable. With proper tools, such as Essence in Practice TeamSpace™, we can give guidance to the people having to do the job as they work. They don’t need to go back to the study material to find out what they should do. And, of course, they don’t need to obey the guidance blindly. The guidance may be just inspirational.
With such guidance it will be easier for the user to perform the practice. Thus, the user can focus her attention more on the creative elements of the practice or on a better way of working to improve the practice.
To see how some popular methods are already being actionable by Essence, both Scrum and Scrum@Scale have been essentialized, transforming these widely adopted frameworks into tangible tools for teams that provide Live Guidance™ for their everyday work. You can see how Scrum Essentials works in this easy to understand video: https://bit.ly/398vuiw.
The ACM Queue paper “Scrum Essentials Cards – Experiences of Scrum Teams Improving with Essence” presents a set of games that you can play: https://essence.ivarjacobson.com/sites/default/files/field_iji_file/article/scrum_teams_improving_with_essence.pdf.
Dr. Jeff Sutherland’s blog is also very instructive https://www.scruminc.com/better-scrum-with-essence/. Dr Sutherland says among many other things: “Essence is the key to success”.
Eureka, we dare say that Essence puts Methods into Practice.
[1] https://en.wikipedia.org/wiki/Software_development_process.