January/February 2018 issue of acmqueue

The January/February issue of acmqueue is out now


  Download PDF version of this article PDF

The Essence of Software Engineering: The SEMAT Kernel

A thinking framework in the form of an actionable kernel

Ivar Jacobson, Pan-Wei Ng, Paul E. McMahon, Ian Spence, Svante Lidman

Everyone who develops software knows that it is a complex and risky business, and its participants are always on the lookout for new ideas that will lead to better software. Fortunately, software engineering is still a young and growing profession that sees innovations and improvements in best practices every year. Just look, for example, at the improvements and benefits that lean and agile thinking have brought to software-development teams.

Successful software-development teams need to strike a balance between quickly delivering working software systems, satisfying their stakeholders, addressing their risks, and improving their ways of working. For that, they need an effective thinking framework that bridges the gap between their current ways of working and any new ideas they want to adopt. This article presents such a thinking framework in the form of an actionable kernel, which could benefit any team wishing to balance their risks and improve their way of working.


Work on the kernel, the essence of software engineering, was inspired by and is a direct response to the SEMAT (Software Engineering Methods and Theory) call for action (see figure 1). It is, in its own way, one small step toward redefining software engineering.

SEMAT was founded in September 2009 by Ivar Jacobson, Bertrand Meyer, and Richard Soley, who felt the time had come to fundamentally change the way people work with software-development methods.3,4,8 They wrote a call for action statement, which in a few lines identifies a number of critical problems, explains why there is a need to act, and suggests what needs to be done. The call for action is:

Some areas of software engineering today suffer from immature practices. Specific problems include:

• The prevalence of fads more typical of the fashion industry than an engineering discipline.

• The lack of a sound, widely accepted theoretical basis.

• The huge number of methods and method variants, with differences little understood and artificially magnified.

• The lack of credible experimental evaluation and validation.

• The split between industry practice and academic research.

The SEMAT call for action's assertion that the software industry is prone to fads and fashions has led some people to assume that SEMAT is resistant to new ideas. This couldn't be further from the truth. As you will see in this article and in a soon-to-be-published book (The Essence of Software Engineering—Applying the SEMAT Kernel),6 SEMAT supporters are very keen on new ideas. What they are against is the non-lean, non-agile behavior that comes from people adopting inappropriate solutions just because they believe these solutions are fashionable—or because of peer pressure or political correctness.

SEMAT supports a process to redefine software engineering based on a solid theory, proven principles, and best practices that:

• Include a kernel of widely agreed-upon elements, extensible for specific uses.

• Address both technology and people issues.

• Are supported by industry, academia, researchers, and users.

• Support extension in the face of changing requirements and technology.

The SEMAT call for action received a broad base of support, including a growing list of signatories and supporters (http://www.semat.org). In February 2010 the SEMAT founders developed the call for action into a vision statement.5 In accordance with this vision, SEMAT focused on two major goals:

• Finding a kernel of widely agreed-upon elements

• Defining a solid theoretical basis

To a large extent these two tasks are independent of each other. Finding the kernel and its elements is a pragmatic exercise requiring experienced software developers with knowledge of many of the existing methods. Defining the theoretical basis is academic research and may take many years to reach a successful outcome.

The Power of The Common Ground

SEMAT's first step was to identify a common ground for software engineering. This common ground is manifested as a kernel of essential elements that are universal to all software-development efforts, and a simple language for describing methods and practices. The kernel was first published in the SEMAT OMG (Object Management Group) submission.2,9 As shown in figures 1 and 2, the kernel contains a small number of "things we always work with" and "things we always do" when developing software systems. Work is also ongoing to define the "skills we always need to have," but this will have to wait until future versions of the kernel.

More than just a conceptual model, the kernel provides:

• A thinking framework for teams to reason about the progress they are making and the health of their endeavors.

• Common ground for the discussion, improvement, comparison, and sharing of software-engineering methods and practices.

• A framework for teams to assemble and continuously improve their way of working by the composition of separately defined, and sourced, practices.

• A foundation for defining practice-independent measures to assess the quality of the software produced and the methods used to produce it.

• Most importantly, a way of helping teams understand where they are, what they should do next, and where they need to improve.

The Big Idea

What is it that makes the kernel more than just a conceptual model of software engineering? What is it that's really new here? This can be summed up in its founding principles (see figure 3), which really bring out three unique features of the kernel: it is actionable; it is extensible; and it is practical.

The Kernel is Actionable

A unique feature of the kernel is the way that it handles the "things to work with." These are captured as alphas rather than work products (such as documents). An alpha is an essential element of the software-engineering endeavor—one that is relevant to an assessment of its progress and health. As shown in figure 1, SEMAT has identified seven alphas: opportunity, stakeholders, requirements, software system, work, way of working, and team.

The alphas are characterized by a simple set of states that represent their progress and health. As an example, the software system moves through the states of architecture selected: demonstrable, usable, ready, operational, and retired. Each state has a checklist that specifies the criteria needed to reach the state. These states make the kernel actionable and enable it to guide the behavior of software-development teams.

The kernel presents software development not as a linear process but as a network of collaborating elements that need to be balanced and maintained so teams can make effective and efficient progress, eliminate waste, and develop great software. The alphas in the kernel provide an overall framework for driving and progressing software-development efforts, regardless of the practices applied or the philosophy followed.

As practices are added to the kernel, alphas will be added to represent the things that either drive or inhibit the progress of the kernel alphas . For example, the requirements alpha will not be addressed as a whole but will move forward item by item. The progress of the individual requirement items will either drive or inhibit the progress and health of the requirements alpha. The requirement items could be of many different types: for example, features, user stories, or use-case slices, all of which can be represented as alphas and have their states tracked. The benefit of relating these smaller items to the coarser-grained kernel elements is that it allows the tracking of the health of the endeavor as a whole. This provides a necessary balance to the lower-level tracking of the individual items, enabling teams to understand and optimize their ways of working.

The Kernel is Extensible

Another unique feature of the kernel is the way it can be extended to support different projects (e.g., new development, legacy enhancements, in-house development, offshore development, software product lines, etc.). The kernel allows you to add practices, such as user stories, use cases, component-based development, architecture, pair-programming, daily stand-up meetings, self-organizing teams, and so on to build the methods you need. For example, different methods could be assembled for in-house and outsourced development or for the development of safety-critical embedded systems and back-office reporting systems.

Practice separation is the key idea here. While the term practice has been widely used in the industry for many years, the kernel has a specific approach to the handling and sharing of practices. Practices are presented as distinct, separate, modular units, which a team can choose to use or not to use. This contrasts with traditional approaches that treat software development as a soup of indistinguishable practices and lead teams to dump the good with the bad when they move from one method to another.

The Kernel is Practical

Perhaps the most important feature of the kernel is the way it is used in practice. Traditional approaches to software-development methods tend to focus on supporting process engineers or quality engineers. The kernel, in contrast, is a hands-on, tangible thinking framework focused on supporting software professionals as they carry out their work.

For example, the kernel can be touched and used through cards (see figure 4).7,10 The cards provide concise reminders and cues for team members as they go about their daily tasks. By providing practical checklists and prompts, as opposed to conceptual discussions, the kernel becomes something the team uses on a daily basis. This is a fundamental difference from traditional approaches, which tend to overemphasize method description as opposed to method use and tend to be consulted only by people new to the team.

Cards provide concise descriptions that serve as reminders for team members. They can keep the kernel as a small deck of cards in their pockets, which they can easily pull out to discuss the current status of development and the work assignment and collaboration among team members. Teams can also discuss areas of improvement by referring to the cards. Thus, the kernel is not merely a heavyweight description of what a team needs to do. Rather, it forms an essential part of what they are doing each day.

The Kernel in Action

The kernel has many applications in software professionals' everyday lives. They include:

• Running an iteration (or sprint).

• Running the entire development from idea to product.

• Scaling to large organizations and complex software-development endeavors.

The first application, planning an iteration, is used here as an example of what a team can do with the kernel. The others are covered fully in The Essence of Software Engineering — Applying the SEMAT Kernel.6

The example presented here assumes that a company has very little in the way of formal processes. In the past it has relied on having skilled and creative individuals on experienced teams, but the company is now growing and has many new hires. These new employees, mostly fresh out of university, have good technical skills—for example, in programming languages—but are less equipped in other aspects of software development, such as working with stakeholders to gain agreement on requirements.

This company has a development team that is responsible for making a mobile social-network application that lets users share and browse ideas, photos, and comments. The team began with only two developers, Smith (the team leader) and Tom, both of whom are familiar with the kernel. They are later joined by two more developers, Dick and Harriet, who are new to the job and have no previous knowledge of the kernel. Success to team leader Smith means more than functionality, schedule, and quality. This team ran development iteratively. You can think of planning an iteration as follows:

1. Determine where you are: work out the current state of the endeavor.

2. Determine where to go: decide what to emphasize next and what the objectives of the next iteration will be.

3. Determine how to get there: agree on the tasks the team needs to do to achieve the objectives.

Determine Where the Team is using the Kernel

Let's assume that Smith and his team are six weeks into development. They have provided an early demonstration of the system to their stakeholders, who are pleased and provide valuable feedback. The system is not yet usable by end users, however. If you are using alpha state cards, then you can do a walk-through as follows:

1. Lay out the cards for each alpha in a row on a table with the first state on the left and the final state on the right.

2. Walk through each state and ask your team if you have achieved that state.

3. If the state is achieved, move that state card to the left. Continue with the next card until you get to a state that your team has not yet achieved.

4. Move this state card and the rest of the pending state cards to the right.

Figure 5 shows the states Smith's team has achieved on the left, and those not yet achieved on the right. For simplicity, figure 5 shows only three of the kernel alphas.

Determine Where to Go with the Kernel

Once the team agrees on the current alpha states, the members discuss what the next desired "target" states are to guide their planning. The team agrees to use the immediate next alpha states to help establish the objectives of the next iteration, as shown in figure 6.

How They Planned to Achieve Them

α Way of Working

Both Dick and Harriet agreed that they had diculties in applying automated testing. They needed help in order to make progress. Tom agreed that he had to spend time teaching them:

A task was added to the iteration backlog for Tom to conduct training on automated testing for Dick and Harriet.

Task 1. Conduct training on automated testing.

α Software System

This state reminds us that the software system must be shown to be of sucient quality and functionality to be useful to the users. So far, Smith's team had been testing within its development environment. Now, it had to conduct tests within an acceptance-test environment, which they had yet to prepare. This resulted in the following task:

Task 2. Prepare acceptance-test environment.

Task 3. Complete requirement-item A: "Browse online and oine."

Task 4. Complete requirement-item B: "Post comment (online and oine)."

Task 5. Complete requirement-item C: "Browse album."

α Requirements

This state reminds us of the need to work with stakeholders to ensure that they are happy with the system produced. In our story Smith had to work with Angela, the customer representative, to determine which additional requirement-items needed to be implemented. This resulted in the additional task:

Task 6: Talk to Angela and agree on additional requirements-items, fitting in the iteration, to make the system worth being operational.

The name of the alpha state supplies a hint about what needs to be achieved to reach a state. Team members can find out more by reading and understanding the alpha-state checklist. By going through the states one by one for each alpha, a team quickly becomes familiar with what is required to achieve each state. In this way the team learns about the kernel alphas at the same time as they determine their current state of development and their next target states.

Determine How to Get There with the Kernel

Smith and his team look at the next target states and agree that they need to establish some priorities. First, they need to have their way of working: working well; then the software system: usable; and finally requirements: addressed. The reason is simple; not having the way of working: working well would impede their attempts to get the software system: usable. In addition, they agree on the priority for the missing requirement-items necessary to achieve the requirements: addressed state.

Smith and his team next discuss what needs to be done to achieve these states, as shown in table 1. By going through the target alpha states, Smith is able to determine a set of objectives and tasks for the next iteration.

How the Kernel Helps in Planning Iterations

A good plan must be inclusive, meaning that it includes all essential items and covers the whole team. It must also be concrete, so it is actionable for the team. The team must also have a way to monitor its progress against the plan. The kernel helps you achieve this as follows:

Inclusive. The kernel alphas serve as reminders across the different dimensions of software development, helping create a plan that addresses all dimensions in a balanced way.

Concrete. The checklists for each alpha state hint at what you need to do in the iteration. The same checklists help determine your progress by making clear what you have done and comparing this with what you intended to do.

The Kernel in the Real World

Although the ideas presented here will be new to many of you, they have already been successfully applied in the real world by both industry and academia (see figure 7). In all cases the groups used the kernel and practices developed by Ivar Jacobson International.1,10 Early adopters of the kernel idea include:

• MunichRe, the world's leading reinsurance company, where a family of "collaboration models" has been assembled to cover the whole spectrum of software and application work. Four collaboration models—exploratory, standard, maintenance, and support—have been built on the same kernel from the same set of 12 practices.

• Fujitsu Services, where the Apt Toolkit has been built on top of an early version of the software-engineering kernel, including both agile and waterfall ways of working.1

• A major Japanese consumer electronics company, where the software processes have been defined on top of an early version of the kernel, helping teams apply new practices and manage an offshore development vendor.

• KPN, where a kernel-based process was adopted by more than 300 projects across 13 programs as part of a move to iterative development. The kernel also provided the basis for a new results-focused QA process, which could be applied to all projects regardless of the method or practices used.

• A major UK government department, where a kernel-based agile toolset was introduced to enable disciplined agility and the tracking of project progress and health in a practice-independent fashion.

The kernel is already being used in first- and second-year software-engineering courses at KTH Royal Institute of Technology in Sweden. After students in the first-year courses conducted their projects, they went through the SEMAT alphas and matched them to their project results, under the direction of Anders Sjögren. The students had the opportunity to acquaint themselves with and evaluate the alphas and gain insight into the project's progress and health. In the second-year courses, run by Mira Kajko-Mattsson, the students were asked to use the SEMAT kernel when running their projects along with the development method they followed. Kajko-Mattsson created a software-development scenario and evaluated it for each alpha, its states, and the state checklist items. The students were then asked to do the same when conducting and evaluating their projects.

The experiences of these courses provided valuable lessons. For example, the kernel assures that all the essential aspects of software engineering are considered in a project. By matching the project results against the kernel alphas, the students could easily identify the good and bad sides of their development methods. The kernel also prepared students for future software-engineering endeavors with minimal teaching effort. By following all the kernel alphas, the students could learn the total scope of the software-engineering endeavor and thereby see what would be required of them in their future as professionals.

How the Kernel Relates to Agile and Others

The kernel can be used with all the popular management and technical practices, including Scrum, Kanban, risk-driven iterative, waterfall, use-case-driven development, acceptance-test-driven development, continuous integration, and test-driven development. It will help teams embarking on the development of new and innovative software products and those enhancing and maintaining established software products. It will help all sizes of teams, from one-man bands to 1,000-strong software-engineering programs.

For example, the kernel supports the values of the Agile Manifesto. With its focus on checklists and results, and its inherent practice independence, it values individuals and interactions over processes and tools. With its focus on the needs of professional software-development teams, it values the way of working and fulfilling team responsibilities over methods.

The kernel doesn't in any way compete with existing methods, be they agile or anything else. On the contrary, the kernel is agnostic to a team's chosen method. Even if a team is already using a particular method, the kernel can still help. Regardless of the method used, as Robert Martin pointed out in his foreword to The Essence of Software Engineering, projects—even agile ones—can get out of kilter, and when they do, teams need to know more. This is where the real value of the kernel lies. It can guide a team in the actions they need to take to get back on course, to extend their method, or to address a critical gap in their way of working. It focuses on the needs of the software professional and values the "use of methods" over "the description of method definitions" (the normal priority in the past).

The kernel doesn't just support modern best practices; it also recognizes that a vast amount of software is already developed and needs to be maintained. It will live for decades and will have to be maintained efficiently. This means the way you work with this software will have to evolve alongside the software itself. New practices will need to be introduced in a way that complements the ones already in use. The kernel provides the mechanisms to migrate legacy methods from monolithic waterfall approaches to more modern agile ones and beyond, in an evolutionary way. It allows you to change your legacy methods practice-by-practice, while maintaining and improving the teams' ability to deliver.

How the Kernel Will Help You

Use of the kernel has many benefits for experienced or aspiring software professionals, and for the teams they work in. For example, it helps you assess the progress and health of software-development endeavors, evaluate current practices, and improve your way of working. It also helps you improve communication, move more easily between teams, and adopt new ideas. It will help the industry as a whole by improving interoperability among teams, suppliers, and development organizations.

By providing a practice-independent foundation for the definition of software methods, the kernel also has the power to completely transform the ways that methods are defined and practices are shared. For example, by allowing teams to mix and match practices from different sources to build and improve their way of working, the kernel addresses two of the key methodological problems facing the industry:

• Teams are no longer trapped by their methods; they can continuously improve their way of working by adding or removing practices when the situation demands.

• Methodologists no longer need to waste time describing complete methods; they can easily describe their new ideas in a concise and reusable way.

Finally the kernel benefits academia. The kernel provides a basis for the creation of foundation courses in software engineering that can then be complemented with additional courses in specific practices—either as part of the initial educational curriculum or later, during the student's professional career. Equally important is the kernel's ability to act as a shared reference model and enabler for further research and experimentation.


1. Azoff, M. 2011. Apt Methods and Tools, Fujitsu. Ovum Technology Report, Reference Code O100032-002 (January).

2. Fujitsu, Ivar Jacobson International AB, Model Driven Solutions. 2012. Essence—kernel and language for software engineering. Initial submission, version 1.0.

3. Jacobson I., Meyer B. 2009. Methods need theory. Dr. Dobb's Journal.

4. Jacobson I., Meyer B., Soley R. 2009. Call for action: the SEMAT initiative. Dr. Dobb's Journal.

5. Jacobson I., Meyer B., Soley R. 2009. The SEMAT vision statement.

6. Jacobson I., Pan-Wei Ng, McMahon P., Spence I., Lidman S. 2013. The Essence of Software Engineering—Applying the SEMAT Kernel. Addison-Wesley. (Forthcoming in January 2013 but available in a prepublication version on safaribooksonline.com.)

7. Jacobson I., Pan-Wei Ng, Spence I. 2007. Enough of process—let's do practices. Journal of Object Technology 6(6): 41-67.

8. Jacobson I., Spence I. 2009. Why we need a theory for software engineering. Dr. Dobb's Journal.

9. OMG (Object Management Group). 2012. Request for Proposal (RFP). A foundation for the Agile creation and enactment of software engineering methods.

10. Pan-Wei Ng, Magee M. 2010. Lightweight application lifecycle management using state cards. Agile Journal (October).


[email protected]

Dr. Ivar Jacobson, the chairman of Ivar Jacobson International, is a father of components and component architecture, use cases, the Unified Modeling Language, and the Rational Unified Process. He has contributed to modern business modeling and aspect-oriented software development. He is an international honorary advisor at Peking University, Beijing, and an holds an honorary doctorate from San Martin de Porres University, Peru.

Dr. Pan-Wei Ng coaches large-scale systems development involving many millions of lines of code and hundreds of people per release, helping them transition to a lean and agile way of working, not forgetting to improve their code and architecture and to test through use cases and aspects. He is the coauthor, with Ivar Jacobson, of Aspect-oriented Software Development with Use Cases. He believes in making things tangible and practical and has been an active contributor to ideas behind the kernel, including the use of state cards.

Paul McMahon ([email protected]) is an independent consultant focusing on coaching project managers, team leaders, and software professionals in the practical use of lean and agile techniques in constrained environments. He is a Certified ScrumMaster and a Certified Lean Six Sigma Black Belt. He has been a leader in the SEMAT initiative since its inception. He has published more than 40 articles on software development and is the author of two books.

Ian Spence is CTO at Ivar Jacobson International and the team leader for the development of the SEMAT kernel. An experienced coach, he has introduced hundreds of projects to iterative and agile practices. He has also led numerous successful large-scale transformation projects working with development organizations of up to 5,000 people. His current interests are agile for large projects, agile outsourcing, and driving sustainable change with agile measurements.

Svante Lidman, with 25 years in the industry, has extensive experience building high-performance enterprise software-development teams. He has held positions as development manager, program manager, project leader, consultant, and trainer at Hansoft AB, Ivar Jacobson International, Microsoft, Rational Software, Objectory, and other companies. For the past five years he has specialized in lean/agile adoption. Starting in mid-2010 Lidman, was the leading change agent in the largest lean/agile transition ever carried out in Scandinavia.

© 2012 ACM 1542-7730/11/1000 $10.00


Originally published in Queue vol. 10, no. 10
see this item in the ACM Digital Library



Nicole Forsgren, Mik Kersten - DevOps Metrics
Your biggest mistake might be collecting the wrong data.

Alvaro Videla - Metaphors We Compute By
Code is a story that explains how to solve a particular problem.

Ivar Jacobson, Ian Spence, Pan-Wei Ng - Is There a Single Method for the Internet of Things?
Essence can keep software development for the IoT from becoming unwieldy.

Ivar Jacobson, Ian Spence, Ed Seidewitz - Industrial Scale Agile - from Craft to Engineering
Essence is instrumental in moving software development toward a true engineering discipline.


(newest first)

Hugh Ching | Thu, 11 Jun 2015 12:03:11 UTC

Post-science proposes the Requirement of Permanence as a discipline for software. Post-science has satisfied the Requirement of Permanence with the solution to completely automated software (Hugh Ching Completely Automated and Self-generating Software System Pat. No. 5,485,601). Software becomes permanent with self-generation, auto-updating, and auto-documentation. Today, the bulk of the software budget is for updating software manually, for sooner or later all software will have to be updated to new systems.

Pan-Wei Ng | Tue, 12 Feb 2013 06:11:45 UTC

This comment is a response to Kevin Kautz's comment on scalability.

Thanks for your interest in the kernel.

This article is just an introduction to the kernel and we have limited ourselves to explain one possible use of the kernel alphas. There are in fact many other uses, which is explained in our book  The Essence of Software Development: Applying the SEMAT Kernel. This article summarizes basically Part I and II of the book. In Part III of the book, we go beyond just doing an iteration, but instead demonstrate how development progresses through various decision points (which can be described as a set of alpha states) from idea to product. These decision points are part and parcel of an enterprises development lifecycle model.

We have Part IV of the book dedicated to discuss different dimensions of scaling: (a) when going beyond small teams to large teams who have members with different background and experiences (b) an enterprise with different kinds of development, such as in-house, offshore, etc. (c) when a single project is large and involves many teams collaborating with each other, such as a large scale product line organization.

In short, it is possible to (i) describe a development lifecycle using alpha states, and (ii) describe a teams emphasis (as part of a much larger team) in terms of alpha states.

Of course, the kernel does not have everything. It is just a kernel, but it is extensible. Through practices (described using the kernel), you can add more details specific to your organization and development context.

David Allen | Fri, 08 Feb 2013 13:14:55 UTC

@Ben Bovee, I am still new to the SEMAT work, though I've been watching it for some time. Regarding your comment "How well could it realistically both enable educational curriculum development and industry practice?"

Thinking back to my educations, here is how I would like to see it advance the education of software engineering. Before the Kernel, professors might choose an established method or two to teach. A creative instructor might have students compare and contrast them to discern the essence of software engineering. With the Kernel, we now have an explicit, method-agnostic language to describe the essence of software engineering. And we have a well-designed framework to compare and contrast methods.

Since I am in industry, my foremost motivation for studying the SEMAT Kernel is to find language to bridge the gap between me and my colleagues who share the same goals but come from different backgrounds (Scrum vs Lean vs RUP vs Waterfall). I intuitively know that we have more in common than appears on the surface. And I want to help us work better together without requiring one or the other to discard what they know and conform to the others language, though some compromise and adjustment may indeed be necessary.

Ben Bovee | Wed, 06 Feb 2013 13:41:26 UTC

About the SEMAT Kernel--details of which were new to me before reading this article:

1 I like some things: a. Forward-thinking; b. Built around perceived pandemic issues subject to relative whim; c. Open to accepting/fostering new ideas; and d. The cards provide a portable common reference.

2 I am unsure about some things: a. Could some card terms be correlated to others commonly used (e.g., Storming, Forming, Norming, Documented, Institutionalized)?; b. Could the "Selected Next States" indicate a level of Capability Maturity?; c. Are the cards intended to provide all necessary and sufficient criteria?; d. How could it be used by businesses developing and operating in time-boxes?; and e. How well could it realistically both enable educational curriculum development and industry practice?

3 I would like to see some things: a. "Further Reading" on--or at least documented--related to each card; b. Whether--and if so, how--it could be applied to non-SW Dev projects (e.g., EA); and c. Documentation of how the Kernel maps to other SW Dev & Engineering Life Cycle methods.

Paul E. McMahon | Mon, 04 Feb 2013 14:07:09 UTC

This comment is a response to Skip Pletcher's comment. Hi Skip. Sorry for taking so long to respond to your comment, but I just recently became aware of this site. Let me answer your excellent question.

First, yes -- all the Alpha states are positive, but that doesn't mean we don't recognize that on real endeavors we often face, as you say, "conflicting" situations, or situations that cause us to "revert". For example, an endeavor could start out using an agile approach and assess their Way of Working as having reached the Principles Established state. Then some new personnel are added to the project, and the new people know nothing about agile and want to use their traditional waterfall process.

What happens here is that when we assess the state again (and we do need to be reassessing our endeavor's progress and health at regular intervals) we do in fact revert to a previous state. The point is--yes--you can revert back to a previous state, or even revert to the point where you are just trying to get to the first state. In other words, you can reach a state, and then at a later point because the conditions on your endeavor change, you find yourself no longer meeting the checklist criteria for that state. So you don't always move forward in a strict linear fashion through the states.

We have found that many people when they are first exposed to the SEMAT kernel misinterpret the states as requiring a waterfall sequential approach. This is not at all the case. Not only can you revert to a previous state at any point in your project based on the current situation, you may also find that you need to iterate through the states of a given Alpha many times on long, or short cycles, depending on your chosen life cycle and practices. Keep in mind that the SEMAT approach is agnostic to life cycle, practice and method choices.

I hope this response is helpful to you, and we look forward to hearing any further feedbacks or thoughts you might have.

Paul E. McMahon Co-Author: "The Essence of Software Engineering: Applying the SEMAT Kernel"

Kevin Kautz | Mon, 24 Dec 2012 01:20:34 UTC

Solid article and the kernel concepts are strong. On scalability, however, I question the fit to large enterprises where risk-based financial decisions on project portfolios drive project funding. This has always been a weakness of Agile -- not that it conflicts, but simply that it ignores it. Can we as an industry ever learn to expand the Customer layer to include the ability of a stakeholder to procure funding to pursue an opportunity? Requirements and estimates of team and work and system are engaged prior to funding commitment, and beyond these, we also need to quantify the unknowns so that the risk can be expressed in dollars with confidence levels ... before funding happens. Yes, I know this is very waterfall ... but this is reality in all publicly owned enterprises and in many private ones.

Better Yet | Thu, 15 Nov 2012 03:35:01 UTC

Wonderful model, expertly written. The entire article, as great as it is, points up the flaw that software development is presently stymied which is why intellectual property theft in the industry is high. New and better software must throw the rules & reasons out the window - all the rules & reasons expertly written in this article. Need I mention the development of color monitors was by those who had no respect, perhaps knowledge, of rules & reasons.

Skip Pletcher | Fri, 26 Oct 2012 15:54:45 UTC

Alpha states seem to be all positive. What if the actual state of Way of Working is 'Conflicted' or 'Reverting?' In other words, we mix waterfall and agile practictioners but they do not blend well. That doesn't sound like Principles Established because they haven't yet acieved that state -- and may revert to this condition even after In Use doesn't get the results expected.

Consider the Requirements Alpha state described as "Requirements are obtuse and conflicting. Specific goals of the project are in direct conflict with one another while generic goals are not yet coherent." We've all been in projects which experienced such a state, but doesn't seem to match Conceived because the Clear opportunity clause doesn't exist. Further, in an UP Inception phase, it may very well be that just such a state is recognized and the project wisely killed. We had an initial small team, they looked at what was being asked and decided that it lacked enough clarity to implement -- so we never achieved Conceived state.

See what I'm asking? CMMI provides a Capability Level of 0, which is just a placeholder for no real capability. Might there be a similar grounding for Alpha states? Or are those examples considered exceptional states which would violate the defined bounds of software engineering? In other words, under those conditions we really aren't engineering anything because we lack the necessary minimal preconditions to do so.

Leave this field empty

Post a Comment:

© 2018 ACM, Inc. All Rights Reserved.