As the old saying goes: “give a man a fish, he eats for a day—teach a man to fish, he eats for a lifetime.” Traditionally, that adage probably wasn’t being applied to Agile Methodologies, but it actually applies pretty strongly to getting the best out of your developers in the modern SDLC. If you tell programmers what task to do next, they’re productive for a day—but teach them how to engage with the methodology and identify the right task on their own? That’ll make them productive for life.
Unfortunately, that’s often not the approach that we see in companies that are trying to deploy Agile Methodologies. It’s a fine line to walk between too little leadership—which can lead to delays and ballooning budgets as projects fail to get off the ground—and heavy-handed oversight that makes real agility impossible. And yet, that’s the line that companies need to be able to walk if they’re going to transform standups, sprints, SCRUM meetings, and other individual tactics into functioning software.
Challenges in Deploying Agile Methodologies
On some level, all Agile Methodologies have a leadership role that’s meant to keep the work on track and help remove obstacles from the paths of developers. This might be a SCRUM Master or an Agile Coach, or it could be someone higher up the food chain like CTO or CIO—but in any case it’s this person’s job to ensure that all of the Agile tools, tactics, and strategies being deployed are actually going to lead to the deployment of a working product.
This makes intuitive sense—and yet, in some ways it goes against the picture of Agile that most people have in their minds. People associate these methodologies with teams that are totally self-organizing and not reliant on central leadership. But while a self-organizing team is theoretically possible for experienced Agile users, the reality is that completely self-organized teams are rare. Even then, some leadership is part of the package—there’s a reason that there are entire schools of Agile leadership out there.
In this way, one of the biggest challenges of deploying these methodologies is getting beyond your own assumptions about how Agile is “supposed” to work so that you can get a specific, clear-eyed view of which Agile practices (if any!) will actually help your organization to meet its goals more quickly and effectively. This is especially true in cases where you’re trying to scale Agile methodologies beyond the small development team you might be working with—if you’re not able to put systems in place for strong managerial guidance that can keep everyone on the same page, you the run risk of disconnect and confusion over what the requirements for a project actually are, who’s in charge of which tasks, and how each disparate Jira ticket actually integrates into a finished product.
The Importance of Agile Leadership
Like we said above, even a team that is largely self-organizing needs a designated person to make improvements to the processes and tools being used, and potentially to interface with other stakeholders within the organization. Without this person in place, development takes place in a silo—or many different silos, and working software never comes around. On some level, you can interpret this as an outgrowth of Agile’s pillar of “people over processes.” Paradoxically, businesses with limited Agile experience become so committed to the ideas that they associate with a particular methodology that they don’t focus on supporting, training, and empowering their people through effective leadership. What does that leadership look like in practice? We’re glad you asked…
What Does a Strong Agile Leader Do?
Okay, let’s say you’ve got a new software package that needs to be created so that your accounts payable department can get data from your POS system more quickly and leverage it into more efficient invoicing. You have a loose idea what the requirements are for this project—but you’re confident that Agile is the way to go, and you assign someone to manage. In a perfect world, what does that someone actually do?
- Adapt the methodologies to the circumstances: Especially at a company that hasn’t done much Agile development in the past, it’s crucial that you first figure out which elements of which methodologies are actually appropriate for your situation. Just because something works for Microsoft, doesn't mean it will work for you. You might find yourself choosing between SAFe (Scaled Agile Framework) and SCRUM of SCRUMs for your scaling options, just as you might have to choose what tools and services your integration pipeline will be built on. Crucially, this is the stage where you have to determine whether any Agile tactics will work for you—which is not necessarily a given. Needless to say, this requires considerable expertise and experience. It helps to have seen and experienced a number of deployments across a number of infrastructures and business cases.
- Keep methodologies on track: Once you’ve figured out the right approach, it’s time to make sure that approach is actually being implanted correctly. If you determine that daily standup meetings will work best for your team, it’s your job to set the agenda for those meetings and make sure that everyone knows what the purpose of the meetings actually is. Likewise, if you’re introducing new tools that your team will have to adapt to, it’s your job to make sure they’re trained on those tools and they know what the expectations are. This task is, of course, dependent on gaining visibility into the project from end-to-end, which is no mean feat in and of itself.
- Facilitate implementation/integration: Most of what we’ve talked about so far has been essentially managerial in nature—but it’s not enough to “just” have strong managerial chops. You also have to know the tools and technology landscape. Otherwise, you won’t be able to ensure that your build pipeline, containers, cloud tools, etc. are actually positioned to facilitate rapid releases and highly-visible environments.
- Remove obstacles: Okay, here’s where we get to some class Agile activities. If one of your developers is looking at delays because of a dependency somewhere else in the project or the organization, you need to do what you can to make sure that developer can keep working on schedule. If the accounts payable team is being difficult and making it impossible to actually assess requirements and set a scope during your pre-planning meetings, it’s your job to get them back on track. The point of Agile isn’t necessarily to do things as quickly as possible (though the goal obvious is to improve your speed to market), but to keep things moving without stoppages—in this way, requirements ultimately get met and software packages ultimately get delivered.
- Make decisions and prioritize: While the above played into classic ideas about Agile, this one is about good old-fashioned management. Like we said above, you want to walk your team through the decisions you make so that they can understand your reasoning and thus better understand the Agile methodology—but it’s still incumbent upon you to actually make the decisions. When people assume that top-down decision-making like this is incommensurate with Agile, projects quickly start to flounder.
- Connect with other stakeholders: This is particularly important as you try to expand Agile ideas and methodologies throughout a larger fraction of your company. You have to ensure that disparate teams all have a shared, compatible vision of Agile, that development meetings are being prioritized appropriately, and that projects are being managed with templates that are actually designed for Agile. This might arguably fall outside the purview of someone like an Agile Coach, but at the end of the day it’s critical that there be visibility between your Agile deployment and other touchpoints within your company.
What to Do If You Lack the In-house Capabilities for Agile
You’d be forgiven if you were a little bit daunted by the list of requirements we sketched out above. Though it’s a relatively high-level picture—the nitty-gritty would take much more than a 1,600 word blog post to cover in full—it’s still a lot to keep track of. For most organizations, this is a pretty tall order. Not only that, but it’s a big risk to commit to a project using Agile methodologies if you’re not 1000% sure that you have the leadership capabilities in house. After all, if something unexpected crops up in development that your designated Agile champion has never seen before and doesn’t know how to resolve, your time-to-market and budget expectations could be dashed.
Luckily, in-house management isn’t your only option. For that matter, in-house development isn’t your only option. But for Agile leadership in particular it sometimes pays to an experienced expert on hand to deal with the unexpected. By partnering with a trusted organization that’s well-versed in these methodologies—having potentially deployed and optimized them in numerous different business units and IT environments—you can lay the groundwork not just for successful software development flows, but for increased agility throughout your entire operation. In this way, you can be sure that your approach is custom-suited to the specific needs of your business and industry, that you’re deploying the right tools, and processes, and that everyone is on the same page about what the SDLC should look like. The result is that major projects meet requirements on-time and on-budget, avoiding potential pitfalls and hurdles whenever they crop up.
The best part about this approach is that it’s fundamentally flexible and scalable. Just looking for an Agile Coach? Engage that coach for as long as you need them—thereby saving yourself the costs associated with a new hire. Want an entire team of Agile developers at your disposal for an upcoming sprint? That can be arranged—all on your terms and within your budget constraints.