You can observe a lot by just watching

It’s time for a ‘next quote. This one’s from Yogi Bera: “You can observe a lot by just watching”. I use this quote when I see things that are clearly happening, but are completely unnoticed by those involved, thereby missing chances to improve.  

One organization that I worked with did project evaluations at the end of each product. Many evaluation reports mentioned similar problems: Insufficient time, lack of people, and unclear processes. Most of things that were mentioned were there almost from the start of the project, but it often took a couple of months before they were reported. Sometimes action was taken quickly, but in many cases the problems were discussed until it was too late to take action. People were too busy with the daily work that they couldn’t take some distance, and see what was happening in their project.

Is there a solution to this? Yes, I’ve solved this with several projects by doing a retrospective at the end of each iteration. Such an retrospective did not focus on what a next project or the organization should change, but what the team itself could change, in the next iteration. The team looked on how they worked together, identified any problem issues, and came up with suggestions that could be implemented immediately. I have done retrospectives where the team, after observing and discussing what has happened, agreed upon an action point to do things differently. In the planning game that they did on the same day as the retrospective, they finished the action point by identifying new engineering tasks, and stopping with some activities that had not been effective. 3 weeks later at the end of the iteration, they did a next retrospective and concluded that things had gone much better. They came up with some additional changes, which were done in the next iteration. Within a couple of months, they were much more effective. Also team morale increased significantly, as they discussed and solved their problems, in stead of complaining.

Another team was struggling with defects that were reported by the system test team. The system  test team had lots of problems to get the software up and running, and wasn’t able to run their own system test cases. When the development team classified the defects and did a root cause analysis, they understood the problem that they had, which had to do with the way that they planned their functional tests. They decided to use different techniques for identifying functional test cases, and were able to find more defects in function test. As a result, the system test team was finally able to do stress and load testing, and discovered some major defects in those areas. These defects weren’t found earlier, because of all the functional problems that the system test team ran against. By observing defects, and looking at the way the function test was done, the project as able to deliver a fully tested product for release, which has very few defects reported by customers.

Sometimes you have to stop with what you are doing, and take a look on what you are doing. Just watching can be enough, look at how you work together as a team, on how you planned your work, and use any feedback that you. Most teams are able to see their own problems (with a little help from a facilitator), if they just take the time. It is not that difficult, so yes, you can observe a lot by just watching!

(Visited 390 times, 1 visits today)
Tags: , , , , , ,

About BenLinders

I help organizations with effective software development and management practices: continuous improvement, collaboration and communication, and professional development, to deliver business value to customers. Active member of several networks on Agile, Lean and Quality, and a frequent speaker and writer.
Tagged , , , , , , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>