Create Discomfort for Continuous Improvement

How often do you feel the discomfort? If it is everyday, you burn out; if it is seldom, you probably do not grow much.

Sitting on the plane to visit a client in US, I felt discomfort, because of different culture, different language, and more. I expected this to come when I accepted the job. I intended to create this discomfort so that I would grow.

How could we create discomfort to grow the team?

1. Scrum

You may start from where you are, which is one of Kanban principles. It helps reduce the change resistance. On the other hand, does it create enough discomfort? Recently, one client asked me to give suggestion on whether to adopt Scrum or Kanban. One thing I paid special attention to was if it would create right amount of discomfort. For Scrum, 1/3 of people felt positive and were eager to try, the other 1/3 felt challenging and hesitated, still the other 1/3 were unclear. While for Kanban, most of them felt comfortable. Then, I suggested to go with Scrum, as I saw that the discomfort level trigged by the change was not too high to burn them out, but enough to make them grow and improve.

2. Done

Get stories done by the end of every Sprint creates the drive for improvement. You need both clear Done and Sprint as timebox. If you do not have clear definition of Done, it is easy to get "Done" as you change it to fit whatever gets completed at the end of Sprint. I have also seen that team planned one day between Sprints to accommodate not being able to get done. Scrum works as mirror, providing the transparency and exposing problems for your improvement. Done within timebox is supposed to create discomfort for team's growth.

3. Expand Done

If you can constantly get done by the end of Sprint, you become comfortable again. Don't keep in that state too long, create discomfort again. If there is still gap between your current Done and PSPI, expand your Done. Expect that you get problems in getting Done after it is expanded, which is good, because you create discomfort again. Team grows when they solve problems that prevent them from getting this expanded Done.

4. Shorten Sprint

I find that still many teams like 4-week Sprint, because they can do mini-waterfall while still getting done at the end of Sprint. Again, if you observe that team feels very comfortable, it may not be effective in exposing their problems and creating drive for improvement. In that case, try to shorten the Sprint and assess the discomfort level, would it enable team to stop doing mini-waterfall and seek more effective collaboration ways of developing software?

5. Go faster, create more value, etc.

Next challenge could be going faster, creating more value, etc. Or, create your own High Performance Tree as your team vision to help identify the gap. With gap, you feel discomfort again to continuously improve.

It is a journey, enjoy it!

About this Entry

This page contains a single entry by Lv Yi published on April 25, 2016 12:43 PM.

Two Approaches for Solving Dependency was the previous entry in this blog.

Decouple Line Organization from Requirement Area is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.