In the worst places where you want to work, business people such as internal software customers or sales people are an adversary to the development team. In the spirit of customer collaboration, most Agile teams do better and try to remove the negotiations and embrace change when it comes from business people. Being able to implement new functionalities and changes to the existing ones quickly gives the developed product a competitive advantage.
From business to development
One of the mantras of BDD and Specification by Example, and usually also of Agile methodologies, is to bridge the gap between the two factions. There are different practices and tools that concur in filling in the physical space:
- XP's concept of customer on-site, a business person that works all day with the development team to answer their questions and steer features in the fitting direction.
- BDD's Executable Specifications, written in plain text in a language readable by non technical person (Given ... When ... Then ...) yet driving an automation layer for their verification.
There is also a continuous education (at least in my personal experience) going on in transitioning to an Agile process. Some concepts are difficult to digest for a non-technical person and must be explained and reinforced:
- 9 women can't make a baby in a month: parallelization of software processes is difficult and in monolithic projects makes things worse. Hiring more people isn't going to lower the cycle time, as their need for communication with the rest of the team and for training will slow down the existing team (Brook's law).
- fixed scope, point estimations are simply not possible for totally new features. Only user stories really similar to the past ones can be estimated precisely, while the release date for all others is always a range, not a single value.
- Technical debt has its interests that are automatically paid in the additional time spent for development. If you don't pay down debt, you will continue to pay interests; if you add debt or fail to reduce it to the original size, you'll pay even more compound interests until adding a new user account requires a week.
From development to business
Ah, these business people! They will never understand, what can they know about the art of Agile development?
On the other hand, as developers we should strive too to have a knowledge of the business that is paying our salaries, and of which stories or concepts are the most strategically important. Here are some examples of movements in this direction:
- Domain-Driven Design aims to produce a Domain Model that closely matches the terminology (Ubiquitous Language) used by business people, and that can follow the business model evolutions. Knowledge of the field sometimes become so deep that I joke that there are no PHP and Java developers, since a clearer division is between financial and content developers.
- Business metrics can be part of your monitoring: instead of measuring only how many pages an application is serving, it can measure the conversion rate of users and the new sales.
- We are experimenting in adding potential values to user stories along with their estimation. The idea is to get out quickly those features that have a low ROI while investing more in the ones that will see a large evolution.
But how many of us do know what an EBITDA is? I have some microeconomic training, but usually we don't know about the values of these figures in our own companies. Which is the customer that pays the biggest part of your salary? On which features the company wants to make a strategic investment and which will be dismissed as not economically viable? Are these information available to developers anyway?
Don't mix up jobs: no one wants sales people reading and writing code, or developers making financial estimation. However, knowledge of the rules of the other field is beneficial to optimize the whole instead of working in our own fence.
We must still be cautious into optimizing the whole, not the other field's metrics: if your development team optimizes only for revenue, you're doomed. Technical debt looms right under the corner if you want to ship hacks as features; the responsibility of a developer is not the financial success of its company, but delivering business value, minimizing total cost of ownership in a sustainable way.
Let me repeat:
- delivering business value: shipping user stories, which are deployed and ready to make money. It's not about the number of lines of code as much as the value the product (which can be money, risk management, or else).
- Minimizing total cost of ownership: this includes development cost, to avoid gol-plating; but also future maintenance costs.
- In a sustainable way: without introducing significant technical debt, as it would be impossible to embrace change in the future.