Iso Iec 24744

[Lorna Schildt]

Inother words, ISO/IEC 24744 provides an agreed-upon set of words (a vocabulary), plus their corresponding meanings (their semantics), that can be used to describe methodologies used to develop software, hardware and other similar products.

From a technical viewpoint, ISO/IEC 24744 is based on the principles of method engineering and departs from the strict modelling paradigm sponsored by the Object Management Group, using instead an extension of the object-oriented approach that incorporates powertype patterns and clabjects.

Development methodologies may be described in the context of an underpinning metamodel, but the precise mechanisms that permit them to be defined in terms of their metamodels are usually difficult to explain and do not cover all needs. For example, it is difficult to devise a practice that allows the definition of properties of the elements that compose the methodology and, at the same time, of the entities (such as work products) created when the methodology is applied. ISO/IEC 24744:2007 introduces the Software Engineering Metamodel for Development Methodologies (SEMDM), a comprehensive metamodel that makes use of a new approach to defining methodologies based on the concept of powertype. The aim of SEMDM is to define methodologies in information-based domains, i.e. areas characterized by their intensive reliance on information management and processing, such as software, business or systems engineering. The SEMDM combines key advantages of other metamodelling approaches with none of their known drawbacks, allowing the seamless integration of process, modelling and people aspects of methodologies. Examples are given where other metamodels are mapped to SEMDM and a brief synopsis of problems is provided.

Various methodologies are defined, used, or implied by a growing number of standards, and it is desirable that the concepts used by each methodology be harmonized. A vehicle for harmonization is the SEMDM. Conformance to this metamodel will ensure a consistent approach to defining each methodology with consistent concepts and terminology.

Almost done!

You are only one step away from joining the ISO subscriber list. Please confirm your subscription by clicking on the email we've just sent to you. You will not be registered until you confirm your subscription. If you can't find the email, kindly check your spam folder and/or the promotions tab (if you use Gmail).

I know this is going to be contentious, but I'm hoping to stir some real discussion on this.

We Scrum trainers and practitioners regularly use the line that Scrum is "Not a methodology", it's a framework.

Leave aside for a moment that these things aren't mutually exclusive, I often find the justification for this argument is based on a misunderstanding of what a methodology is.

a methodology is "a contextual framework for research, a coherent and logical scheme based on views, beliefs, and values, that guides the choices researchers [or other users] make"

further: "This is a quantitative approach influenced through the philosophy of empiricism that posits knowledge (see epistemology) can only be obtained through direct, verifiable observations"

To me, this sounds an awful lot like Scrum. Not an explicit set of steps, but a quantitative approach based on empiricism, that guides our choices based on a scheme of values.

Is it possible that we've used the term methodology incorrectly in the past to describe more rigid, waterfall type approaches, and we're now afraid of that word?

Is it possible that Scrum is in fact a methodology, and we actually need to be better at explaining what that means, instead of calling people out when they use the word 'methodology'?

Or am I completely wrong, am I missing something?

Interested to hear your thoughts.

I'm not sure where your definition of "methodology" came from, but it's not one that I'm familiar with. When I'm talking about software product development methodologies, there are two definitions that I'm familiar with:

If I had to guess, I'd probably say that the PMI folks would consider Scrum to be a methodology, since it does define some practices and rules to help manage product development in a complex space. The ISO 24744 people probably wouldn't consider Scrum a methodology since it's incomplete and doesn't provide enough details into the specific process steps, how tools play into it, and all of the necessary work products.

Out of all of the words, "framework" makes the most sense to me to describe Scrum. Frameworks tend to be partially-complete structures that can be fleshed out and completed. In the software world, frameworks are also abstract and highly reusable in various contexts, with the details being used to specialize them for different contexts. All of this fits nicely with what Scrum is. It provides a few abstract roles, events and sequencing of events, and rules that different teams can plug different details into. There are many different ways to use Scrum and still "do Scrum" in accordance with the small number of rules.

Perhaps this is a big part of the problem. We seem to be a bit stuck in a hole that has been dug by waterfall software practitioners. The term is far older than software, and far broader than product delivery, and yet we seem only concerned with how it's been misused by waterfall software delivery methods of the last few decades.

I agree that framework is a good word, but something can be both a framework and a methodology.

So I guess the reason I'm asking the question is because we always seem to get defensive when we see the word methodology, but it feels to me like we're reacting to it's misuse, not the reality of the term.

For full transparency, at this time yesterday I would have said the same as you. It was only because I found myself ready to type out a defensive critique of someone describing an 'agile methodology' that I decided to take the step back and look into it, and believe I may have been wrong all these years.

I'm a bit less picky when it comes to "process", "methodology", "method", and "framework", but I do tend to use "framework" when something is incomplete and isn't prescriptive and words like "process" or "method" when there's a great deal of specificity - my implementation of Scrum is my process or method, which is likely to be different than your implementation of Scrum, but both are built on the same framework.

I will say that I do sometimes group Scrum in with "agile methodologies". My thinking there is that if you are using the Scrum framework as it was designed and intended, the end result should be a process or methodology that is consistent with the Manifesto for Agile Software Development. However, I do know that not everyone who claims to be using Scrum is using the framework as it was designed or intended, which leads to faux Agile or Dark Scrum or similar names for things that use Agile terms and concepts or appear to be Agile but are not.

Even on this forum, a few days ago, a respected member called me out publicly in what felt like an effort to shame me for referring to Scrum as a methodology. It is most unwelcoming, and might I even say, bullying.

The problem with the ISO/IEC 24744 definition is that it is for software engineering. Scrum makes it clear in no uncertain terms that it is not just for the software domain. It is more general and is cross-domain. So a more general definition must be used.

Most people use the dictionary to define words. Agile practitioners value simplicity, as the Manifesto says "simplicity... is essential." So why must we make things so complicated with something so fundamental?

Just look at the daily scrum. We state who can be there, we can state who can participate, we specify the strict conditions in which Scrum Masters or POs are allowed to speak, we describe the purpose of the Daily Scrum and we even time box it down to 15 short minutes.

Any rational person would say yes. Everyone in the broader software development community says 'yes.' Only die-hard Scrum Practitioners would argue that it doesn't. All while bullying, belittling and publicly shaming others who don't agree with them.

When I see Scrum people argue it's not a methodology, it's always a straw-man argument where they create a ridiculous definition of 'methodology' and then argue against it. Gunther Verheyen's linguistic gymnastics to create a definition that bares no resemblance to how any regular person would define a methodology is one of my favorites:

If you want to be accepted in the Scrum Community, you must unlearn the basic definitions of words. You must then accept new definitions that bare no resemblance to reality. And then you must shame others who do not comply with unlearning.

If I don't 'drink the Kool-Aid', will I get pushed out of the industry? I've already been told that nobody takes me seriously because of my unabashed use of the dictionary to define words. I've already been called out publicly.

But I've always believed in speaking truth to power. And courage is a Scrum value. The problem is, I use the dictionary definition of courage. Perhaps there's a different definition of courage that I should be using?

If we as practitioners can't be truthful and honest with ourselves about something as simple as the definition of the word 'methodology', then how can anyone trust us to guide a Scrum Team, coach others, be transparent?

If your first introduction to a team is to show them that you not only refuse to accept the universal definition of commonly used words, but that others must accept the redefining as well, what credibility do you have when it comes to commitment, courage, focus, openness and respect?

3a8082e126