These days, even companies that aren’t in the traditional software space find that they have to undertake complex software development projects. Banks and insurance providers need secure and user-friendly web portals so that their clients can access their services online, just as even the most old-school supply chain businesses are finding themselves forced to digitize in the Industry 4.0 era.
This frequently puts decision makers like CIOs in a tough spot: all of a sudden, trends from the software development world—from continuous integration/continuous delivery (CI/CD) to increased pressure to migrate infrastructure to the cloud to the ubiquity of Agile—are powering more stringent time-to-market expectations than ever before.
This can be daunting even for seasoned industry veterans—questions about the right tactics, teams, and methodologies to use are likely to crop up around every corner. But a little knowledge in this department can be a powerful tool. If you’re trying to decide which Agile methodologies to implement, which tools to use in pursuit of that goal, how to scope your latest project, etc., it’s helpful to have a look at the numbers.
1. Half of CIOs said Agile was a fad.
We didn’t mention Agile above by accident. On the contrary, it’s bound to come up in any discussion of software development. Why? Because it’s one of the key drivers of digital transformation in modern operations. Businesses of all shapes and sizes see high profile companies like Google and Microsoft rolling out sophisticated Agile teams and think that they have to do the same. The result is a pan-industry arms race to see who can break things the fastest.
In spite of its popularity, just a few years ago half of the CIOs polled in one survey thought that Agile was just a passing fad, and that in a short while no one would be talking about it anymore. If Agile is a fad, it certainly hasn’t showed any signs of passing—so why this antipathy? Most likely, these CIOs are responding to the fact that Agile deployments often don’t live up their perceived potential. The architects deploying the methodology within the organization promise new levels of efficiency, but what they deliver is a lot messier and harder to grapple with. Teams wind up disorganized and constantly improvising—which, because Agile is so poorly understand, CIOs mistake for signs of a successful deployment—and the result is that no one ever fully understands the project’s requirements, and inessential tasks receive attention while the basic architecture and foundation of the system languish in unresolved Jira tickets.
For managers who have only ever experienced this kind of Agile deployment, the whole concept naturally seems destined to go the way of the fax machine. But the flipside is that when these principles are utilized the right way, by experts who know the ins and outs of the Agile methodology and its pitfalls, they really can speed up time-to-market. The trick is gaining a clear understanding of how Agile is supposed to work in theory, how it actually works in practice, and how to navigate those two often-divergent realities.
|
Jumpstart your Agile software development! Join us for a webinar to get tips from the pros.
|
2. 92% of executives say organizational agility is critical, but only 27% say they’re highly agile.
Now, this disconnect between expectations and reality might make you wonder why so many people go for this methodology in the first place—and the answer is that they hope it will live up to its name. Especially for companies that are pivoting away from more traditional ways of doing business towards more software-centric products and processes, the need to stay on one’s toes and maintain speed is crucial. Agility—the abstract concept—means responding quickly to new conditions, and never letting a heavy and immovable plan get in the way of the right business decision.
The reason people turn to Agile is that it promises exactly that: it says that you can prioritize working software over documentation and people over processes and tools in order to create self-organizing functional teams. But what tends to happen when CIOs try to operationalize these principles is that documentation is thrown out altogether, and disorganized teams suffer from a lack of direction and integration. In theory, a team that’s able to implement upper case Agile will be able to remain lower case “agile,” but the gap between priorities and actual business realities is fairly stark.
What is it about maintaining corporate agility that proves so elusive even for businesses that make it a priority? Could it be that these teams are implementing Agile methodologies and processes and finding that they’re still not able to rapidly adapt to new business needs in a way that’s truly value additive? Another survey found that only 17% businesses don’t use any Agile methods, so this seems like the most likely scenario.
3. Agile projects are 28% more likely to be successful, even if more than a third still fail.
Finally, we get to what might be the crux of the issue we’ve been dancing around for a few paragraphs now: yes, Agile projects can be more successful (28% more successful, to be exact), but the rate of failure for any software development project is still going to be relatively high. Even if a particular methodology improves your odds of success dramatically, that doesn’t make it a cure all—in point of fact, no single tool or methodology is. Let’s say you have a handful of certified SCRUM masters, you’re set up with Jira and host of other Atlassian projects, and you’ve got a whole host of Kanban boards where you’re tracking the progress of a number of different development projects: at a large company trying to navigate the needs of a complex market, these tactics are only going to be helpful if they’re properly aligned with core business goals.
More than that, they’ll only result in working software if there’s someone who set a proper scope for the project, establish a minimum viable product based on a close understanding of the project’s requirements, and put a plan in place for actually integrating all of the work being done by various team members into a cohesive piece of software. This can be easier said than done, and, unfortunately, you often don’t have the luxury to spend a long time on trial and error.
4. 33% of companies don't use any metrics to define software development success
Like we said above, you need to align your methodologies—and indeed the entirety of the SDLC—with your actual business goals and initiatives. One of the best ways to make this happen is to set the right KPIs and metrics for your project. There’s any number of things you can track across the development lifecycle, e.g.:
- tickets opened vs. closed.
- number of bugs
- code readability
- test coverage
- time-to-market
Any of the metrics above can give you a sense of how your development project is progressing—and yet, fully one third of companies aren’t using any metrics at all to track how their developers are doing. This puts them in a position such that it’s difficult or impossible to accomplish what we talked about above, i.e. aligning business goals with development processes. Why? Because if you’re not actually tracking your development processes, you simply have no way of knowing whether you’re going to meet your goals or not.
This is, of course, assuming that you have explicitly-defined goals that are more specific than “deliver some software.” If you don’t, you’re potentially setting yourself up for a project that doesn’t actually meet requirements in a timely manner. If, for instance, you’re not tracking metrics on your buildout of a new piece of invoicing software for your internal users, you’ll have nothing but guesswork to rely on when they ask how long it will take to implement functionality that lets you adjust sales tax based on location. Since they don’t know when this crucial feature will be available, they may turn towards shadow IT or other problematic workarounds.
Conversely, you might find yourself in a situation where you know that you’re getting yourself to market too slowly, but because you don’t have any metrics to analyze you can't figure out any way to remedy the situation. Ultimately, it’s crucial to benchmark things and establish KPIs from the outset of a project, align those KPIs with specific business goals, and choose the methodology and tools that best promote success viz. those KPIs. Anyone can tell you that this is easier said than done, but the stakes are too high to ignore this part of the software development process.
Of course, the flipside here is that stats don’t always tell the full story. If your developers are under too much time-to-market pressure without getting the leadership and support they need, you might easily find yourself in a situation where all of your KPIs—like closed tickets and completed stories—show positive progress but you’re not any closer to working software. In these situations, it’s all about having the experience and expertise to gain a holistic overview of the project that goes beyond the Kanban board.
5. 22% of companies list capacity as the top challenge they face in developing software.
This number makes it the most cited challenge in the survey. Naturally, it’s hard to remain adaptable and turn around development projects quickly when you simply don’t have the resources you need to get the job done. One of the most obvious fixes here is outsourcing—the same survey found that only a third of polled businesses had outsourced some of their development, but two-thirds of those businesses had been happy with the results.
But outsourcing doesn’t just have to be a matter of adding in extra capacity. It can, of course, but what some CIOs and project managers miss is the fact that the right outsourcing or nearshoring partners can also bring project management and software development methodology expertise to your project. In this way, your relationship becomes about more than just filling seats and churning out lines of code. Instead, it can be a partnership in which you’re able to rely on someone’s existing experience and expertise in order to avoid all of the trial and error and the other pitfalls described above.
In this way, you kill two birds with one stone: you deal with your capacity shortfalls virtually overnight using a team that can easily slot into your existing project framework with very little ramp-up—and you bring in expert software development architects who can work with you to find the optimal tools and tactics to bring your project to its best conclusion, on-time and on-budget. Because you’ll ideally be partnering with an organization that lives and breathes this kind of work, you can be sure that deploying Agile-related methodologies in a smart, value-additive way is completely routine, meaning that you can skip all of the guesswork and start meaningfully improving those KPIs.
Learn More About Intertec’s Software Engineering and Support Services
Intertec specializes in building and supporting custom software for its diverse clients. Our experienced team of interdisciplinary professionals have experience at all stages of the software development lifecycle. Click here to learn more. Prefer a personal consultation? Go ahead and schedule a meeting with us here!
Ready for more insights on Agile software development from industry leaders? Sign up for our upcoming webinar, featuring Intertec CTO Fred Palacios.
