Detached Development
A colleague of mine recently sent me a long, ranting article, written by an evidently frustrated engineer in his early thirties, complaining that Agile development was a terrible idea. I read the article and summarised its long litany of allegations (some with foundation, most wild) and had intended to write a point-by-point rebuttal of the more extreme accusations levelled at the process. However, that list alone, in brief bullet points, would have produced an article much longer than the one I want to write (or you would want to read). It also wouldn’t have identified the main issue.
The thrust of the article was that you should, in any company, simply trust the engineers to create products of value. Let the company be engineering-driven. Processes that try to introduce business-level concerns into product development simply demotivate, devalue and insult the engineers. In the first instance, Scrum always was about engineer empowerment and letting the engineers decide how to build what matters most to customers. Secondly, how is the engineering team supposed to know what customers would value, if all they do is trust their guts and engineering instincts? Is that enough?
It occurred to me that what the article was really demonstrating was that the product manager’s role in getting agile development right is quite crucial. I’ve been an engineer and worked with engineers all of my career and I can say, with certainty, that many engineers that think they know what their customers would value are often so hopelessly wrong about it, that it threatens to sink the company. Rare, indeed, is the engineer that has a good grasp of the competitive landscape and deep insight into customer needs, who can magically execute a winning product development strategy from their Visual Studio environment alone.
What a good product manager can do, in the context of agile development, is help the makers become more aware of their context, give them clear-sighted guidance on what customers value (and what they don’t want or need) and assist them in becoming more competent at making those valuable products. Along the way, they can be supportive of development efforts that centre around innovation and research, help the team architect in extensible ways and avoid unnecessary technical debt or operational burdens. Product managers that understand product development carries risk are better than those that think development is a sausage machine, pushing out identical, nondescript products. Customers don’t want identical, nondescript products. They want to hire your product to do useful, awesome things for them.
Some developers think that their workplace should be a fully-funded, personal playpen, where they can create to their heart’s desire, irrespective of what their customers really want. They think they can do this without reference to any other stakeholders and without leaving their desk to go and talk to customers, or to survey the competitive landscape in which their product must survive and prosper. Agile, to these developers, is a stupid imposition because it gets in the way of their creative impulses. They resent anybody trying to make them aware of what their business needs them to make or having to report out on what they’re cooking. Rather, they’d prefer splendid, cerebral isolation and detached development, undertaken in the blissful, uninterrupted quiet of an ivory tower.
The plea to just leave the company’s competitive fate to the engineers, let them do as they please and everything will turn out well (high quality engineering and happy employees) seems to be wishful thinking. The engineers might have genuine insight into producing what’s going to be of value, but I’m prepared to bet that the knowledge is unevenly distributed amongst the team. There is nothing to protect a company against pouring time and money into irrelevant hobby horses that ultimately have no market value to the customers they serve. In short, being engineering-driven might work, but in my experience, it usually fails because development becomes so detached — from product needs, from business imperatives, from their customers and from reality.
Who are the customers you serve anyway? Have you selected a viable customer base that is growing and has a future, or are you serving a bunch of soon-to-be dinosaurs, desperately clinging on for their own lives, doing all the wrong things in their own markets, looking forlornly skyward, waiting helplessly for the comet to hit the Earth? One of the most important functions of product management is to shape the product into one that appeals to a viable customer base (or which turns non-viable customers into viable ones). Engineers usually have little awareness that their current customers are about to vanish in a puff of smoke, because of structural changes in their industry. Competing in a shrinking market is both brutal and foolish. It doesn’t matter how good a buggy whip you produce, if horse drawn transportation is being superseded by motor vehicles.
Many developers, temperamentally, seek safety and security in their employment. What they miss is that the safety and security of your employment, as a developer, is directly proportional to how large a customer base you delight. Pretending that you can have a safe and secure job by decoupling yourself from this reality is delusional and dangerous. Again, a good product manager can shore up the safety and security of all employees by producing a product which has wide appeal, is valued highly and which makes the customers natural advocates and word-of-mouth ambassadors of it. Orders should come in without too much effort. If you feel like each order won is like squeezing blood out of a stone, there’s something (badly) wrong with your product.
Some engineers claim that Scrum is just a way of spotting and sweating on slackers. Agile, as a development method, doesn’t demand competence from its participants; it seeks to foster the growth of competence, through mutual support. Being lost at sea inside your IDE is not useful to anybody, if you don’t get help. You can be lost indefinitely, learning nothing, if you don’t seek the support of others on the team. Sprints shouldn’t be so aggressively scheduled that team members have to turn requests for help away, in order to meet their own commitments. There is a certain amount of slack that needs to be built into the sprint.
The way to be an outstanding contributor and engineer, in a Scrum team, is to consistently deliver high quality products that customers value. That means trying and failing, innovating, architecting carefully and minimising needless technical debt are your personal business, not something to be left to a nameless “somebody else”. It means taking the long view, when producing increments of the product vision iteratively. It also means not dropping the ball on the long term vision either, when it doesn’t all fit into a single sprint. Ultimately, it means understanding how your long term vision benefits the product and the customers.
A good product manager can be a genuine guiding light to a Scrum team of agile developers. The closer the product owner (usually the product manager) works with the team, the better. They are the eyes and ears of the market, inside the development team. Their role is to protect the product, as advocate of the customers, while encouraging creative engineers to do their best work.
That’s not to say other team members shouldn’t also be the eyes and ears of the market — they absolutely should. It takes time away from cutting code, though, so the company culture has to be supportive of that. Many development shops aren’t. Time spent understanding what’s actually needed is crucial to product success, but many companies don’t see it that way. That’s broken.
Some commentators have suggested that Agile and Scrum can be greatly improved by applying the Theory of Constraints, Total Quality Management, Continuous Delivery, DevOps methods and Toyota’s Kata continuous improvement disciplines. They may be right, but they could be very wrong. These are all processes that fail to consider what the customer truly values, so unless you perform some kind of risk adjusted value mapping, from the point of view of what’s most valuable to customers, not just the business, you will fail. Amazon said it best by asserting that if you don’t listen to your customers, you will fail, but if you only listen to your customers, you will fail.
The Vanguard method takes a different approach to process improvement. Vanguard says these prescriptive, management-imposed, process improvement initiatives don’t work, because they don’t address the performance limitations of the system people work within and don’t deal with customer variance, instead attempting to design a one-size-fits-all product. They don’t cause the product development system itself to be derived from what customers really want and value, but instead start from the point of view that the development system (the “software factory”, if you will) already exists and must be incrementally improved, irrespective of whether or not that actually helps or hinders the customers in doing the job they hire your product to do.
In the end, the argument between engineering-driven and business-driven product development is a huge red herring. Product management needs to be about engaging developers in customer-driven product development. Customers use your product, value it and ultimately pay for it. How you make products and what products you make should be focused on making customers’ lives easier, embracing and absorbing their rich diversity of needs. Everything else is vanity.
About the author
Michael Topic is a freelance Product Manager with over thirty years experience delivering products that didn’t exist before. He welcomes contract enquiries to define new, competitive products, design them and deliver them. His speciality is software-based products.
Disclaimer
The opinions offered in this article are intended to describe common scenarios that sometimes occur in general product management practice. They are in no way intended to be read as referring to any particular employer, past or present.
