Agile can be a great methodology for developing and delivering better software. But while agile works well in small organizations, scaling agile for enterprises doesn't always go smoothly.
People tend to assume a lot about agile development practices, such as:
- Team members don't change
- Every specialist is also a generalist
- Everyone is engaged and motivated to work
- Your team is always in the top 10 percent of performers
- Teams have very little in the way of external dependencies
- Customers are fully engaged in the process
- Everyone is located in the same place
While these assumptions may be valid for many small, startup environments, they don't often apply when enterprise-scale projects get underway. For example, user stories start to overrun their time frames, spilling over into subsequent sprints, and "work in progress" (WIP) limits are breached, creating bottlenecks in development and testing.
So how do you prevent this from happening?
People with a technical mindset (yes, you developers, dev testers, and others) tend to think that scaling agile is like writing computer programs: "if (agile) then {do x; do y; do z}." But it's not that simple. While each organization is different, there are five key challenges to overcome when scaling agile up for enterprises.
1. Getting into an agile state of mind
Large enterprises, especially those maintaining legacy projects, got used to their various teams working in silos. Development and QA were separate organizations. Developers "completed" their tasks, then passed them on to QA for testing. There was a real disparity between the development team's definition of "done" and the QA team's definition of "done."
To successfully scale agile for enterprises, this mindset needs to change from "I need to finish my user stories," to "We, (development and QA) as a team, need to finish our user stories together." Looking at the WIP as an example, it means that if there are 15 user stories in the WIP, developers haven't completed their task until QA has finished theirs. Developers must accept that the user stories they're working on aren't "done" until they've been approved by QA.
2. Managing legacy projects with long release cycles
Legacy projects can have long lead times between each delivery, which doesn't fit well with the agile spirit of fast sprints and releases. The trouble is that in legacy work, there isn't always a customer breathing down corporate's neck, demanding fast and frequent releases. It's easy to put stuff on hold and ignore the ever growing backlog.
To avoid this, you should try to define interim milestones: internal releases that break up long release cycles to stop user stories from accumulating in the backlog. For example, if your next delivery isn't scheduled until six months from now, break up that long cycle and release an alpha version to a select group of internal users within two months, and a beta to a group of friendly external customers two months after that. This applies a constructive tension to the teams and helps keep everyone alert and on schedule in a positive way.
3. Moving to shorter development and test cycles
Long release cycles are comforting in enterprise environments that have become accustomed to developing full blown solutions with lots of functionality for all platforms and all browsers. But for development and delivery teams, things can get very uncomfortable when features that spent months in development get rejected by your customers. Agile stipulates short development cycles. To accomplish those shorter intervals, you need to shift your approach to "minimal viable product" (MVP) mode. Aim to create the smallest useful, functional product and ship it to customers in short release cycles. You can then monitor customer reactions and tweak the product in subsequent releases.
4. Achieving automation from day one (AD1)
AD1 is a noble quest. The immense contribution that automation makes to the stability and overall quality of your product is indisputable. Automation tests are deterministic, which makes them effective in detecting regression bugs in your product between releases. However, this also means that if your product changes, your automation tests will break. Developing automation tests requires a huge effort by trained personnel and that work must be done in the early phases of development, when a product is much more likely to change. It can be difficult to keep automation tests in sync with product development.
The solution, of course, is to aim for AD2 (or AD3 or AD4...). Postpone your automation tests and develop them according to a carefully devised strategy. Start off with manual testing until you achieve some degree of stability and only then move to automation. Deciding exactly when and how to start writing automation tests can be somewhat of an art. It varies between projects depending on the different considerations you should take into account.
5. Evaluating your progress
Scaling agile for enterprises doesn't happen all at once. No one migrates instantly from waterfall to agile. It's a process that takes time. To evaluate your progress, set reasonable objectives by defining agile KPIs for your team.
A very useful KPI in agile environments is the "average cycle time." This is the time taken for a user story to move through the WIP from the day work on the user story began until it is ceremoniously labeled "done." This is one of the most important KPIs, because it measures the time it takes to complete a user story or feature in your backlog and indicates if you are indeed developing and getting things "done" quickly enough. Ideally, the average cycle time should be no longer than a single sprint, but there may be some variability between teams. As long as all team members can agree on a reasonable average cycle time, you can use it as a standard if user stories start to drag on. You can also eventually adjust your average cycle time. Over time, as the team gains experience working together and becomes more efficient, you'll find that users stories are completed more quickly. When you find yourself consistently beating your average cycle time, that might be the time to shorten it.
You can also use "work in progress over time," which is a measure of the number of active user stories at any given time. It gives you a good indication of whether or not you're opening too many development tracks, how focused your team is, and whether there is time to start and complete additional user stories before the end of the sprint.
Another metric is "average defect resolution time." This represents the time it takes to fix defects in functionality until the product is ready to ship to production. Knowing this average helps you allocate time between continuing with development and fixing defects. You can even take this a step further and break it down according to defect severity, to make your estimates more accurate.
Scale up
The biggest obstacle to successfully scaling agile for enterprise environments is the mindset of those involved in the process. By tackling this mindset directly, you can help team members change how they feel about and act toward their daily tasks. And you're able to measure performance to see that the team continues to make progress and develop more efficiently. Agile is a journey that requires a long-term commitment from everyone involved, but it's worthwhile when you start feeling the benefits that agile brings to your larger scale development group.
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.
