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, deal…
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 / firstname.lastname@example.org
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.
Tweet at @mithareraghav with #agilecoaching #SGBLR
I’m speaking at Global Scrum Gathering Bengaluru, 27-29 June 2016. #SGBLR
Happiness is something that all of us seek. There are various definitions of happiness but deep inside all of us know the moments when we feel truly happy within.
Personally for me “happiness” comes as #1 priority and it ranks even before health and wealth. Recently I read a quote that I completely resonate with
“Happiness is success, success is happiness “
Dimensions of happiness
We engage in many activities in order to be happy. Below are the activities we engage in to be happy.
Happiness = function of ( P, E, M)
Now let’s look at each of these components.
#1 P stands for Pleasure
There are many activities that give us instant gratification and give happiness, we can call them as pleasure and happiness. For example
- Watching football
- Listening to music
- Eating our favourite dish
There are many actions we do to be happy. These include habits like smoking, internet surfing etc. Such actions that involve “instant gratification” give happiness. But the problems is, at the end of the activity we feel like “I want more”. However when we repeat the activity, we notice that the level of happiness comes down drastically and at one point it even stops giving any happiness.
Another issue with activities that gives us instant gratification is they are addictive and at some point the activities become mechanical.
#2 E Stands for Engagement
When you are completely involved in these kind of activities, they also give happiness. The level of happiness is more than the activities involving pleasure.
- Playing football than watching football
- Playing a musical instrument than listening to music
- Preparing a dish for family and friends than eating your favourite dish
In these activities you are completely involved, and there is some sense of accomplishment. You are in a state of “Flow” – It is a state of total absorption in an activity where the individual is so focused that nothing else seems to matter.
Compared to “pleasure” the activities involving “engagement” are longer in duration.
(please refer excellent work done by Mihaly Csikszentmihalay – FLOW)
The optimal engagement comes when your ability and the challenge is optimal. When the challenge is bigger than your ability to do the activity then you experience some stress/fear whereas when your ability is more than the challenge then you experience boredom.
The problem with “Engagements” is it involves lot of time and requires initial investment. To enjoy playing guitar or violin you should invest your time in learning the instrument, then practice playing the instrument. You need to have certain level of skill to experience the “FLOW”.
So far we covered pleasure (p) , and engagement (e). The next aspect of happiness is activities involving meaning.
#3 M stands for meaning
Meaning involves engaging in activities with a purpose – a purpose bigger than self and caring about others. When you are involved in these kind of activities your level of happiness is not only higher but is also long lasting.
Prof. Selgman (https://en.wikipedia.org/wiki/Martin_Seligman) authority on positive psychology reportedly conducted this experiment with his students. One day instead of his regular class he took them to a movie and when they came back he asked them to rate on a scale of 1-5, the level of happiness they felt. All students rated whatever they felt.
Next week again instead of his regular class he took them to a near by community school where kids from underprivileged background were studying. They spent the afternoon playing with these kids. Again when they returned to college he asked them to rate on a scale of 1-5, the level of happiness they felt. He collected the data.
After six months towards the end of the semester, he handed over two forms, one was titled “Movie” and the other was “Visit to community school” and he asked the students to rate the current level of happiness with respect to these two events. Many of the students had forgotten that they had gone for a movie but everyone remembered the visit to the school. The ratings after six months for “Visit to community school” were much higher than the that for a “Movie”
The activities involving meaning will not only give higher level of happiness but it is also long lasting.
I can share from my own personal experience. We run a trust called Kruti( www.mykruti.com ) and couple of years back we did a photography workshop for kids from lower income group families .I still have beautiful memories about it.
Even after so many years, when I see the Kruti videos, I feel very joyful remembering the time spent with kids and their unconditional love, editing the videos, selecting the music and compiling the movie etc.
We can see that when we engage in activities that give us meaning and engagement automatically our level of happiness goes up.
Let’s be happy !
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.
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)
- 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 w.r.to 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 email@example.com or +44 78216 45866
Session Image courtesy : Learning Connexions Twitter Feed (@lconnexions)
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,
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 firstname.lastname@example.org or +44 78216 45866