The message of today is clear: Everything must be agile . But agility also has its pitfalls. Starting with the question of what is meant by "agile" in the first place. The description of the Scrum process on a beer coaster, for example, leaves a lot of room for interpretation.
The question is justified whether, with the promised high speed, you don't end up in the countryside rather than reliably staying on track - i.e., focused on the goal. The typical statements of a Scrum team member with an agile manifesto sticker on the product backlog speak volumes in this regard: "I don't need a plan, because I develop agile", "I know what to do and don't need to document anything" or "Let the team figure out for itself what to do". Executives can't condone this and must take care to create a reliable framework for software development in their company.
But how can guard rails be defined in the form of principles so that high speeds are possible? How can the core elements of software development be communicated to those responsible in comprehensible language? The "Essence Model" provides answers to these questions. It provides a uniform framework for all software development processes. Starting with sequential, waterfall-like procedures up to agile models. This is made possible by applying a few simple principles.
Read more about agile methodology (German):
The name "Essence" says it all. It is about the "essential" ingredients for successful software development. What does that mean in practice? For example, it makes sense to consistently deal with the customer's requirements and to develop and specify them strictly within the framework of projects. In the example, this would be the alpha "requirement". The essential ingredients are called "Alpha" in the "Essence Model" - an acronym for: Abstract-Level Progress Health Attributes.
Essence consistently separates content (what?) and processes (how?). The model only makes specifications for content. This means that the workflows (software development processes) can be freely designed by the software managers or developers. This is important, because the latter often regard rigid process specifications as "nannying."
In the broadest sense, this is also comparable to "baking a cake". Certainly, there are a variety of recipes. Most have in common that the basic ingredients, such as butter, sugar, and flour are the same. They represent the essential contents. How the ingredients are then mixed and further supplemented is determined by the baker.
Elements of the Essence Model of Software Development. Photo: Oliver Laitenberger
With the separation of "what" and "how" the dispute about which procedure is "the best" ends. The baker does not decide on the ingredients, but on the procedure for mixing them. This means that the company defines as a standard which content is to be created and developed over time. The orchestration of the content is left to the person or persons responsible. As such, the essence model covers the full range from waterfall to agile.
So how can the progress in software development be determined? Many software projects show a green status for a long time until the end date is reached and then become a critical project virtually overnight. Early indicators are missing.
In the essence model, this works differently. The progress of the alphas is made transparent with the help of predefined "conditions" over time. Whether a condition has been fulfilled is determined on the basis of answers to checklist questions. In sum, this makes it possible to determine what progress has been made in software development and whether software development is on the right track.
The importance of risk management in the context of project management has unfortunately not yet been widely recognized – after all, dealing with risks is a sub-sub-sub-discipline of project management in many companies. In the context of the essence view, the topic of risk can be observed by the fact that there is a "Risks under Control" condition. In any software-based digital transformation project, this is the point in time when a first impression can be given to a customer based on executable software. In the end, only "executable software" and no documentation represents a suitable indicator for controlling risks.
Essence Milestone: Risks under Control. Photo: Oliver Laitenberger
The essence model permits a holistic statement about the "state of health" of the software development processes. The "Risk under Control" condition ensures the existence of executable software – but it says nothing about the scope and quality of the developed software. For this there are meanwhile innovative tools , which provide so to speak a map of the extent and contents of the developed software. Furthermore, the relationship between progress and results can be visualized accordingly.
Evaluation scope, content & progress with "seerene". Photo: Seerene
The combination of the essence model and the use of innovative tools provides those responsible not only with objective statements regarding the status and maturity of software development, but also with information on whether the software developed to date meets the required maturity status. Particularly against the background of digital development projects with investments sometimes in the millions, this transparency is indispensable for the purpose of planning and controlling digital projects.
Some well-known companies, such as Google or Munich Re, have already recognized the advantages of the essence model and adapted it as a standard. From this, the potential of the essence approach can be derived for other companies to finally get a grip on their software development. In addition, specifics of the respective company can be integrated into the model, so that the model is also suitable for project use beyond software development.
In a nutshell, the essence frame offers the following advantages for you:
Present "progress" and "health" of their software-based digital transformation projects in a way that everyone can truly understand.
Detach yourself from the dogmatic debate in the field of tension between non-agile and agile methods of working by establishing the guard rails as a framework and leaving the procedures to those responsible.
Easily determine what progress your development team(s) have made to date (whether non-agile, hybrid, or agile ) and where there will be roadblocks, if any.
Manage your risks from the start and scale small projects into larger ones.
Get a tool to create transparency into your digital projects before you've fully leveraged your investment.
Use available tools to provide visibility into the current development status of program code and improve planning and control.
Original article in German published in May 2020 in "Computerwoche ".