It has been a LONG time, and so much has happened in my life since my last post, but one common theme keeps emerging: words have meaning. You may be asking, “Well, what does that even mean?!” I mean, even Led Zeppelin told us that “sometimes words have two meanings.” And I suppose they are right, when you’re talking about art or symbolism or what-have you. But in the context of analysis, words really do have just one meaning. And when they get mixed up, trouble can ensue.
Examples. I worked for a company once that was very clear: if there’s a problem, call it what it is, and let’s solve it. Every week at status update, if a problem was on the horizon, we took steps to mitigate it and move on. This was one of the most effective teams I have ever had the pleasure to work with, and I loved that we could really speak truth to power and get things done.
I worked for another company that took another approach – a “problem” is nothing but an “opportunity.” Our managers told us to never use the word “problem” in conversations with directors and higher. Yet, we were still supposed to have a “sense of urgency” about everything. The result was, we developed software that may have “problems”, and rolled them out too quickly, to demonstrate our “sense of urgency.” I don’t really think the authors of the Agile Manifesto meant to do it that way.
Still another company I worked for did something that blew my mind. A team that I was not on developed and implemented something that was not tested, and it caused major downstream problems. They brought the team into a “war room” and spent weeks – yes weeks – solving the problem. And then, that team got a very prestigious teamwork award for acting quickly to solve a problem. That they caused. Because they didn’t test. Yet many other teams did the “right thing” and implemented good software, perhaps less quickly, but were problem-free. The result was teams because incentivized to actually build in problems so they could be recognized for their achievements in problem-solving. What?!!
So, let’s think about that word, “problem.” It’s just a word. How does it get such negative press? Was it all the logic problems we had in math class growing up with trains leaving stations at different speeds in different directions and all that? Seriously, though. In my mind, a problem is nothing but a puzzle, and a puzzle can be solved. A problem may very well be an “opportunity” in disguise because the solution may become a lucrative piece of software itself later, but it isn’t always. But if you ignore a problem long enough, it could grow up to be “trouble” or a “deal-breaker.” Nobody wants that.
I think we would all agree that a goal for software development and implementation is to introduce as few, if any, problems to the production environment for the users as possible. At least, I truly hope so. With that in mind, what harm during the requirements, design, and development process is there in identifying and solving problems? A couple of things:
Some business analysts and developers are actually measured on how many defects in requirements and code are found (not just deployed) during testing, and the more they have, the worse it is for them come annual increase time. So, who’s going to be sweeping problems under the rug? I suggest that defects (problems) found in testing, and before testing, and even in the requirements review process, should instead be celebrated at that time because then they can be solved early on, at a lower cost, and never exposed to the users. Why? Because that means we’re having actual conversations about reality, and not just trying to hit some metric.
Some people are actually afraid to bring problems forward. I recall once when a company I worked for was rolling out a brand-new technology product for use by the general public that would, if successful, be a very useful tool for the company for many reasons. Sadly, I’m not sure how many real public people they interviewed or had focus groups with, because the product wasn’t taking off in use as well as they expected. So one time, in an all-hands IT meeting, the CIO puts up a Slack chat on the big screens (this was a large company), and asks outright, “have you used Product X (name changed to protect the innocent) and what is your feedback?” The premise was pretty cool. The CIO, knowing that the employees were also likely customers and have taken the product on a test-drive, was seeking end-user feedback for the development team. So, as the brave little early adopter I am, went to the Slack channel and posted something along the lines of, “it takes me twice as long to use Product X than the current way I do that process.” And the Slack comments kept scrolling. After the meeting, my manager called me into her office. She told me that my comment was not appropriate and that it made my director look bad. Well, my director was a great guy and I certainly did not intend to make him look bad. The CIO had actually asked for feedback. But here I was being “coached” (another word with mystical, multiple meanings at that company) and the upshot was, I had no desire to give feedback ever again. And, to be honest, I never used Product X ever again, and I hear it’s still not widely used.
So, my plea to those of you who have leadership or influence: stop making a “problem” a bad thing. It’s only bad if you don’t address it. And it’s likely not to be addressed if people’s pay or recognition is tied to it, or if they are shamed into not talking about them. Let’s not pretty it up by calling it an “opportunity” – let’s let an “opportunity” shine on its own merits.
Leave a Reply