Products, not Projects

@benjaminm Not if it’s a faster, better, cheaper Betamax/8 track player/rotary phone – value is in the use, not the construction

— Gene Hughson (@GeneHughson) September 7, 2012

I’m sure the person who asked Benjamin Mitchell that question truly believed that “faster, better, cheaper” was valuable. I’d imagine that person values his or her work and considers anything that enhances that work to be beneficial. Unfortunately, that’s not always the case. If I create something that fails to meet your needs, my ability to do so “faster, better, cheaper” is supremely irrelevant. From the customer’s viewpoint, value will come from the capabilities that your efforts enable, not from the work itself. The product is the value, not the project.

It’s no secret that I’m skeptical of emergent architecture. Solving various small problems in isolation is not the same as providing a coherent solution to the overall business issue. In fact, focusing exclusively on lower level details may impede our ability to solve the larger issue:

Intuition does not adapt quickly to new situations and resists changes in scale. A retail cashier who is exceptional at serving customers and processing purchases finds new, perhaps overwhelming, challenges in managing the store. The cashiers natural intuitive ability to diligently manage a single customers purchases is overwhelmed when presented with many customers and many purchases. The culprit is the complexity of detail. Often referred to as an inability to “see the bigger picture”.

Gary W. Kenward , “The Systems Perspective”

Just as a system is more than a collection of components, the product is more than a series of projects. Tom Graves, in the slides for his BCS-EA 2012 presentation noted (slide #8):

Products always imply a service…

• Whom do you serve, and how?
• How will you know you’ve served?
• How will you know you’ve served well?
• Who decides?

The answer to the first and fourth questions, are obviously “the customer”. Questions two and three, however, can be trickier. Feedback is required to answer those. The advantage of frequent incremental delivery lies in the fact that feedback can be gained, both by the development team and the customer/product owner:

We all know the world is not flat, and Scrum is not a linear process. But some Scrum teams use feedback only to improve the process, and forget to apply it to the product. User stories are consequently turned into software without learning from the stakeholders and adapting the backlog. This wastes a massive opportunity: to ensure that the right product with the right features is created.

Roman Pichler, “The Scrum Cycle”

If process improvement is emphasized to the point of excluding product improvement, the feedback is wasted. Each release should be seen as an opportunity to reduce the divergence between the product delivered and the product desired. The smaller the divergence, the greater the value.

Focusing on the product aspect, which meshes well with DevOps practices, enhances application lifecycle management by tying budgets to business value:

Using a product management approach, the organization now has budgets for product teams instead of new development or maintenance. Budgets are no longer lumped together, but are instead dedicated to specific product lines. Each product team needs to make the case why their product needs funding based on the business value that it generates compared to total life-cycle cost. Using this approach, organization can now make business decisions as to which products to innovate on and which to cut or retire.

Fadi Stephan, “You Build It, You Run It”

This kind of holistic approach encourages customer participation in the process, setting up a virtuous circle of increasing value, increasing ownership and increasing satisfaction. Products with a high level of customer satisfaction (not to mention those that work on the teams developing those products) tend to do better over time than those without.

Fightin’ Words

Architect: Would it make sense to only host the UI on the SharePoint front end servers and put the other layers behind a service on another box?

Consultant: Naw, that would be stupid.

If you’ve read more than a couple of my posts, you may have noticed that I’m something of a fanatic about pragmatism. The blog was only a little more than two weeks old when “There is no right way (though there are plenty of wrong ones)” was published, and it’s been a recurring theme since. Whether designing a system or designing the process under which systems are developed, context is king and very little is truly absolute.

In the exchange above, the consultant in question didn’t need to ask about load on the front end web servers, dependencies, etc. before deciding that the idea was “stupid”. Any contextual information that might require deviating from the script appeared to be unwelcome. As it turned out, that wasn’t the case. The consultant was actually a very talented and flexible individual who had a momentary lapse in people skills. That momentary lapse, however, could just as easily poisoned the well and ended the collaboration before it started.

Most would understand that “stupid” is one of those words best avoided in all cases. However, words like “right”, “proper”, “good”, and “best” are frequently used as are “easy”, “quick”, and “cheap”. All of these are meaningless without context (and extremely subjective, even with it). Some can be positive or negative depending on the circumstances – is it shoddy “cheap” or inexpensive “cheap”? Ostensibly positive terms can seem like a weapon when you’re on the receiving end – if my way is “proper”, that would imply that your way (assuming it differs) is “improper”.

Just as lock-in creates a danger when designing, mental lock-in can lead to communication failures. Whether it is a matter of shutting down the conversation or misinterpreting it as such, the result will be the same. In my opinion, inadvertent offense is actually worse in that you’ve offended the other party and aren’t even aware of it, which can lead to unexpected issues in the future.

Another danger inherent in these words is the mindset it can foster, both in ourselves and others. We’re ill served when no one will challenge us and worse off when we’re too certain of our own skill. A few weeks back, the saying “strong opinions, weakly held” made the rounds on Twitter. It defines “Wisdom as the courage to act on your knowledge AND the humility to doubt what you know.” I’ll agree with Liz Keogh that it’s probably too much to ask for from a human, but it’s a worthy goal nonetheless.

So, does this mean that I’m advocating verbal pacifism? Hardly, I enjoy a good mental wrestling match too much for that. I do, however, recommend knowing when to be diplomatic (customers) and when to be nurturing (mentoring). As in everything, striking a balance and molding to the situation is key.

Happy Anniversary

It’s hard to believe that it’s been a year since I launched Form Follows Function. Over the course of those twelve months, I’ve put up forty-eight posts (counting this one) and received nearly twelve thousand page views. Twenty-eight subscribers follow via WordPress or email and a further forty-nine via the RSS feed.

The international character of the readership is something I find quite amazing (as well as humbling). While forty-seven percent of the views have come from the US, UK, Canada and Australia, the remainder of the top twenty are quite a diverse group:

• India
• France
• Netherlands
• Brazil
• Sweden
• Israel
• Belgium
• Spain
• Germany
• South Africa
• Italy
• Romania
• Ukraine
• Pakistan
• Switzerland
• Poland

It’s been a privilege to be able to share my thoughts and an honor being able to interact with those who have commented here, on LinkedIn and Twitter. If what I’ve had to say has been of use to others, I’m very happy, but know that I am still greatly in the debt of others who have shared their knowledge and experience with me.

Here’s hoping the next year brings even more participation. Thanks for reading and keep coming back!