Thanks for the comment. While I agree that the “Business alignment” rule applies to Product Management in general, in the context of decision making, and in light of the examples I gave, it is also something that Development needs to understand as well.

As I wrote in the article:

“We want efficient engineering teams. They should not be wasting cycles on non-productive work or work that has little value. But, that drive towards efficiency, velocity and productivity cannot be blind to the priorities and needs of the business. Those business priorities must be incorporated into the day-to-day decision making that takes place in a product development cycle.”

What you’re suggesting may work, but I think a lot of stuff that “product” would boil down to a “no regression in major product areas” or something like that.

I look at it this way. The requirements documents basically focus on what’s new or different from the last release. Everything else should continue to work as defined or designed in previous releases.

Obvious things like the installer and licensing should not need to be specified unless there are changes in those areas. If PMs need to specify that, then what else do they need to specify? The Dev/QA people are technical professionals, not automatons who will only do what is told of them.

But the culture of development is far too skewed towards technical expediency and that has to change.

Saeed

People do have different frames of reference, and that’s why the Manifesto is a good thing for the development community. It is a call for a change in attitude and culture amongst software development professionals.

For those building commercial software — even open source products — they need to understand that they are a part of a business. For example, SugarCRM is an open-source CRM product. But it is part of a for-profit business. It competes with commercial closed-source CRM products.

As long as developers are working on commercial software, they need to join the rest of the company and ensure they are aligned with the business objectives. Now every developer doesn’t have to be a business pro, but those in management — development managers, QA managers etc — should be mature enough to understand what the objectives of the business are and why not everything can be handled as purely a technical decision.

The licensing example I provided was simply one of several instances I’ve seen over the years where technical decisions were made without understanding the business implications of them. At minimum they raise support cases, but can also cause business loss. Imagine the impression on the company that purchased the software. If they can’t actually even get the software license working, what could that imply about other parts of the product? Perhaps they should reconsider their purchase. It’s something that would run through my mind if I bought software that didn’t install or couldn’t manage licensing properly.

The Manifesto is helping change the culture of software development for the better. This issue of business alignment is one area where it could make the change more impactful.

Saeed

David

Roadmapping seems to be an issue for many agilists. I wrote about it here,

http://onproductmanagement.net/2008/10/28/agilescrum-and-product-roadmaps/

Really there is no conflict, but I can’t tell you how many times I’ve heard proponents of Agile argue that creating a product roadmap is useless in an Agile dev culture because “the requirements backlog is constantly changing”.

This comes from a lack of a understanding of the business context they work in. Businesses care about releases. They don’t care about iterations or sprints. Yet, I’ve heard developers state far too many times, that given the code can ship at the end of every iteration (let’s just assume that is true), why do we need long release cycles. Again, this is a lack of the business context.

In the end, every employee in a company should have enough understanding of the business and it’s objectives to make more informed decisions in their jobs. This is true for sales, marketing, finance, product management and, yes, engineering.

We need informed, educated professionals who deliver value add in what they do, not a bunch of technologists who are oblivious to the business they are in.

Saeed

You are right, automated testing would have solved the problem, but the lack of automation is not a reason to ignore testing licensing.

You state that the QA is not to blame, as they made their decision based on risk assessment. And that is the correct approach from a purely technical point of view. But that is exactly why this new element is needed. They cannot simply work from a technical perspective. They need to look at things from the business perspective. Licensing is core to a software business. It is not simply a feature. It MUST work and it MUST be tested. The licensing example is simply one specific case for the need for a more business oriented focus. The priorities and needs of the business, not simply the technology must be part of the decision matrix.

And until it is explicitly expressed in something like the Agile Manifesto, it will remain a gap that needs to be addressed.

Saeed