Businesses must be much more agile than ever before. If they are not, their existance is under treath. When put under pressure from competitors, customers and other forces, they must be able to change and adapt fast. Can agile software development help them achieve that? And, if so, how could it do that?
One of the most important tasks for business software is to support business agility. But what does business agility mean, and how could we as software developers support it?
The Agile Business Consortium defines business agility as the ability of an organization to:
- Adapt quickly to market changes - internally and externally.
- Respond rapidly and flexibly to customer demands.
- Adapt and lead change in a productive and cost-effective way without compromising quality.
- Continuously be at a competitive advantage.
Business agility is about change. The consortium explains the reasons for a business to be agile as follows:
"The future is unpredictable, and with the world and its technology changing ever faster, it is creating greater uncertainty on our needs and requirements."
Few software developers, when hearing the "agility" word, come to think of business agility. We tend to think about agile approaches to software development.
This situation gives cause to the following question: "Are these two agile concepts compatible?" The answer is a firm YES!
From that follows another question: "Can an agile approach to software development promote business agility?" The answer is once again a firm YES, but this time there's a hitch.
The answer is yes, because agile approaches to software development result in faster delivery of software. And faster delivery of software can't be bad for business agility. The hitch, though, is that it's not enough to deliver fast. Here's the Business Agility Manifesto's explanation
Developing software faster is not sufficient, in and of itself, for survival and growth because once operational, such software is likely to prove difficult to continuously and rapidly change without unintended consequences.
This statement may seem a bit abstract, but the manifesto clarified its meaning as follows:
The true measure of an agile business solution is how much business knowledge is configured into it and how easily that knowledge can be changed or reconfigured.
This is less abstract. To avoid the unintended consequenses mentioned, the software should contain a good amount of business knowledge. What's more, it should be easy to change or reconfigure this knowledge. To achieve this, the structure of the software should resemble the structure of the business as much as possible.
Martin Fowler and James Lewis gave one of the best examples of how to do that. In their pioneering article about microservices they emphasized that "Microservices should be organized around business capabilities."
Many have repeated this statement but few have told you how to do it. And yet, it is so easy, especially if you work in an agile development team. If so, you work with backlog work items on a daily basis. These are user stories, features and epics. And all of these are based on business capabilities on different levels of abstraction.
If only Fowler and James had said to organize microservices around business epics instead. How much easier things would have been.
But don't despair! We'll tell you more in an upcoming article on this site.
