Tuesday, July 31, 2012

Do Business and Engineering Get Along?

A comment from David B on our recent blogpost on process fanatics got me thinking. He points out that there is often a “dichotomy in point of view and approach between technically focused people and business solutions folk. The more effectively you can get them to ‘walk a mile in each other's shoes’, so to speak, the better the odds of developing technical software solutions that meet--or even exceed--the needs of the end user.” So true!

I’ve been on both sides, and this is definitely apparent. Unfortunately, the solution is not as clear, but I think a respect for what each group brings to the table is a great place to start.

Business people think that engineers often look down on them because they don’t understand all the things the engineers do, and this makes them “stupid,” though in reality, they bring a lot to the table. Who would take that cool technology and turn it into dollars to pay those engineering salaries without all the other functions of a business?

On the other side, business people often think that engineers are putting up unnecessary roadblocks regarding what they can deliver and when. It’s easy to ask for the moon, but it’s not so easy to deliver it. Understanding a bit about the technical challenges of developing a new product would go a long way.

Do any of you work in a company where this problem has been solved or somewhat alleviated? What did you do?


Thursday, July 12, 2012

The Power of Negative Requirements

A requirement gathering typically focuses exclusively on what the product will do, how fast it will do it and the parameters in which it will operate. This is all important, but also, in my opinion, incomplete.

I like negative requirements because they stipulate specific features that a product or application will not provide. I find that by defining negative requirements a product development team and stakeholders can minimize confusion and the dreaded feature-creep. (There are enough stories of failed products and overwrought development teams to testify as to why it is not prudent to simply add a feature.)

When one puts a stake in the ground and states, the new product will not provide a specific feature and why, the conversation really gets interesting. From the development team's perspective, it helps to frame the product and handle change requests more effectively.


Agile Myths

I ran across an article on Agile and loved it--not only because it mentions common myths about Agile methodologies, but also because it mentions common mistakes that aspiring Agile teams often make. I see too many individuals and teams using Agile as an excuse not to plan or document. That's not Agile--it's chaos.

Here's the article link: http://people10.com/blog/2012/05/13/agile-myths-answered-here/?goback=.gde_81780_member_114980795

Take a look, and feel free to tell me what you think. Thanks.