The basic idea of avoiding improvements is because it might hurt other processes. It might benefit your process as you get in control, only when you ask other project members to help you like better technical design, someone has to write them. Often these are the persons who are currently needed to deliver the code you need.

Recently I was in the fortunate situation a tester told me that things could be improved. An interesting discussion took placeQ: Why improvement is needed the initial answer was to optimize the process?A: By optimization the speed of execution of certain tests will be increasedQ: Why speed should be increased as you managed everything in time?A: We can perform more tests and also perform some regression tests as functionality was added during the acceptance phase.Q: What is your idea about the needed improvements?A: We could do some clustering of test cases, we can change the templates, we could communicate better, daily kick-off meetings will help, data preparation should start earlier, maintaining metrics can be optimized....

It seems he had some thought about this and obvious those thoughts seem to be valid. Are they? I told him that perhaps improvements can be done and I asked him to write those improvements down and explain them to me. I asked him also to think about what the benefits are, the disadvantages, how much it will cost and beside what value will it have. After a day I received a small document with suggested changes, very good structured. Although the document mentioned in a clear state within the context as he saw his activities and how it can be improved it was still missing something. I was written for an "ideal" world. His "ideal" world. Together we went through this document and start talking about the necessity for those improvements and also how will it value the project/business and does his project context match with the overall project context.

It was an interesting conversation as I learned more from the suffer he faced during performing the tests. I also was triggered again that providing only one solution is never enough. It remembered me the words a teacher told us: "Always provide 3 options, let the people decide. One option is no option."At the end of the meeting we came up with the following options:1. Do nothing2. Do something which is not optimal3. Do the optimal solution

This reminded me about an posting I made here in the past: July 7th 2008 I posted an article here The power of Threeabout the situation that there are always at least three options.

In this case it would help if three options were offered also. Only just providing more options is not sufficient. Those options should also be placed in the proper context. It should not only help you and benefit your team; it should also be valuable for the customer.

As in my article in Quality Matters I explained about internal and external improvements, this with respect to direct and indirect improvements. I believe you have to be careful with improving. If you can do better, why not start. If you ask others to do better, consider there time and resources are also valuable. If you are asking them to change or do more it will cost something on other areas. If people are spending lesser time on those areas they become worse. So it is important to place this also in your defined context. What is valuable, their current activities for the organization or you new activities?

So again, here is also the power of three involved:1. Does it help you?2. Does it help the project?3. Does it help the organization?Add for these questions the value towards the organization. I would suggest translate the benefits and disadvantages into value to the product, organization, team.

At the end of the meeting we came to the conclusion that although most of the suggestions are valid as can be, it would cost more on other levels. Does this mean that those suggestions for improvement are useless? I certainly would say no. When people are able to come up with improvements, there must be signals that something is not going smooth. These signals should not be ignored. As they are all written down it will help when improvements are done on a structured way, they can become part of a total improvement plan. Or they can be used as signals that we should think about improvements.

AS IS

The postings on this blog are provided "AS IS" by Jeroen Rosink with no warranties. Most of the post will be thoughts, and thoughts can change over the time. I would appreciate when you leave a comment to sharpen my ideas and thoughts.