Does this scenario sound familiar? A sprint team delivers another release on time and on budget. It boasts about how much its velocity has improved and how many story points it was able to cram into a two or four-week sprint. It shows its business partners a bunch of nice, pretty charts that illustrate how it is cranking out software and how agile the organization has become. The business partner is not impressed, however. Her competitors are crushing her by getting more rich features out each month. The competing products seem able to adapt on the fly and quickly address new requests from customers. The business partner asks the team to call out the major features delivered in the last release.

The scrum master proudly rattles off the following:

  • Added three new tables and fifteen new fields in preparation for onboarding customer XYZ
  • Increased the customer number from four to six throughout the entire application and changed all of the UIs to reflect the new length
  • Deployed a new purge utility to remove log files older than seven days to prevent the file system from filling up again
  • Upgraded to the latest version of SQL Server
  • Added the new customer sales by geography report you requested.

The business partner (BP) scowls and starts the following exchange with the scrum master (SM):

BP: “Our competitor just implemented a new Android application to go with its iOS application. This is after adding location-aware alerts and notifications in the last sprint. Why are these two features so far down in our roadmap?”

SM: “You prioritize our backlog. We are just working on your priorities.”

BP: “I first have to have a stable system. We can’t keep having file systems filling up. Our competitor’s customers onboard themselves using a very easy workflow-driven user interface. Simple changes seem to take weeks to get implemented here. It takes so many resources just to keep this platform running. I don’t know if I will ever get the features I really want high enough on the priority list to ever see them in production.”

SM: “Well, we can try to increase our velocity a little more in the next sprints.”

BP: “Sigh.”

When Agile Is Not Really Agile

In Jason Bloomberg’s latest book, The Agile Architecture Revolution, he points out the following IT challenges that are causing what he calls the Enterprise Application Crash Crisis Point:

  • High cost of ownership
  • Difficult upgrades
  • Poor cross-functional processes
  • Apps don’t deliver on business requirements
  • Inflexibility that limits business process change.

The problem here is that IT often has a different definition of “agile” than the business does. In many IT shops, agility is measured in terms such as velocity, story points, burn down charts, and other metrics and data points that are geared toward measuring how well a team is performing based on historical numbers. None of these numbers really measure business agility. They measure IT productivity. These two metrics are not equal. A team can be highly productive building stuff that does not really matter to the business partner. The business partner is often forced to prioritize user stories that add no real value to the overall product other than to make it live to see another day. This is often caused by a lack of architecture.

When people take the term agile literally and start building stuff without putting enough thought into how an architecture will support the demands of the business over time, the end result is usually a fragile and rigid system that cannot respond to the speed of business at a rate that truly makes a business agile. Agility should be measured in the eyes of the customer, not the scrum master. Sure, the scrum master should keep tabs on the team’s performance, but the key business drivers should be focusing on metrics like customer satisfaction, new customer registrations, new features added per some time period (month, quarter, year), revenue growth, etc. If we measure agility in those terms, then we can put user stories in the backlog that drive those behaviors and make them a priority. If all we care about is velocity and story points, we can become really good at cranking out low-value user stories.

For a project to be truly agile, agility must be a driving force in the underlying architecture. How many projects have you seen where the very first thing that is built is a user interface (UI)? A sprint team happily cranks out this new UI with no consideration of how to quickly onboard new customers, how the operations team can support customer calls, how the server team can support the underlying infrastructure, or how to easily accommodate new requests from customers through configurations or rules. Instead, the norm is to simply crank out a web page, start acquiring customers, and worry about all the details later. That may make sense for a cash-starved startup, but it does not for enterprises. I am a huge advocate of a “sprint zero,” which requires business partners and architects to collaborate up front and discuss a longer-term vision of what the products and services should do. This is where the architects ask questions to uncover the “abilities requirements.” You know, things like scalability, reliability, portability, maintainability, etc. Then user stories can be made based on that information and included in the roadmap.

The abilities should be roadmap items just like feature sets are. Usually a system does not need the highest degree of scalability on day one, but some level of thought should be implemented in the initial architecture to ensure that making changes to the system to accommodate future growth will be easier and more streamlined. We live in a world in which technology is changing faster than ever before. Systems that take long periods of time to make low-impact changes will not survive in the modern world of web, mobile, and cloud.

Summary

Being good at agile software development does not necessarily equate to being agile as a business. IT exists solely to support the business in meeting the business’s goals. Business goals are often tied to metrics like revenue, customer satisfaction, and market penetration, while IT often focuses strictly on IT metrics like velocity and story points. A company is only agile if it can deliver products and services at speeds that match customer demand. Regardless of how fast IT can crank code out, what is really important is that the products and services are matching up with the supply and demand economics of paying customers. In the fast-moving environment in which we live in today, it is critical that the underlying architectures of the products and services we build are built to be configured, modified, and automated, so that IT can truly be agile in terms that the business understands.