Software Developer: The final outpost
In this day and age most software development teams make use of agile methods to crank out new features and functionality at the speed of light. Unfortunately this improved speed has in some organizations and teams led to a more output focused mindset, instead of paying attention to the actual outcome. More on this later.
In this article I would like to highlight why I believe software developers (myself being one) has a vital role to play in counteracting this output focused phenomena. At the end you will also find some additional resources and how-tos.
My good friend and colleague Martin Holeby S:t Cyr usually describes the cost of making changes to a product using a simple scoring system as a thought experiment. The general idea is that the further through the development cycle you are, the more expensive any changes become, in terms of time and effort. Therefore: always strive to make as many big changes possible as early on as possible!
For example, a change at the drawing board while working with high level user journeys and wire frames costs 1 point. Making changes to full blown pixel perfect static designs costs 10 points. Changes during actual coding costs 100 points, and once your feature have reached production the total cost of making a change now adds up to a 1000 points.
Regardless if the actual factor is 10 between every step, anyone involved in software projects will probably consent to the fact that changes get more and more expensive the further down the line you have taken your feature. And that any changes to features released in production is the most expensive and comes with the highest risk.
What I like to point out in the above example is the accumulated value of the two final stages where we as software developers has the highest impact, 100+1000=1100 in “time and effort” points. As a developer to constantly question why a feature should be developed, and to always look for the expected outcome and purpose, is vital in making sure only features with a high user-value (e.g. business value) ends up in production.
Organizations that do not cherish active questioning and self-reflection within teams, while simultaneously miss to clearly state the purpose of features about to be developed, might drive the organization into a feature factory, a place known to silently wipe enthusiasm and engagement away from any developer or designer involved.
John Cutler, senior product manager at Zendesk, coined the term feature factory and describes it as a product or a company that measures output over outcome; it does not matter WHAT is actually shipped but HOW MUCH.
To me any developers worth their salt will stick up to this kind of delivery madness by actively helping the team back on its right keel; if the developer is not taken seriously by the team or organization one of two things usually happens, the developer simply quits or feature fatigue strikes. The latter being the most dangerous.
Traditionally, feature fatigue is what happens to end-users who get exposed to a too high volume of features and functionality within an application or service.
As John Spacey, a technologist stationed in Tokyo, puts it: “Feature fatigue is a tendency for consumers to shy away from products that appear to be feature-rich. It is a modern phenomena that has occurred due to the explosion in the number of features packed into products and services.”
For me, feature fatigue can strike, not only end-users, but developers as well when organizations fail to highlight expected user-value of new features being developed. As a developer you simply feel like you are developing features for no particular reason, you just become a minion who just live to serve.
Once feature fatigue strikes, your developer will no longer care for the actual user-value and stops challenging the overall feature priorities by finding alternative areas to feel purpose in the day to day activities.
Feature fatigue might go unnoticed since the developer simply finds other tasks to invest time and energy in to feel purpose, not necessarily within areas relevant for the business. Not only is the main focus now shifted elsewhere, but features with slim to none end-user value is now being developed at the speed of light.
A majority of all new features simply becomes waste. Unfortunately these features are not your average “trash” in that sense that you can simply dispose of them, it is even worse since the generated waste now has to be maintained and catered for actively as it has already reached your production environment, costing even more money and energy.
To minimize the risk of spending time and money building and releasing features that no one wants, make sure your development team always knows what the expected outcome of a feature is, especially the developers. Make sure to nurture a culture where questioning is cherished, or you might turn your entire development team into a feature factory!
For more hands on advice about how to avoid running a feature factory I suggest reading this blog 10 ways how to NOT make your product a feature factory by Romy M, containing insights from previously mentioned John Cutler.
Remember, your developing team is the final outpost protecting your production environment from unwanted or maldesigned features. All efforts to keep your developers and designers away from feature fatigue is money well spent!
Do you feel like you need help getting your team back on track? Is your team in need of questioning and user-centric developers? Are you, as a developer or designer, caught in a feature factory distressed by feature fatigue?
Get in touch and we will try to help you out! Either through flatwave.se or by visiting our company page Flatwave on LinkedIn.
Remember to follow this blog to catch all insights released related to customer-value and software development! Leave your thoughts and comments, I am always interested in hearing others opinions!
