How to Eat an Elephant: Tips for Facilitating Test Process Improvement
I have been working in process improvement the past few years. During this time, I have noticed some key activities that lead to its successful implementation:
- Know where you are (Understand your current situation)
- Know where you are going (Define your target situation)
- Ownership and commitment from the project members are key
- Develop your process first, then obtain the tools
- Figure out how to eat an elephant
Most of these tips speak for themselves, but I’ll add a few words on the elephant.
Sometimes, when introducing a new process, the organization has a group who sits down and writes the entire process, then presents it, saying, “Now, go implement.” If you’re lucky, you may be supported by a bit of training. There are several dangers to a big-bang approach like this:
- You lack ownership and commitment from the organization
- You don’t learn from the small steps in the process implementation, so you cannot change direction and modify or enhance the process when needed
- Often, the process ends up like shelfware: Too much is required to implement the big machine, so not much gets anchored and used in the organization
- There is not enough focus on the cultural modifications that have to be part of any change
Instead of this approach, consider the question: How do you eat an elephant? The answer is, of course, “One bite at a time.” You need to create your backlog of initiatives, prioritize them, and identify the low-hanging fruit that can be implemented with only a little effort to show that you are changing stuff. Give the feeling of achievement and progress … and then take it in small bites.
For example, on one project I worked on, the first improvement was to create a commonly accepted overview of the testing challenge—identifying the current process, breaking down the testing task into smaller parts, creating the minimum structure, and defining clear responsibilities for the tasks. The main thing was to get the overview and identify process and system components and ownership.
With the overview in place, we could now prioritize. Where should we start with improving the testing? Should we introduce structured scripted testing or just use a test tree as a checklist? What training is needed for support? What could we do to improve the planning process? In other words, you need to create a prioritized backlog of small improvements.
When introducing a new process, the main factor to consider is people need time to get used to new ways of working. Break up the implementation into small steps and let the new activities and processes get anchored before you move on.
Activities may happen in parallel, but when you implement an improved process, the people have to be able keep up with you while supporting their project at the same time—so never forget the elephant.
