In the agile world, there are framework practices, e.g., iteration planning, daily stand-ups, retrospectives. There are engineering practices such as continuous integration, pair programming, collective code ownership etc. These are highly emphasized. There is also a focus on framework related values, e.g., the Scrum framework has values such as commitment, courage, focus, openness and respect.
There are also many soft practices that a team can follow and these soft practices can be quite useful for the team members. Software development or for that matter any development work, is primarily a human collaborative effort. At the end of the day, the software is built by people. Collaboration happens among people. It’s people and only people who are capable of reflection and taking actions. Soft practices help team members work with each other energetically, and positively over a sustained period of time.
In this piece, I’ll outline one such soft practice – Naikan. I believe many of you would be hearing this term for this first time, particularly in the context of Agile.
What is Naikan
Naikan is a Japanese practice and loosely translated means “inside view” or “inside looking”.
No one in this world could accomplish anything without the support of others. In our everyday lives, we need support from many individuals, groups and even inanimate objects. With this awareness, we realize that we impact others and we are also impacted by the world around us.
Two Examples
Take a simple example of a developer cutting code and checking into the repository in a team of generalizing specialists such as testers, deployers, integration members, project manager, product owner etc. Can the developer check-in the code if the branching is not available? Can he or she check-in without doing the needed testing? Can the developer work on it without having other dependent files being available (otherwise it may break the subsequent build)?
So, for a very simple work of code check-in, the developer needs support from other team members. Isn’t it?
Another example - your early morning chores. All of us can easily relate to it. The water tap, the water itself flowing in, the tooth-brush, toothpaste – all of these are created or provided by someone. Without this support, you can no way do the morning chores properly.
Naikan asks such questions in a simple way and it works as a constant reminder system for us. It constantly reminds us that in this world whatever we do, we are dependent on others. These can be seen or unseen hands, known or unknown actors, animate or inanimate objects. Hence, the practice of Naikan asks ourselves to see things from the world’s perspectives instead of solely our own.
Three Questions in Naikan
In Naikan, three simple questions are asked:
- What have I received from _______?
- What have I given to _______?
- What troubles and difficulties have I caused _______?
The area to be filled up above, i.e., “_______” can be a person, community, group, team, an organization, a country or the entire world.
As Scrum or Kanban or any Agile development framework are team-based approaches, you can reword these questions slightly. Then the questions are:
- What have I received from the team?
- What have I given to the team?
- What troubles and difficulties have I caused the team?
As you can see, these questions not only ask what you have received, but what you have also given. It does not seek what troubles or difficulties are caused by others to you, rather what difficulties you have caused to others. This in turn asks you to think from the others' perspective - in this case your team's perspective.
In essence, like Naikan asks us to see ourselves from the world’s perspective instead of our own, the agile soft practice of Naikan asks us to see ourselves from the team’s perspective, instead of only our own.
Naikan is Action Oriented
Naikan, as defined earlier, is mainly about self-reflection with the 3 questions, but it’s also action-oriented. How?
Think about our first example of a developer working on a piece of code. When the developer is practicing Naikan, what are the chances you will see conflicts happening, when:
- A broken build happens and hence the developer can’t work on the latest.
- A database schema, which is not supporting the object model.
- A fresh co-developer, who mistakenly checked-in a non-compiled piece of code, or
- Finger pointing when things don’t go right.
As you would have realized by this time, it’s expected to be quite less. The developer knows that there are so many things happening for him or her by others. Hence, the developer won’t get into any conflict, but will be more of a collaborative nature to fix the build, to counsel the fresh engineer on the utility of compiled code, and to work with others, instead of finger pointing.
Remember, I mentioned earlier that Naikan is a constant reminder system and it asks to look at the world in relationship with others, not solely from own interest.
Where Naikan Can be Used?
Looking at the above three questions in Naikan, one would immediately relate it to the three questions asked in daily stand-ups (or daily scrum). These are put in its simplest form.
- What I did yesterday?
- What am I planning to do today?
- What are the impediments?
But the questions in daily stand-up and Naikan are not the same. Revisit these questions to see the differences and reflect upon them!
However, the team can use the practice of Naikan while doing daily stand-ups, i.e., the team members have the self-reflecting practice of Naikan built-in, as the questions are put forth during daily stand-ups.
The best use of Naikan actually can happen in various retrospectives and intraspectives.
Use in Retrospectives
In a recent article on retrospectives and intraspectives (link), I defined retrospective as:
“A recurring workshop in which the team looks back on their work over a period, reflects upon it, and learns. The team applies this learning in future work to improve people, processes, and products.”
In the above article on retrospectives, I’ve mentioned various stages and various techniques that can be applied. The practice of Naikan can be built-across the fabric of retrospectives, i.e., before starting a retrospective, the team members can have these reflecting questions as a start.
Tip: As a starting point, you can use the 3 questions of Naikan along with the Norman Kerth directive when the retrospective session begins.
This improves the spirit of discussion. Also, as Naikan helps in self-propelling actions, it gels well with retrospective, which is also action oriented.
Use in Intraspectives
In the above article for retrospectives, intraspective has been defined as:
“An inspection or reflection for the team, within an iteration.”
Again, while doing intraspectives, Naikan can work as a reminder system for every team member when the practice is well-established.
You may think Intraspective and Naikan are same. However, there are two key distinctions:
- Intraspective is for the entire team, whereas Naikan is for you in the perspective of the team.
- Intraspective happens within an iteration, whereas Naikan is a constant reminder throughout the retrospective or intraspective or Sprint or even the entire project.
Final Words
I came to know about Naikan sometime in 2014/2015 and liked the simplicity of it. I also found it to be effective. You can expect the following with the practice of Naikan:
- Asks you to think again, before taking an action.
- Keeps your stress low.
- Will stir positive emotions on what you have received.
(Because we usually receive more from the world than we give it back.) - Compels you to call or meet people if things don’t go exactly as expected and there is friction.
- Makes you thankful to the world to have a life and breathe another day.
Try Naikan for a few iterations or few releases and you can see the results. And because Naikan has just 3 questions, it is simple and can be easily remembered.
Also, as I noted earlier, it’s a practice and because it is a practice, the more you work on it, the better you get at it.
References:
[1] The Art of Taking Action: Lessons from Japanese Psychology, by Gregg Krech
[2] Article - Retrospectives and Intraspectives for Agile Practitioners, by Satya Narayan Dash
