So, this new thing called agile is infecting your company, and you're a business analyst or a tester (and have been for many years). You know your company has some challenges with getting releases out on time, but it has always been that way—software is complex!
You've heard about this agile thing before from other colleagues, and you heard about it from your leadership after they attended a conference. Suddenly, they're convinced that the Midwest bank you work for will become the next Google.
You've heard about how agile makes teams faster and more productive how it helps teams do away with testers, because everyone is now a developer.
With all these forthcoming changes, what will your new world look like? It's an interesting question and one I don't hear addressed often enough in the industry. There are extreme predictions about what the new world will look like when organizations make the shift to agile, but it's hard to know what to believe.
The agile framework and ideology are hardly new (scrum has almost reach the voting age in the US), and many organizations are successfully reinventing how they build and deliver software. But not everyone has jumped on the agile bandwagon—some never will. Often, the risk of making any changes, along with the unknown outcome of those changes, outweigh the potential benefits.
Perhaps unsurprisingly, there are also a number of misconceptions and myths that can complicate the organizational change process.
Agile Island isn't only for the developer
One of the biggest challenges holding back the proliferation of true agile within larger enterprises is that there isn't enough conversation about how to build the bridge for everyone on our teams to come over to the agile island (where teams are happy, successful, and productive).
Not that I'm suggesting that agile frameworks are bad or don't work—quite the opposite. Better software comes from empowered teams, but most organizations still need to figure out how to involve the different skill sets, disciplines, and experience that their current teams already have in the new processes. The move to modernize and empower teams in larger companies is often tougher because, ironically, the drive to bring agile to the enterprise isn't typically a grassroots initiative. Enterprise agile is something that's being pushed from the top down.
What is enterprise agile? While I don't think the industry has a consistent definition yet, I would submit that there are significantly different considerations, scales, regulatory and HR constraints, and cost structures that need to be considered in larger organizations.
Executive support is critical to making any real changes, but many companies forget that agile is less of a process than an exercise in psychology. Agile is about empowering a team to choose to do the work they can best deliver, to have that same team work together to assess what's most difficult, and to work more directly with business stakeholders to figure out what they would like built. It's a process focused on the continuous improvement and evolutionary growth of a system.
In the rush to improve processes, companies are invariably leaving many people on their existing teams behind. Within a larger enterprise, it may be much more difficult to broaden the skill sets of every team member. Many initial process-transformation initiatives spend too much time focusing on developers and development at the expense of having discussions about how those with different skill sets and focal areas can work together more closely on a dedicated team.
In the most successful agile teams, there aren't really any official roles, because everyone becomes cross-functional. Everyone develops, everyone deploys, and everyone tests. There's even some documentation created. Most teams are composed of subject matter experts who contribute to different phases or portions of the system as it grows.
The tester is dead. Long live the tester
In concepts like scrum, quality is everyone's responsibility. And automation, by way of software tools, is definitely necessary to maintain velocity as your system grows. This leads many people to question whether the role of the tester is becoming obsolete. I've asked this question at conferences and at meetings with thought leaders, and I've gotten all sorts of responses. Some think that testers need to be retrained. Some think they need to find other work.
Let's go back to our Midwest bank example and consider the implications of all of these views for a moment.
Immediately, our agile initiative has some pretty heavy organizational mud to wade through. We suddenly have a number of people who feel their jobs are at risk, and they're not likely to make any transition easy. Additionally, we're likely ignoring the valuable insight and experience of a large portion of our existing team, simply because they aren't skilled Java developers (or skilled in any other programming language, for that matter).
Think back to the early stages of the Industrial Revolution, when the world began to transition away from manual labor toward using physical machines to improve scale and efficiency. We're unquestionably a better society having made these technical changes, but there were some hard lessons to be learned from them. We needed to retrain some workers, and we needed to invest more in technology that wasn't directly connected to an end product but technology that facilitated a lower-cost end product. And there was a lot of unrest in the labor force from people who were gradually discovering that their careers no longer existed.
But especially within the enterprise, having different specializations within an agile team yields much better results than a purely development-focused team. In particular, the role of tester is more important today than ever before. The rapid pace of release requires more checkpoints (many automated) to help ensure that quality is architected into the system. We need people on the team to be thinking about integration with other systems and about architecture, which does not evolve organically in large systems. It's been obvious for a while that test automation seldom works and that it scales without being deliberately built into any system. But when test automation is architected into a system, the results are stunning. Simply because we can test more frequently with significantly less effort, we can deliver higher quality software and richer and more relevant functionality. The lesson: catch errors early on in order to save on rework later.
Automation to help the team, not do away with it
Poet Mattie Stepanek said it best: "Even though the future seems far away, it's actually beginning right now." We are deep in the throes of one of the most pivotal periods in human history. Not only is software pervasive in our world, but we have evolved to a level where the creation of software is becoming more and more like manufacturing hard goods in the past. With each evolution of a system, lower-level abstractions become more predictable and standardized, which leads to the automation of common activities.
Business needs software to be competitive and to change and deliver faster than ever before. Agile is becoming an effective way for software teams to align more directly with business, to avoid scrap and rework, and to deliver greater value. The delivery cadence required in an agile environment is beyond what even those creating the software can keep up with, so automating core activities in the process is the only logical solution. However, there are some major misconceptions about automation (more on that in a moment).
Frameworks like Scaled Agile (SAFe) have a very clever way of handling organizational change indirectly, through the concept of a release train. Essentially, it's a team that's dedicated to a release but can also be composed of cross-functional team members: developers, architects, UX specialists, and testers.
The key to faster delivery of any software is removing or limiting scrap and rework. Teams do this by understanding the business problem being solved the first time, working with the business directly to prioritize what needs to be created and ideally incorporating some form of architecture expertise to marry those ideas with what makes sense to address architecturally.
Do we need automation to support tasks during development? Absolutely—automation by way of unit testing, regression and functional testing, performance and security testing, and in documentation, deployment, and so on. This premise leads to one of my favorite myths in modern software development.
Making agile work in the enterprise
I have never been a part of, nor have I seen any project (agile, iterative, or waterfall) that has had enough time or resources to accomplish everything that was ideally needed for a business solution. We always have to make trade-offs based on what we have to work with. Automation is most successfully used as a way for the team to do more with what they have—not to replace bodies on a project.
Automation, when done properly, allows the team to focus on more challenging activities and to effectively deal with the quantity of functionality that needs to be tested and validated with each release. Automation doesn't replace people; it frees them from low-priority activities and allows them to focus on building more complex abstractions and more elegant systems.
Agile absolutely works, but let's remember why we're adopting it and what the real genius is behind it. It's about psychology and continuous improvement. It's not a silver bullet for fixing organizational problems.
Successful agile transformations are not about workforce reduction, the death of the tester, or an effort to build teams of super-human geniuses. There's so much wasted work done on a traditional project today that even slight shifts in how teams think can improve velocity without needing by-the-book scrum.
But there's a fine line to walk, especially as larger organizations look to customize or even ignore some of agile's core tenets. It doesn't take a lot to make an agile project dysfunctional—this whole concept of empowerment is pretty powerful. However, also remember that the system needs to evolve, with success stories paving the way, ensuring that the team is best able to deal with shifting priorities and change.
5 key considerations for enterprise agile
In summary, agile can work within the enterprise, but there are some key considerations that need to be addressed:
- Figure out how to involve the whole team within the new process, or any transformation will be severely impaired from the start.
- Role specialization can definitely still work (think SAFe) in an agile environment—just make sure everyone is dedicated to the release.
- Testers in particular can offer a lot of value to the enterprise in an agile environment by helping architect automation and providing a rigorous quality focus for releases.
- Automation (test, deployment, continuous integration) is important for teams to get a handle on the speed and volume of work.
- Neither agile nor automation should be used as an excuse to shrink headcount or to fix organizational issues—it just won't work.
What are your thoughts? Anything you would add? Let me know in the comments below.
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.
