Thoughts on Business Driven Development #1

From a developer perspective, there are many approaches for a feature development, it can be Test Driven Development (TDD), Behavior Driven Development (BDD) etc. However, developing new features should be in the context of the product development. In that perspective, the notion of TDD might be misguiding, since developers are perceived as “driven” by tests. Feature development should be driven by the business, and the business only.

But why the business should be important to developers?

“The Business represents the customer. They want to make sure that we are bringing the right features to market at the right time” - The Role of the Product Owner, Lee Eason

Developers might not be fully aware of that, but they are making business decisions all the time. When they write code, each line of code is a product decision. The quality of the code, how much it scale, how buggy the code is and how fast they can push it to production, all this will impact any future business decision. Why? because developers know best what they’ve developed, and how much time it will take to refactor it. Code is more accurate than any spec or documentation. A few years ago, I made a small refactoring, extracting dozens of methods from different persistent services to a single component and naming it “recommendation service”. A few years later, this service eventually became the core of the team strategy and shifted the business towards information management.

Another example for the need of being driven by the business are “Hackathons”. Those one-time events may be the result of a disconnection between the teams. Hackathons should not be driven by the developers ambitions to “hack” something (well not only..), they should be a business requirement to the developers to build features that are valuable to the business and easy to develop, the process of so called “hacked” features should be a standard in any product development process.

This is why developers must interact daily with the business team, since unless we want zombie-coders who work on 100-page documentation files and have big QA teams to controls the translation of specs to code, the solution is to have developers that understand the value of their decisions to the business and to future of the company.

Shifting the developers mindset to a business driven development methodology can make a huge positive difference to your team productivity and motivation. The “Feature Factory Syndrome” happens when zombie-coders are doing feature after feature without being able to see the big picture, this may result to demoralization and frustration. In a business driven development, the developers are fully aware of the business goals and how they are being converted to features that compose a successful product.

In the next post I will explain the definition of product owners, flat organizations, bottom-up decision ownership and exposing business challenges for making that change.