I recently attended a presentation delivered by Forrester Research analyst Kurt Bittner that I found very inspiring. The presentation centered on how the nature of IT is changing to reflect the new realities of business. In particular, it centered on how DevOps is helping organizations improve their pace of delivery.
Kurt made an excellent point: if we look across traditional industries, including travel, finance, and retail, the differentiators are becoming less about the products themselves and more about the interaction with the customer. Often it's the speed of response to the customer's needs that helps set companies apart.
Most loans tend to be similar from bank to bank, many airlines cover the same routes, and many of the same products can be purchased at various retail locations. Price can be a differentiator, but more companies are realizing that it becomes a "race to the bottom" if price is their only distinguishing factor.
When user experience matters
It's that customer/user experience that does the most to differentiate a company from its peers in the eyes of the purchaser. In the financial world, this could be in the form of a faster loan approval process; in travel or retail, it could be a better mobile app.
Hold onto that thought for a moment.
It's also no secret that all businesses work to lower their own costs. Lowered costs mean better returns for shareholders and even a better ability to affect the pricing angle on services or products offered—this concept is hardly new or revolutionary.
For me, one of the more frightening conversations I have with clients (and a common one lately) is about how they're primarily justifying a move toward agile to help lower organizational costs.
Moving beyond cost-savings
A more agile delivery method for customer-facing applications makes sense for a number of reasons but not necessarily because it lowers cost. Agile first and foremost helps deliver the highest and most relevant user value or a sprint toward a "Minimum Viable Product (MVP)," a term coined by Frank Robinson.
Mobile apps epitomize the MVP concept. Take Microsoft Office, for example: in the complete Windows desktop experience, Office requires hundreds of MB and contains dozens of sophisticated features. Most of us may never use 80 percent of what Word and Excel have to offer.
The Android version of MS Office is around 89 MB and contains only the core functionality that most users demand. It's a more nimble and focused version of Office. I'm not suggesting that Word should always have only 20 percent of its current functionality, but from a maintenance and development cost perspective, Android Office pales in comparison to its Windows Desktop "parent."
Microsoft's core goal in creating a streamlined Android version of Office wasn't to lower costs (it could have been, but I doubt it) but rather to offer Microsoft products in these other environments (iOS, Android) to stymie the burgeoning growth of competitive offerings.
Staying ahead of the Joneses
"If we don't do it first, someone else will beat us to the punch." This is the mindset behind the more successful implementations of agile methods inside companies. Google and Amazon update their applications at a blistering pace to stay ahead of competition. The driving factor isn't to lower costs but to deliver a concise and high-value user experience. Doing so focuses their development efforts on building the most critical functionality.
Cost saving ends up being a side effect of building only the most important functionality, in an incremental way, by testing early (and continuously) in the process—these are core agile tenets. Cost saving is not directly the goal.
So, if agile tends to lower delivery costs, shouldn't a focus on cost saving achieve similar results? Why am I nitpicking at verbiage?
Well, it's because cost saving has been a goal for almost all companies. It's the change in focus (building what's right versus saving money) that orients the team toward the right behaviors as the product is created. Purely observationally, organizations that have adopted agile primarily as a way to lower costs tend to develop some very destructive behaviors. Often, these types of undesirable behaviors can contribute to the failure of agile within an enterprise:
Scrum teams have traditional managers instead of scrum masters or coaches. Agile teams need to be freed from the arduous reporting and meetings that generally accompany more traditional, top-down management techniques. In most cost-focused project approaches, authoritative management evolves in order to ensure compliant and more predictable behavior from a team. Agile, however, is about empowerment and focus. Providing traditional, non-servant leadership within an agile team tends to hinder progress and creates dissatisfaction, often leading to chaos. Agile teams need to be free to self-select what they feel they are best able to build, in concert with what the product owner needs most.
Testing relies heavily on offshore resources, causing lag and delays in the feedback loop. While offshore testing can be a successful practice, more successful agile organizations tend to employ a hybrid approach to remove the time zone impediment on receiving feedback from development efforts, as discussed in the 2014-15 World Quality Report by Capgemini, Sogeti, and HP. The goal is to test in tandem with development, because it allows for the fastest correction of issues. Testing in tandem avoids the scrap and rework that teams face when they invariably build new functionality on top of things that end up needing to be changed due to bugs identified during testing.
Forced obsolescence of specialized skill sets on the team. The thought process I've observed is that if the team members are cross-functional, things can be done faster, without the need to involve often overextended shared resources (such as DBAs). In many cases, the team does need to become more cross-functional. However, many organizations still struggle with technical depth in performance and security testing—roles that could reside within a modified center of excellence (COE). In many organizations, refactoring an existing COE is preferable to eliminating it—a natural conclusion when "everyone can do everything." Often, organizations looking to save on costs tend to lean toward removing a COE, rather than changing its size or skills focus. And of course, COE members need to be a part of the core team in order to truly add value.
Automation replaces people. A common refrain I hear from clients is, "If we automate properly, how many people can we reallocate to other activities?" When cost is the driving factor, they ask, "How many people can we let go?" Automation is necessary in an agile project to cope with the pure volume of work as a system grows. Automation also provides the team with repeatability and begins to build a set of actionable, objective metrics. But everything shouldn't be automated, even in agile projects, and especially in some aspects of testing. There's always a cost when creating any form of automation—sometimes far higher than a comparable manual process. Yes, I'm arguing that manual testing can sometimes be the right answer. Ultimately, the team should be thinking of architecting automation into the system where practical, while also being sensible about what is automated.
I'm sure there are other examples of awkward behavior within organizations that are new to agile, but of course your mileage may vary.
Conversely, when organizations are driven to agile as a way to deliver software more quickly, empower teams, or build solutions with more relevant end-user value, costs become more predictable. This predictability comes in no small part because agile frameworks time-box a release, forcing the team to prioritize features throughout. By forcing delivery around a fixed schedule and using a flexible framework to complete functionality in increments, you can ensure that the team delivers the most critical features and avoids extraneous work on less important items.
There's no shortage of software industry studies that attribute a high share of project-cost overruns to unnecessary features—once again leading us to the concept of the MVP.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
