Start practicing Shoshin

When you were a child and wanted to learn something for the first time. You chose to learn it from others with an open mind. Take an example of painting the picture. You could experience this when your kids try to mimic you while learning something the first time.

(My daughter Shruti tried to paint the butterfly. She was eager and tried to accept every information with an open mind)

When you acquire knowledge about something your mind becomes more closed. Over the period of time, you become reluctant to accept more information.

I hope you had experienced this at least once. When you try to give suggestion to improve processes like stand-ups, grooming, retrospective or some other agile process, the senior person would refuse to change since he/she thinks that he/she knows everything.

He/she choose to kill your suggestion with her/his closed mind! EGO?

I was introduced to this term by my agile coach when I was working with Tieto education Pune.  Initially, I was not very convinced or sure about it, preconceptions!


However, over the period of time, I saw good behavioral changes in me and my scrum team.

Shoshin clearly encourages good behaviors in you and your team. See below description from Wikipedia.

“If your mind is empty, it is always ready for anything, it is open to everything. In the beginner’s mind there are many possibilities, but in the expert’s mind, there are few. ” ― Shunryu Suzuki

I started attending various agile and software craftsman ceremonies with an open mind like study circles, knowledge sharing sessions, refinements, the storytelling of epic work items and so on. It really helped me and my team to grow as a scrum team.

Believe me, if you choose to practice below-mentioned attitude (SHOSHIN), it will really help you in the long run.

  • Openness

  • Eagerness
  • Lack of preconceptions.

I would highly recommend practicing Shoshin mindset in your team. Even you could include it in your way of working.


See what James Clear says about SHOSHIN:

Agile Economics : How decisions impact cost?

Cost is one of the important corners of the Project-management triangle. This factor is especially important for decision-making from business perspective.

Let’s look at one of the techniques that will help us take more informed decisions about various operations we as developers do.

Consider a scenario when we have to automate the deployments in your project. One natural approach these days, is to automate everything. But let’s take a closer look at the things more closely.

Let’s put some numbers on a graph. On the X-axis we have the percentage of automation done in the project and on the Y-axis we have the cost needed to automate it.

Let’s put one more graph on it, that of “doing things manually”, indicated by green curve.

As it turns out, the cost of doing everything manually is too high. It would require a step-by-step manual intervention many personnel (typically Devops). So if we have 0% automation in our project, the cost of doing everything manually is quite high.

On the other hand, the cost of automating everything, every single step is also high, since doing this will take a considerable amount of time and effort for developing it. (indicated by orange curve)

However, if everything is automated, the cost of doing deployments manually tends to be zero, we can deduce this by comparing the curves.

Now let’s do something interesting. If we add the values of these 2 graphs, at every single point, we would get a curve of something like this (indicated by dotted red curve)

This red U-shaped dotted curve, indicates the total cost if the deployments are done in combination (manual and automation). As you can see the cost tends to be minimum at Point(X,Y).

We can therefore infer that you should:- “Automate X parts of the system by investing Y amount in it“.

Why is this statement important?

Simple, cost. You don’t want to overspend on one particular aspect of the project. Instead prioritize things, (which in this case is X %) and automate them first. And then if you have time, money and will, go for the remaining (100-X)%.

Find your minimum dropping point. It could be way off on either sides. But having a rough idea of where you stand, can help you optimize your business.

Please note the above curves are approximations for explanatory purposes, the actual values may vary, scenario-to-scenario, team-to-team…..

This technique can be used in many other decision-making processes, such as “How much code coverage should we have?”, “How good product quality we want?” and so on…..

The most important part in this thought process is “Prioritization”. Do not plan big upfront. Instead, go step by step. Look where you stand after regular intervals and then do course corrections accordingly. After all, that’s what “Being Agile” means….

Why Definition of done is required?

On Friday morning, Shrikant, the Manager, came to Naveen, the software engineer, asked about “Password reset functionality”.

Naveen had implemented the “Password reset functionality” using test-driven development and replied to Shrikant that he had checked in the code into TFS.

So, Naveen with a great smile said: “Yes, the feature is Done“.

Shrikant was happy and said “nice, let’s deploy it into the staging environment for client’s review”.

However, Naveen was hesitant and looked doubtful since the use cases and the code was not reviewed by another developer and QA was still waiting for his turn to verify the functionality in QA environment.

Ah! Who is responsible for this situation. Who is right or wrong?

You may come across such a situation.

This situation may occur because everyone (developers, reviewer, QA, and product owner) could have their own version definition of done.

One person, ‘done’ may be ‘deliver a feature in production with ZERO bugs’.

To me, it will create use cases, prepare the design, follow TDD practices and so on.

To the product owner it may  be “meet the need, get it verified against business rules”.

Remember the definition of done is a comprehensive checklist of necessary, value-added activities that establish the quality of a feature.

Below is sample definition of done:

  1. Prepare use cases that will cover use needs.
  2. Write code that covers all use cases.
  3. Peer-reviewed (or produced with pair programming) and meeting development standards.
  4. Unit tests are written and passing.
  5. Builds without errors.
  6. Code checked into TFS/git source control.
  7. Deployed to test environment and reviewed by QA.
  8. Passed UAT (User Acceptance Testing) and signed off as meeting requirements.
  9. Any build/deployment/configuration changes implemented/documented/communicated. (Database changes etc.)
  10. Relevant documentation/diagrams produced and/or updated.
  11. Remaining hours for the task set to zero and task closed.

To avoid above situations (mentioned in the first paragraph) in the team, it is very important that everyone knows and follows guideline mentioned in the definition of done that was created by the development team and product owner so that features get delivered completely with good quality.