I came across this word “Essence” through an article in Communications of the ACM, while I was on an assignment with Jaguar Land Rover (JLR) working with the electrified powertrain department (PT-66). The division had embarked on an ambitious project to develop an all electric luxury SUV, the iPACE.  The team was looking at ways to develop software in an agile way without compromising on the safety standards (IS0 26262/Functional Safety) within the given time. The article I stumbled upon was – The Essence of Software Engineering: The SEMAT Kernel (Jacobson et al.). The initial summary caught my attention and here are the key points mentioned (please note this article was published in Oct 2012)

  • 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; 

I think the software industry (now fashionably called the Tech industry still lacks the discipline that it needs in order to avoid the disasters caused by the malfunction of MCAS systems (a system fitted on the Boeing’s 737 MAX Aircraft that caused two major accidents – Article the Crash of Ethiopian Airlines Flight 302: Explained through Graphics’ 2021).

In JLR we were experimenting with introducing the concepts of “Agile” without using the word, to bring agility in the processes and in behaviours. I was looking for a mechanism for building a vocabulary and possibly an ontology (wiki -an ontology is a way of showing the properties of a subject area and how they are related, by defining a set of concepts and categories that represent the subject.). Ontology is one of my favorite areas of study and research, which is actually derived from Philosophy. Which also means the study of being (Onto – Being, logy – Study).  I found that Essence is like a glue that can bind information science with philosophical constructs of ontology. I’m not an expert in  Essence and the SEMAT framework, in fact, I did not study the Essence in detail to avoid any influence on my own thinking. 

My thoughts about Essence are as follows when it is used in the context of transformation.

  1. Understand the essence of the organisation, the soul. That will be the core of Essence on which you can build the enterprise transformation framework.

The organizations should do a self-assessment of their true essence. That is mainly encapsulated in its “reason for existence” for that organization.  One can find it by asking – What, How, Who and Why for the “reason for existence” of the organization.

 In the journey of transformation, it should retain the ‘core’ while the rest all can change. In fact it should be taken care that the “core” is retained. 

Example: Many years back I worked with Infosys, in my view one of the core of that organisation was Meritocracy. Similarly, when I was at Wipro, it was around Integrity. In a real transformation journey, you have to do a detailed and much deeper assessment of it. 

  1. Taking Responsibility 

Organizations should stop looking at canned “Frameworks” and expensive consultants to solve their challenges. They can be used as a “catalyst” but not as solutions. Equally important is to take full responsibility for the outcome and not to put blame on the frameworks and consultants. 

Adhering to Simplicity 

The larger the organization the simpler the approach should be. Simpler does  not mean easy, nor does it mean a short cut or compromised solution. It should be based on a strong foundation, based on values and principles. 

Based on a Context

Context is decisive, it plays a vital role in any transformation. The approach to transformation should be contextual. The implementations might differ from one unit to another depending on the business need, geography and culture.  

The Basic Structure 

Basic constructs of Object Oriented Methods can be used to define a methods library. Most of the management approaches have roots in Taylors “Principles of Scientific Management”, while most of the approaches are not relevant, the core essence of that theory “ a scientific approach is better than the finest type of ordinary management”, is still valid.  The biggest gap in the current approaches to adopting various frameworks is not giving sufficient attention to the solid theoretical constructs. . 

The missing “piece” 

In most of the frameworks, the key missing piece is there is not enough guidance on the person (actor) performing that activity.  In the early days of process improvement, the focus was always on maximising efficiency. It was achieved by using advanced tools. In the current era of knowledge work the most important factor that determines the outcome is the person who is doing the work and his/her state being. 

In the knowledge work, the outcome is a function of 

Individual Outcome = Function of ( competence x  state of Being*) 


Competence = skill x knowledge x experience

Being (state of) = function current(behaviour x mindset x emotional state x bodily state x thought process) 

Sometimes a person may be energetic and can do more things while at other times the person might have some health and wellbeing challenges that might come in his/her performance. It is difficult to explain but easy to experience. For example – on a particular day, everything happens the way you thought it would happen and on top of that you also receive some unexpected gifts – you will feel good right? Then you might say, “ I’m happy now !” – at that time you are in a state of “being happy” in the same way if things have not gone as per your plan and you drop your coffee cup on the floor and break it, you will experience a sense of irritation, anger, and frustration. That can be called “being sad”.  Only human beings have the ability to identify and distinguish their “state of being” but you can accurately identify your own state of being. Our assessment of judging the state of being for others will not be accurate. 

“Being sad” is not the same as “Being frustrated” or “being helpless” or “ being irritated” 

The important point to note is “being” is a dynamic constant that takes various forms, that is the reason in eastern philosophy it dwells into the idea of your natural being or original being – as your essence. 


There is absolutely no need to come out with a new set of frameworks, methods every week. In the current world of social media the approaches that make a big noise get people’s attention. Most of the time, the method creators and/or the custodians have commercial interests, that is not wrong but it is not very explicit. The danger is, if we try to apply any of the frameworks without a proper understanding or without the right context it will not yield the desired results and also creates a bad reputation for the industry/profession itself.  

It is also understandable that everyone wants to contribute (with good intentions) but we should not forget that we are standing on the shoulders of the giants. Let’s not forget to acknowledge the work done by these giants. 


Jacobson, Ivar, Pan-Wei Ng, Paul McMahon, Ian Spence, and Svante Lidman. 2012. ‘The Essence of Software Engineering: The SEMAT Kernel: A Thinking Framework in the Form of an Actionable Kernel’. Queue 10 (10): 40–51.

‘Boeing’s 737 MAX Aircraft and the Crash of Ethiopian Airlines Flight 302: Explained through Graphics’. 2021. The Seattle Times. 10 March 2021.


SEMAT, Essence, “being” Agile

In my previous blog on retrospective, I mentioned that this year my focus will be on some exciting developments in the field of Software Engineering. Currently, the field of software development is led by the Agile software development, It has made sufficient contribution to the whole paradigm of software development. It has made it very clear that “…the sole purpose of software development is to develop software” though it might sound like a Zen koan(1), it is explicitly stated in one of the principles in Agile Manifesto – Working software is the primary measure of progress. The shift in focus from planning, estimating, contract negotiation, hardware, technology to delivering software has made a huge difference.

“…the sole purpose of software development is to develop software”

The last couple of years I have spent studying, practicing, studying, practicing, studying …..  various agile methods and the current state of agile development, there are many new developments happening but in my view, the current challenges faced in the industry can’t be solved by the direction in which agile development is heading. Maybe it is worthwhile to pause and connect the dots with some fundamentals and then build new solutions, frameworks, and methods.

In this article, I will introduce some interesting developments that I found useful. In the later articles, I will share more details about the work we are doing at ProcessWhirl about using behavioral economics, analytics, and Lean Product Development.


It stands for Software Engineering Method and Theory, the initiative was launched in December 2009 by Ivar Jacobson, Bertrand Meyer, and Richard Soley with a call for action statement and a vision statement.

The purpose of SEMAT is to bring the rigor of engineering discipline back into software development. If the project involves developing a driverless car or a health monitoring systems based on Artificial Intelligence (AI) it is important that failure modes are considered as part of the design, the boundary conditions, reliability and critical to quality (CTQ) parameters.

SEMAT can help in bridging the gap between current methods and theory.


The most interesting part that caught my attention while studying SEMAT was “Essence” – it is the kernel or a foundation on top which any method or framework can be expressed. Essence aims to find the common ground across various methods. It is based on three principles. it is actionable; it is extensible, and it is practical.

Essence aims to find the common ground across various methods.

The kernel provides a simple language to express methods and practice, in line with the three principles.

“being” and Agile

This is the topic close to my heart, exploring the world of being. I’m exploring the “being” part of “being Agile”

This takes me back to study of Ontology (I have written blogs and spoken at Global Scrum Gathering and in Capability Counts conference on this topic), It is a branch of philosophy(in particular meta-physics) focusing on study and nature of ‘being’, this term is also widely used in social science, computer science /artificial intelligence, information science and in many other fields.

The term is derived from Greek words, “Onto” for existence and “logia” for study, science. The Latin derivative ontologia means the science of being.

In general, ontology focuses on nature of ‘being’. For example, let’s consider an apple. The existence of apple can be experienced by sight, touch, smell, and taste. In an apple juice, though the form is changed the existence can be experienced in the form of smell and taste. The “essence” or the being of an apple can be experienced.

In the case of living beings the concept of “being” is different, especially for human beings. Human beings have a wide range of ‘beings’ in which they express themselves. Normally they are expressed as emotions like “being happy”, “being sad”, “being angry”, “being enthusiastic” and so on. The being is not just the emotional state but it is much more than that. It is a combination of mental state (attitude and state of mind), emotional state (feelings and emotions), bodily state (body sensation), thoughts and thought process (logic and memory) in a given moment of time or in a given situation.

This also includes mind-set (frame of reference) and worldview (model of reality).

In fact, one can’t write/read about “being” then it becomes “knowing”.


There is a work to be done to express all these ideas as well to study the existing methods and theory. The concept of common ground and Kernel is fundamental and fascinating, it helps to connect the dots with so many interesting topics.

This year also marks 50 years of Software Engineering, time to celebrate as well as take the developments further.

A proper understanding and complete knowledge will help in building effective solutions for businesses and for the society.

Finally, I will end this article with quote from Bhagavadgita(2)

” The impermanent has no reality, reality lies in the eternal. Those who have seen the boundary between these two have attained the end of all knowledge”

Further study



(1) Zen Koan

Koans (pronounced KO-ahns) are cryptic and paradoxical questions/ridles asked by Zen teachers that defy rational answers. Teachers often present koans in formal talks, or students may be challenged to “resolve” them in their meditation practice.

The above example can be framed like “What is the purpose of developing software? “

(2) Bhagavadgita – Eknath Eshwaran

Conference Slides

  1. CMMI and AGILE – Ontological Perspective – Capability Counts 2017, May 2017 VA, USA
  2. Ontological Constraints in coaching agile teams – Global Scrum Gathering, Jun 2016, Banaglore, India


Why do we have brakes?

As we were stepping out after our weekly 8D* meeting, Gireesh asked me “Raghav, Tell me why do cars have brakes?”, I responded with a smile “of course to stop the car.”

Gireesh, functional specialist, manager for the verification team, smart and good people’s manager,responded back with a smile “No, we have ‘brakes’ so that we can go fast !!”. I could sense the shift in my perspective. “Is it not true that brakes help us to drive faster?”

This is one of the reasons you should put a brake to your routine and spend time for retrospection,so that you can go faster.

In this blog I will share few points on personal retrospection. The personal retrospection is effective when it spread across few sessions but it is also important that it is done with some planning.

People in the Agile Community are familiar with the doing retrospection with teams. The following points might help you in your personal retrospection.

Step 1. Preparation

Block about 1–2 hours of your time.

Decide on a place that has less distraction and comfortable to sit and contemplate.

Have all your source of information including your phone, laptop, i-pad, Notebooks etc.

Supplies — Notepad, pens, Sharpies plus pack some light snacks/coffee/tea (optional).

Step 2. Making lists

List all the major events of the year.

Write down your accomplishments.

List of your failures.

List of down your incomplete/ work in progress initiatives.

List down people who helped you in your journey.

List down people who let you down.

List down your regrets.

Revisit your goals (if you have one).

Step 3: The process

Go through your lists in the following order.

First, take the List of failures and make note of lessons for the future. If you are feeling bad about the failure, this is the time to let it go. Feel good that at least you got a chance to try many people will not get that opportunity. Finally, failures are not the end but are intermediate milestones.

Next, take the list of “incomplete/ work in progress initiatives” — go one by one and decide the next action. It can be “drop the item” or noting down the next action required or mentioning a revisit required.

Next is to look at people related lists

“List of people who helped you in your journey” — Make a plan in your calendar either to send a thank you note or small gift or time to speak etc.

Next, it is important to look at the list of “people who let you down” — In this is list if there is any unresolved issue or incomplete communication set-up a time in your diary to complete the conversation. If you don’t want to do any of these simply you can forgive and let go any negative emotions that you carry.

Take a moment to wish well for all people on your list.

Then look at your list of regrets.

As you are going through the list ask yourself these two questions

“What I could have done?” — Note down your response.

“What I can do now?” — Note down your response. If there is something you can do now then note down the action in your diary.

Then look at your previous year’s goal and assess your performance, Make notes for your planning exercise (Don’t try to do both retrospective and planning together), make a summary of your retrospection.


Finally look at your accomplishments. Note down the motivation and factors that helped you to achieve these objectives. Make a plan to celebrate your achievements.

Step 4: Completion

Finally take moment absorb all your experience, complete the retrospection process.

Nature does not hurry, yet everything is accomplished. – Lao Tzu

Summary of my retrospection

Overall the year 2017 was good. In terms of experience it gave me lot of time to think and contemplate about my future direction. Made some good friends and connections. Read some extraordinary books !! It was a good year 2017.

Last few years I have spent enough time and money on acquiring new skills, experience and qualifications. Now it is time to put all these back into practice and help others to grow especially our team in ProcessWhirl.

I will continue to share and help people to grow. Personally, I will stop focusing more on “Agile” (not that I will stop working on any Agile assignments) but go beyond and focus on core software engineering.

I will do some research and experiments on SEMAT/Essance and also sharpen my coaching skills along with study of “Ontology” (“being”)/philosophy.

— — — — — — — — — — — — — — — — — — — — — — — — — — — —

* 8D : The eight disciplines (8D) model is a problem solving approach typically employed by quality engineers or other professionals and commonly used by the automotive industry.

Raghavendra (Raghav) Mithare, (

Consultant and coach at ProcessWhirl based in London.

How many colors are there in the rainbow?

How many colors are there in the rainbow?

Did the number seven come to your mind?  Think again and look at the image clearly, can you see it has millions of colors? Still, If you are not convinced,  you can validate this from the data of Spectrophotometer.  


Number seven is also not totally wrong, you can call them as seven primary predominant blocks of color. The seven primary colors are RED, ORANGE, YELLOW, GREEN, BLUE, INDIGO, VIOLET, and from these primary colors we can create millions of colors.

But, Why did the number seven come to your mind when you think of the rainbow?

The reason is due to the working of the brain. In order to processes, large amounts of data and information the brain simplifies the input and stores them as concepts. These concepts are linked by categories and patterns (in this case Colours is a concept and the primary colors are patterns).

This complex processing can be demonstrated as below.


Input :

Brain simplifies the representation of the complex world and stores as (mental) models

World    —————-> induction   ———-> Simplification

In the same way, the brain uses deduction to interpret the world using its models or simplifications.

Similarly, the reverse happens through deduction.



To interpret the world the brain converts the simplifications through deduction and creates a sense of reality.  

Simplifications ———> Deduction ———-> World

Your view of the world (Simplifications) is a constructed based on the context and the mental models, beliefs, and values.

The real world (Reality) is given (it exists as it is), it is complex, uncertain, unstable, and contains a vast amount of information and data. The brain balances/limits the amount of information that it can process.

But it is important to note that, you have a sense of the reality or your interpretation of the real world. Hence two people react differently to the same situation.

So all the Models are the simplification of the real world. It is an abstraction from the past and sometimes a base to build the future.A proper structure and a language will help in developing robust models and interpretation of the real world.

UML is a good example of a notation that helped in developing models and developing software systems. The whole concepts of Object Oriented Analysis and Design is a mechanism for simplification of the real world.

This understanding of models, simplification, and deduction helps in analyzing and implementing models and framework like CMMI, Scrum, SAFe or LeSS.  The initiatives sometimes don’t yield expected results due to our inability process these models and convert them into useful practices, structures for the organization.  

This phenomenon is elegantly summarized by statistician George Box

 “Essentially, all models are wrong, but some are useful”.

Some interesting links

All models are wrong

Raghavendra (Raghav) Mithare  –



Ontological constraints in coaching ‘Agile Teams’- Part 2

The workshop was well received during the Global Scrum Gathering in Bengaluru. One common question asked by many participants was the meaning of “Ontology”. Ontology is a branch of philosophy, dealing with study of the nature of being. Currently ontology based concepts are used in professional coaching and leadership development work.  (Harvard Professor Dr. Michael C. Jensen (his initiative EJI) , Prof Dave Logan of UCS author of Three Laws of Performance, have done significant research and contribution to this field).

The term ontology is also used in Computer/Information Science for formal naming and definition of the entities for a particular domain.

The presentation slides

The intention of the workshop is to give the participants a glimpse of “being” as an experience.  It is important to understand and know the difference between “doing” and “being”, since in any agile implementation “being agile” is more important than doing agile. If this distinction is not made very clear then all the agile practices will face the risk of ending up like rituals without significant outcomes.

During the sessions one key exercise is to identify the subtle differences in actions taken (doing), results obtained (having) and the experience (being). The importance that the language plays in differentiating the experience is also discussed.

In the later part of the workshop the key constraints which are natural to all human beings are discussed and demonstrated through games (Rocket Singh).

The best way to understand these concepts is to participate in one of the sessions and experience it.

For more details contact :  Raghavendra (Raghav) Mithare at +44 782 164 5866 /


Ontological constraints in coaching ‘Agile Teams’


I’m speaking at the upcoming Global Scrum Gathering in Bengaluru (27-29 Jun, 2016). In this article I will give some background about my 90 min workshop. The ‘ontological constraints’ is the topic close to my heart and I’m excited to share these concepts with all of you. These concepts are easy to understand but difficult to explain. I think these concepts have evolved along with the evolution of human beings. I find them very relevant in the context of Agile Software development which emphasis “interaction” among people.

Whenever there is an “interaction” among people these ontological constraints play a vital role in the overall outcome and experience of that transaction.

Let’s look at, what is Ontology?  Ontology is a branch of philosophy focusing on study and nature of ‘being’, now this term is also widely used in social science, computer science and in many other fields.

The term is derived from Greek words, “Onto” for existence and “logia” for study, science.

In general ontology focuses on the nature being for everything for example take an apple. The existence of apple can be seen, felt and can be tasted. In the context of managing Agile teams, I will be focusing on “way of being for people.”

To understand ‘the way of being’, pause for a moment.

Observe your mental state (attitude and state of mind), emotional state (feelings and emotions), bodily state (body sensation), thoughts and thought process (logic and memory). So your way of being is “what is going on with you internally in a given moment or in a given situation”


Once you experience the way of being, you can now look at the ontological constraints.

To look at the ontological constraints you need do a small exercise.

Write down or make mental note of the following question.

What kinds of people or kinds of situations you find uncomfortable to deal with?

Consider that there are some invisible ontological constraints are at play here.

Share your thoughts here or write to me at /

Tweet at @mithareraghav  with #agilecoaching #SGBLR

I’m speaking at Global Scrum Gathering Bengaluru, 27-29 June 2016.  #SGBLR

Architecture & Agility


Few weeks back I attended a wonderful session – Architecture & Agility:Married, Divorced or Just Good Friends? by Kevlin Henney. I was particularly interested in knowing  Kevlin’s view on scalability , extensibility of Architecture especially using Agile methodologies like Scrum.

Before you read further let me caution you that I’m not an expert in the field of  (software) “Architecture”.  My expertise is in facilitating adoption of best methods and techniques for developing great products and coaching teams. I have a seen very high co-relation between  great teams v/s architecture and Agility. In this article I’m sharing few notes I had made during the session and a question which I’m pondering upon about software architecture.

Learning Connexions

Kelvin’s session started with many quotes and definitions of Architecture and their limitations and interconnectedness.  He shared the various views people have expressed to define architecture.

I personally use the definition provided by ANSI/IEEE , which states – Architecture is defined by the recommended practice as the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.

Kevlin spoke about all the points – components, relationships, environment, principles and subsequent design and evolution with appropriate example and quotes.

He made it very clear that (irrespective of the various definitions used)

Architecture is

  • central to your software system
  • it has to be represented (Abstraction)
  • it has to be implemented (code!)

In my own experience over the years, I have noticed that different levels of importance is given to “Architecture” in Software Development efforts.  I have seen huge shift in the activities related to defining architecture.

In the pre Agile era, in many organisations small group of people created huge set of design documents and they called it Architecture and very few created models by using tools.  Also few teams sometimes created additional documents to meet their internal policies , procedures or contractual obligations/milestones with lot of resistance!.

In the current Agile era, surprisingly, teams are not too keen to spend lot of time on  solution architecture. They are busy rolling out features every sprint and resolve architectural challenges as and when they encounter it.

In both pre-Agile era and Agile era( i.e. now), wherever the team is good and have at least one or two people with an “Architectural” mind set, the solutions have evolved exceedingly well.

Kevlin made it very clear that our architecture (Representation) and code base (implementation) are not different.  He made us look at the Twelve Agile Principles – “Architecture and Agility” are embedded in each of these principles.

Final point from Kevin’s talk was that -it is NOT about being rigid architecture.  It is not about saying – “this is it”. It is about being open to changes.

On my way back I was thinking about numerous interesting quotes and examples shared during the session. I saw the beautiful tower of the Shard* and  I stood admiring it’s beauty when a thought came to my mind.  Before the tower was built, lot of work might have gone in defining the architecture. Then there was the labour of constructing the structure and finally the building has come into existence. What is the force that binds and continues to hold all these elements together? In the case of Shard it is “Gravity” that is holding it together. So all architectural decisions are based on it. In case of Software Systems – what would be the equivalent of  “Gravity”? Unlike Shard our systems continually evolve. They are not static, standalone systems. Are the set of all “Customer Requirements” the “Gravity” that holds our Software systems? or is it something else? I don’t know but it will be a good question to ponder on.


Raghavendra (Raghav) Mithare is a professional coach and a scrum master, regional head for ProcessWhirl based out of London. Feel free to share your opinions, comments and feedback. You can reach him or +44 78216 45866

 Session Image courtesy : Learning Connexions Twitter Feed (@lconnexions)

Three pitfalls

2.LinkedIN Image Tempale

As I was undergoing my training to become a coach, I had the privilege of working with a wonderful coach.

One day when I was sharing with him that I was feeling a little low, he shared something that made a difference to me .

What he revealed to me was this –

Consider whenever you are in a bad mood or feeling low, you are most likely to be trapped in one of the below three pitfalls.

The three pitfalls,

#1. Comparing

#2. Complaining

#3. Competing 

The first pit fall is you are “comparing” with others, or your current situation with past situations or with some expectations. 

Majority of the times you keep comparing yourself with others – in schools it was the other guy/gal who got the better grades and today it may be a friend who is in a better position in terms of role, income or recognition. Look and see if you are trapped in some kind of comparison.

The second pitfall is “complaining”. You may be upset because of some unfulfilled expectations. It can be from people, systems and processes around you, society, current state of affairs, traffic, pollution, environment, global warming, etc. etc..

When you are in a complaining mode you are in trapped in the second pitfall.

And the last pitfall is you are trying to compete with others and you want to be ahead at times. When you are not ahead you feel a sense of losing. If it is healthy competition it is fine, but this is about the competition that drains your energy.

As a human being these are our natural pitfalls. But being aware of these help us to come back to our normal self.

As such these are not bad things but you need to be aware when the above feelings are not leaving you empowered.

Comparing is good when you are planning your next goal for development. It is good to look around, compare and then set your goal, and create a plan to accomplish it. But there is no point comparing every day.

Complaining is required to bring any unresolved issue to the attention of relevant authorities.  For instance, if the street lights are not working or if you have lost your baggage it is good and sometimes necessary to complain to the relevant authorities.

Competition is good as long it is healthy and you are growing.  A competition with your own self can be very beneficial.  

Hence while comparing, Complaining and Competition can be healthy, it is important to be aware about your own self and ensure that you don’t fall into the pitfalls of these emotions.

 Hope it helps you as well.

Raghavendra (Raghav) Mithare is a professional coach and a scrum master, based out of London. Feel free to share your opinions, comments and feedback. You can reach him at or +44 78216 45866