The Essence Theory of Software Engineering - Large-Scale Classroom Experiences from 450+ Software Engineering BSc Students

Software Engineering as an industry is highly diverse in terms of development methods and practices. Practitioners employ a myriad of methods and tend to further tailor them by e.g. omitting some practices or rules. This diversity in development methods poses a challenge for software engineering education, creating a gap between education and industry. General theories such as the Essence Theory of Software Engineering can help bridge this gap by presenting software engineering students with higher-level frameworks upon which to build an understanding of software engineering methods and practical project work. In this paper, we study Essence in an educational setting to evaluate its usefulness for software engineering students while also investigating barriers to its adoption in this context. To this end, we observe 102 student teams utilize Essence in practical software engineering projects during a semester long, project-based course.

💡 Research Summary

This paper investigates the adoption of the Essence Theory of Software Engineering in a large‑scale undergraduate software engineering course, aiming to bridge the well‑documented gap between the heterogeneous methods used in industry and the more uniform curricula taught in academia. The study was conducted during the 2017 spring semester of the TDT4‑140 “Software Engineering” course at the Norwegian University of Science and Technology (NTNU). Over 450 second‑year students were organized into 102 project teams of four to five members each, resulting in a total of more than 450 participants. Each team was tasked with developing a functional software robot that could improve university education, a project that required them to interview real stakeholders, elicit requirements, design, implement, and deliver a complete software product.

Essence was introduced in the first lecture, where the seven alphas (Opportunity, Stakeholders, Requirements, Software System, Work, Team, Way of Working), activity spaces, and competencies were explained. Initially, teams were allowed to work with whatever development approach they preferred, which typically resulted in “ScrumBut” practices for the first three weeks. After this exploratory phase, the instructor introduced the Ivar Jacobson Practice Library and its practice cards, encouraging teams to map their processes onto Essence’s alphas and activity spaces. Use of Essence was deliberately optional; there were no mandatory checkpoints, and grades were not directly tied to the degree of Essence adoption. This design was intended to capture naturalistic data on both adoption and resistance.

Data were collected via written reflective reports submitted by each team at the end of the project. The reports were required to address three prompts: (1) what the team perceived as positive about Essence, (2) what they found problematic, and (3) how they actually employed Essence during the project. The authors performed a thematic analysis combined with a quantitative coding approach. Initial codes were generated inductively from the text, refined iteratively, and then applied across all 102 reports. The analysis yielded several key themes.

Positive aspects highlighted by students included: (a) a common vocabulary that facilitated intra‑team communication and inter‑team comparison; (b) explicit tracking of progress through alpha states, which made project health visible; and (c) the ability to integrate or compare multiple development methods (e.g., Scrum, Kanban) within a single meta‑model. These benefits aligned with the authors’ hypothesis that Essence can serve as a “method‑agnostic” scaffold for learning diverse industry practices.

Conversely, the most frequently reported barriers were: (a) a steep learning curve associated with abstract concepts such as alphas, states, and competencies; (b) insufficient instructional scaffolding—students felt the initial lecture did not provide concrete, step‑by‑step guidance for mapping their work onto Essence; (c) lack of tooling—teams relied on paper cards and manual tracking, which was perceived as cumbersome compared with automated dashboards (e.g., SematAcc) described in the literature; and (d) optionality—because Essence usage did not affect grades, several teams deprioritized it, citing a desire to focus on delivering functional software.

Based on these findings, the authors propose several pedagogical recommendations. First, introduce Essence incrementally with concrete examples and short, hands‑on workshops that reduce the initial cognitive load. Second, develop or adopt lightweight digital tools that automate alpha state updates and visualize activity spaces, thereby lowering the maintenance burden on students. Third, embed Essence usage into the assessment rubric so that students perceive it as a required competency rather than an optional add‑on. Fourth, schedule periodic instructor check‑ins to verify correct usage and provide timely feedback, which could improve both adoption rates and learning outcomes.

The study acknowledges several limitations. It is confined to a single institution, a single course, and a specific cohort, which may limit external validity. The reliance on self‑reported reflective reports introduces potential bias, as students may overstate benefits or underreport difficulties. Moreover, the optional nature of Essence in this experiment means that the observed adoption rates may be lower than in a mandatory setting. Future work could include controlled experiments comparing Essence‑using and non‑using groups on objective performance metrics, longitudinal tracking of graduates to assess industry transferability, and the development of a standardized curriculum module that integrates Essence with other agile and plan‑driven methods.

In conclusion, the research demonstrates that Essence can indeed provide a unifying framework that helps students understand and manage the complexity of real‑world software projects. However, for Essence to become a practical teaching tool at scale, educators must address its steep learning curve, provide adequate tooling, and align its use with assessment practices. Only then can the theoretical promise of a method‑agnostic, modular meta‑model translate into tangible educational benefits and better prepare graduates for the diverse methodological landscape of contemporary software engineering.