My Story Thus Far - Part 3
I think it's the ability for an organization to turn it's problems into assets that makes it a great place to work. Late in 2016 I was noticing a trend at Agility - we were all getting tired. Folks were working more hours than ever, developers were burning out, project managers were pulling their hair out over deadlines. We were slumping, and we didn't seem to be able break out of it by working harder. Something had to give.
One day I got a recommendation from CEO Jon Voigt to read a book. He had been travelling and had been listening to audio books on the plane and in the car. He said "Joel - our problem is BOTTLENECKS! You have to read this book - it's called The Goal." Being a somewhat avid reader, I searched it up and was soon reading a sample of it on the kindle app. Turns out this book is over 30 years old, and although it professes to be a scientific analysis of the theory of constraints, it's written in novel format - it's a story. It's a damn good story, well told.
I highly recommend this book for anyone who's ever tried to produce something with multiple people involved - not just manufacturing or assembly lines - anything. It's filled with different anecdotes and ideas that easily relate to production. It was amazing to read about a camping trip with boy scouts and how walking in single file from point A to point B could apply to writing software, but I started to see ways that we could change some processes at Agility to help eliminate the areas that were slowing us down - the bottlenecks.
I started to look at how we had been building software and websites, and I looked at the patterns. It turns out that we tended to cram a lot of work in at the END of a project, just before a deadline. We had never planned to do that, but it's just how things had been turning out. Most of our project teams were very small - usually 3 to 4 people max, including project management, architects, devs, QA, etc. Sometimes all the code in a project would be written top to bottom by a single developer, which made things simple, in theory. Here's the thing though - we had projects that were wildly successful, with very happy customers, but as I said earlier, our people were burning out. I had one developer come to me and say "I have no idea if what I just built is any good. I just know I don't want to look at that code for one more second." It felt like a massive slap in the face. The developers were heroes in my eyes, but they felt like failures. It was a disaster waiting to happen.
I read The Goal in one sitting. Stayed up all night. It is riveting. I saw immediately what we needed to do, but I was worried about how it might sound. I stewed about it for a few days, but we were continuing to have problems with burnout, and I knew something needed to be done. I called a meeting.
I looked up from the whiteboard where I had been madly scribbling out ideas and diagrams. It was silent. Nobody spoke. But, all the faces in the room were smiling. All of a sudden I knew everyone would be on board and we were off to the races. The ideas for improving our "factory" and getting our "machines" running more smoothly was intoxicating to the team. I would never have dreamed that the art of building great software would be improved by such (for lack of a better word) archaic concepts. Our teams expanded to include many more folks, and we started more closely together than we ever had before.
Today, many months later, we are still refining the process and iterating over different versions of our factory. New bottlenecks have emerged and most have been eliminated, but the effect is undeniable. We are working as a team instead of individuals, and instead of isolated "hero" developers, we are sharing the pride in our accomplishments.