The Problem of Plenty

Over 8 years ago, I had just then taken over the responsibility of delivering a complex product; there were over 1500 people working on development and testing of one single product! delivery was behind schedule and cost was escalating with every passing day. It looked messy; I could sense that teams were not working in a cohesive manner, building overlapping functionality, resulting in conflicts and rework. And it was clear in my mind that there were too many people than needed(obvious, isn't it). Before even I addressed the structural & process related issues, I had to have a plan to reduce the team size so that we didn’t create more and more problems to solve! That said, I didn’t know where to start from and I was looking for opportunities. Soon I had some that provided me with enough insights to work on.

A few days into my role, a team of 15 people approached me. They were allocated into the program but were all herded in a conference room as there was space crunch(!) and they were not assigned any work. They requested me to address their issue so that they could get started. While I listened to them, I could quickly figure out that there were more such people that were allocated to the program but without any work. That provided me with the first opportunity to reduce weight and I did that clinically! It will be another discussion as to why in the first place there were so many people!

As you would expect, there were more people so more test engineers as well. And they wrote more test cases! There were 64,000 test cases, most of them to test the design (as opposed to intended use) and the test suite was growing. It included test cases that were written from day-one though the product which was in its nascent stage, was undergoing design changes along the way. Because there were more test cases, it took more time to test and there were more issues(defects) as well. One day testing teams celebrated raising 100,000 defects and that’s when it hit me hard. It was clear that people were at cross purposes and were not joined up for market success. That’s when we took several steps to optimize, shift-left and automate testing, and made changes to leadership there; we needed a leader who would work with and not work against development teams.

Over a period of 18 months or so, we brought down the team size to 800+. Don’t get me wrong. This is not about self righteousness. Nor am I saying testing is the issue. It’s all contextual. This could happen with designing as well. All I am highlighting is the problem of plenty. The more the merrier, doesn’t apply to product development! Cohesive commando teams always work better!!

#ProductDevelopment #Healthcare #Testing #Transformation #Optimization #Automation