Anyone else feel like planning out a release is a series of tangents and rants? The goal of allowing our customers a good, usable, and delightful way to empower their world seems to be overwhelmed in the rush to be first, and unique, and the fastest changes. Which may not be what our customers want, or at least a significant subsection of them. In an attempt to be the first to showcase the newest, we may leave our customers in a fog, unsure of where they are at, or how to get where they are going.
Making plans for testing and goal-focused development seems to have been forgotten, or overlooked in the rush to get the next release out. Having the ability to insure that the potential risks are focused on, rather than the tangent of "But we need to do this- we'll fix it later" or, worse "This shouldn't affect anything else", are the hints that we need, as an organization, to step back and look at where we are headed. And make sure that our plans for getting there have an awareness of the risk. Many companies who try and be the first to market with ideas then feel obligated to stay first - even if a longer time frame is sensible, and can allow a better experience. Some of what is rushed into releases has no noticeable effect on me, as a consumer. So time spent insuring that there are no unexpected side effects is more value to me.
Forgetting how your product is going to be used in real life is something that subsections of your teams will rant about: you may hear that they would not use it that way- or that it shouldn't be used that way - in contrast to the sections that state that no human in a situation where they would need this would use it in this manner. My personal peeve for this is driving directions - at 60 mph (95 kph), telling me I need a lane change around a minute before a turn is needed is both frustrating and dangerous in a new city.
There have been several comments recently in my world: those who feel that the testing they are advocating for is being pushed aside in the thought that "this isn't needed" or "it would take too much time!" Which, as professionals, we know both aren't entirely true: it may not be needed, but would be necessary. if you are lacking a strong relationship with all the team members - or have a person that is willing to listen to your concerns - anyone with a doubt about why and how this change is supposed to help may end up feeling pushed aside - if something breaks, a not-so-silent statement of blame, or a rant, is likely forthcoming, and could have been avoided. Another case of "We don't have resources to do it correctly, but we have them to do it twice (author unknown)" rules supreme.
In addition, in the rush to get a product out, with the newest features isn't allowing time for knowledge transfer - a new person, coming in at the start of a plan, or even and Aglie sprint, reels away from the workplace, overwhelmed by the amount they don't know, and no one has taken the time to explain -in many cases, this continues for an extended period of time, and is never truly filled in. I have listened, with silent horror, to people who have worked at a place for years, and still have the questions they asked about the product in their first weeks remain unanswered.
I am hoping that the business mindset shifts from the outlook of the ability to release multiple times a day means we must, into a more-confident mode of releases come when they are the best possible changes, and the entire team is comfortable. Listening to concerns may prevent the company from being the next disaster headline.
Top comments (0)