The thing that bothers me about a lot of agile processes is that they seem so uncertain about what to build or design. The practitioners all admonish and warn against arrogance, hubris, thinking you know better than the customer or predicting what the customer wants, but they go too far the other way. Agile software processes seem to be for people that have been parachuted into the problem domain without a clue about the customers, the previous successes and failures in that market, the competitive landscape and about the job of work the product will perform. They seem to barely know its purpose.
What are we? Product designers or zombies?
I think that many people who are passionate about a product domain and the use of products in that domain, who have lived and breathed their solutions in the market of real, paying customers, over a large number of years, know precisely what to build and how to build it. There is no guesswork. Validation by agile process, in this case, is just wasted time. Worse still, if your product design happens to be visionary, then there are few people qualified to actually validate it. Those products happen to be the best products, by the way. Works of genius come initially from the mind of somebody with a veritable talent for astonishing product design.
So the task of the software development process, agile or not, shouldn’t be to insert fear, uncertainty and doubt into the process, so that the pronouncements of the product owner and designer are mistrusted at every step of the way and painstakingly (and often wildly inaccurately or incompetently) “validated”, soaking up masses of time and resource in the process. Just because you are on the development or management team doesn’t mean you have equivalent insight, experience, attitude or passion for the problem being solved.
What happened to trust? What happened to recognising when somebody has some genuine expertise and insight into the problem and has come up with a ground breaking solution? Does it hurt those, with less insight and vision, to admit that they’re in the dark? Is all the validated learning really a thin disguise for jealousy? Does it get abused to shore up the hierarchy, making it clear to all who is really boss in the organisation? Is it a way to devalue the contribution of the product visionary, in an attempt to dissuade him from asking for more of the spoils of the win in the marketplace? A really good product designer is actually worth far more to the company, in actual dollar terms, than what he is being paid. Always.
Everybody that participates in the design of a product wants to feel that their contribution is valuable. The problem is they all want to feel that their contribution is in the overall creative direction of the concept. That, I submit, should be left to specialists that have bothered to spend years passionately immersed in thinking about great solutions. Contractors or new development hires, who have come from some alien problem domain, shouldn’t expect to have the same weight of creative input as the passionate, inventive, innovative product visionary. That just dilutes the brilliance and novelty of the product.
It’s how we get camels, instead of horses. It’s where the committee mentality now resides, though cunningly disguised as an agile process and aggrandised by buzzwords du jour. It might be validated learning, but if that learning has been pre-validated, through a process of informal, but nonetheless important, thinking about the problem over a long period of time, in front of customers, learning from every expert they encounter, every day, with a number of iterations of the solution already under their belt, then to re-validate the learning is pretty wasteful.
I think that the real role of agile processes should be to find a way for people that already know the story to tell the story to those that don’t know it and who will be involved in the faithful rendering of the story into an actual, shippable product. It’s about fidelity to the vision, when you have a strong product owner and designer. It isn’t about second guessing and doubting what they have spent years coming up with.
You can’t replace the hours spent becoming an expert in the problem. You can’t compete with sincere passion. If you want to have an equivalent say in the product design, you have to have spent the hours and immersed yourself in thinking about the solution, body and soul, over a long period of time (several years). That’s what earns you your place at the product validation table.
To take a six month contract with a company you have never heard of before, land in their development department and expect to be calling the creative shots, based on some agile process you use to pretend that you are now the resident expert, or worse, to pretend that nobody is an expert, so that every opinion is equally valid, renders the product insipid, vague, ill-defined, incohesive, conservative, irritating to use and illogical, while taking a much longer time to build it.
I thought agile processes were all about reducing waste and producing better products, quicker. Too often, they are used to massage the egos of people that just blew in, so that they feel their opinion on matters they know precious little about get the same weight and attention as the product visionary.
Agile is too often usurped by ego.