If you’ve overseen a large software development project, it should come as little surprise that more than two-thirds of such projects are doomed to failure from the start. Indeed, real success is hard to come by—and the more likely outcomes right now are partial successes, e.g. projects completed way beyond their deadlines, way beyond their budgets, or way below their expected levels of functionality. The result is that businesses of all shapes and sizes throw good money after bad in the hopes of salvaging projects that should have been scoped, sized, and managed much differently from the start.
Though development projects have been failing since the dawn of time (or at least since the dawn of computing), most modern failures take a very particular form: failed Agile deployment. The benefits of Agile are well documented, and CIOs and project managers across the board see big, successful Agile implementations at large tech companies and try to replicate that success in their own operations. The problem is that all businesses and business initiatives are different, and what works at Google isn't likely to work at your average Midwestern insurance company. In fact, Agile isn't likely to work at all if you don't understand its pitfalls and challenges at least as well as you understand its principles.
In point of the fact, the Agile Manifesto (on which specific Agile implementations like SCRUM, SAFe, etc. are based) is fairly simple. It calls for:
But folks tend to badly misinterpret these concepts. They think that plans and documentation are old hat, and that the entire software development lifecycle should be leaderless and improvised. In a perfect world, self-organizing teams could roll out the right software for a set of requirements without traditional oversight—but self-organizing isn't the same as making it up as you go. Even a self-organized team needs a clear set of requirements and a well-groomed backlog, so that they're building out the right parts of the software in the right way at the right time, instead of creating a mishmash of different features without any way of integrating them.
|
Jumpstart your Agile software development! Join us for a webinar to get tips from the pros.
|
At best, a project that lacks clear definitions, priorities, and structures—that prioritizes moving quickly and the appearance of Agile over moving in the right direction—will require a ton of costly and time-consuming rework. At worst, it will never get off the ground at all.
Now, let's say your team is implementing Agile in a way that enables you to move smoothly and without obstacles within a structure that will actually help you build towards your goals. Are you out of the woods? Not entirely... Even if your software development lifecycle is built to meet requirements in a structured way, you can still run into issues when those requirements aren't sufficiently clear. After all, if you're building a widget that's designed to digitize your company's invoicing process, and the accounting team can't or won't give you a sense of what functionality the widget actually needs, you're essentially stuck gambling on your best guess for how to complete the project. In the extremely likely event that you don't magically intuit their needs, you're stuck with more rework and potential delays.
Often, projects appear to fail because the requirements change in the middle of development. This can be frustrating—no one wants to deal with a project whose stakeholders are so fickle that they change their minds faster than you can code—but it's often not an entirely accurate representation of what's going on. Take an industry like banking: your software project needs to meet certain regulatory requirements, yes, but those requirements usually have long lead times before they change. So, when your CFO comes to you and says the requirements have changed, what he usually means is that the requirements were, in fact, unclear to begin with. This means that your team has been working on the wrong thing since the start—all because you were given vague or incorrect information at the start of the project. Though the only real recourse here is to anticipate this possibility and get as firm a handle as possible on the requirements from the start, this is another area where a better organized Agile team will be better able to establish and respond to those requirements.
Okay, let’s say you’re overseeing a project to custom-build a new CRM system that will revolutionize your sales and marketing systems. You have a number of high-minded talks with those teams to better understand how the current market-based options are failing them, what sorts of functionality they need on a day-to-day basis, and just generally how they intend to use the system. You estimate that it’ll take X number of months to deliver the project in full based on the information you have, and you go about reserving resources and ramping up project teams. Then, as the project goes on, you realize that the project is so massive that you barely know where to start. This means that things go slowly and developers often work at cross-purposes. Your estimates for person-power and time are based on very little—meaning that they could be way off in either direction—and they're bound to remain volatile. Why? Because your developers are probably milling about with no clear direction or integration strategy, and the functionality that's getting built out has little chance of ever coalescing into any sort of finished product, let alone one that your sales and marketing teams will actually want.
The best bulwark against this kind of pitfall is always start with a small scope and expand outward. Figure out with your sales and marketing folks what would constitute a minimum viable product (i.e. what are the bare minimum features they would need to use the application and get value out of it), and then assign stories to developers and start in on sprints with a clear vision for how they'll integrate into that product. From there, you can cautiously expand the scope to add features as needed. In this way, you can start with a much clearer idea of how much time and capacity you'll actually need, and thus avoid disruptions further down the road. Of course, even scoping out the MVP correctly can be a challenge—which is why we recommend bringing in an expert who can help you refine your timeline and capacity estimates.
This isn't a strictly an Agile problem, but it's certainly Agile-related: developers feel enormous pressure to mark tasks as complete, but they're not getting the support they really need to contribute to the project, so they misrepresent their progress. Instead of reaching out to others on the team who might be able to help, they simply close the existing ticket and create a new item in the backlog to address the "technical debt" from the first issue. In reality, it's not technical debt, it's unfinished code that doesn't work. But from a manager's perspective, it's extremely difficult to see that just from looking at Jira.
This presents us with a something of a paradox: Jira and other Atlassian tools are meant to empower Agile methodologies, but in instances like the one we described above they're actually contributing to a situation where tools and processes take precedence over people. And the result is that real problems don't become clear until the delivery date has nearly arrived. Unfortunately, there's no easy solution to this problem—since this is in some ways of symptom of larger Agile implementation failures, the best way to deal with it is to get your Agile methodology into working shape, whether that's by refining your processes in-house or brining in an expert.
Sometimes projects don't succeed because of issues with scope and capacity: issues that were present at the start of the project are never resolved, and things spiral out of control. Sometimes, however, you have the right people working on the right tasks for the right requirements and a viable product still fails to materialize—why? Often, it's because of a lack of technical leadership. Again, in a perfect world an Agile team can self-organize, but in this world self-organizing teams are a rare achievement, especially when the makeup of most teams is often changed by attrition and new hires. Thus, you usually need some more traditional management to ensure that everyone is working on the right stories and that all of their work is being integrated successfully. Someone has to organize discussions, provide guidance, and ultimately create the structures that will result in a finished product that meets the needs of internal and external stakeholders.
This is another area where improvisation really doesn't cut it. To keep your development initiative on track, you need a comprehensive, end-to-end view of the project—something that's hard to come by if you haven't managed tons of similar projects. You need an organized approach to project management that's specific to your industry, project, and team, and you need to avoid all of the other pitfalls we sketched out above. A technical lead at Google might be able to pull this off without breaking a sweat, but for most businesses (even in the tech world) this is going to be a daunting proposition.
So far, we’ve sketched out a number of high-level reasons why software development projects don’t go as planned. No doubt you noticed that none of these pitfalls were about technology or technical skill per se—rather, they were basically all operational. This leads us to one frank conclusion: Why do software development projects fail as often as they do? Because they’re mismanaged—whether that’s from a staffing, scoping, project management, or internal communications perspective. For a problem like this, there’s no one-size-fits-all fix. That said, there are better ways to set yourself up for success. Partnering with (the right) managed services provider, for instance, can be an important step in giving your team the tools, capacity, and structure it needs to meet deadlines with the desired functionality intact. Even a business that regularly completes development projects may need a convenient way to scale capacity up and down as needed over the course of a project. For businesses at which this kind of project might not be routine, you can rely on a managed services provider to help you properly scope the project, assign the right number of resources, and choose an appropriate methodology. Since all of this will be routine for them, there won’t be all of the uncertainty around these choices and judgement calls. Instead, seasoned professionals will help ramp your project up and down using repeatable processes that they’ve implemented and scaled countless times before. The result is that your software development vision becomes a reality, instead of languishing in development purgatory.
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!
Afraid to face another software development fail? Check out our webinar, How to Turbocharge Your Agile Software Development, to get tips and strategies directly from Intertec CTO Fred Palacios!