There are a lot of software development frameworks and methodologies out there. We mean A. LOT. Knowing which set of procedures, methods, and theories is right for your organization, your team, and your project can be complicated. Since you’re here, we’ll assume you have a nodding acquaintance with Agile Methodologies. Just in case, here’s a working definition in 50 words or less:
The Agile approach to projects sees cross-functional, self-organizing teams working in close collaboration with their customers/users in an iterative development cycle featuring adaptive planning, continual delivery, and flexibility in its response to change.
Following our assumption that you’re here for more information on this set of guidelines and best practices, we’re not going to try to sell you on Agile. Instead, we’re going to offer some thoughts on how you can make that decision for yourself by going over some of the more common stumbling blocks and hurdles we see people come up against on their path to Agile serenity.
Challenge 1: Not Having a Firm Grasp on the Tenets of Agile
Agile has been around the block. It literally got a guidebook in the form of The Manifesto for Agile Software Development, published in 2001. Its four values and twelve principles started to give shape to the movement we know today, providing common ground for all the existing and future methodologies and frameworks. It’s a given that if you want to go down the Agile path, you must read, understand and acknowledge the values and principles of the manifesto.
But as with many manifestos, it only details the “what” and not the “how.” Even equipped with the manifesto and other resources, people tend to badly misunderstand the principles that make Agile projects successful. People see Agile as a quick and easy path to a functional product, without having to take the time to document their processes, lay out the structure of their team, or highlight the tools to be used. This is not the case at all. As ever, it’s crucial to keep in mind that the objective of implementing Agile must always be delivering robust, working software that satisfies an existing need.
|
Jumpstart your Agile software development! Join us for a webinar to get tips from the pros.
|
A strong Agile leader/coach is often required to provide guidance on the process and make sure all the actors are performing their parts, otherwise the project can quickly devolve into chaos, frustration, and endless rework. We would recommend finding a solutions partner to work with on your first outing, until you feel it out and find your footing. An experienced Agile coach/consultant will help you customize any methodology to your organizational reality and make sure you avoid common pitfalls. The first contribution may even be a recommendation not to do Agile, depending on the exact nature of those organizational needs. Agile's not a silver bullet, after all.
Challenge 2: Focusing on the Right Things
Agile has built-in flexibility. That’s a big part of why it’s been so successful in such a wide range of projects and industries. With that flexibility comes an increase in opportunities for minds to wander, or for the scope of the project to grow.
Your team is made up of humans. You’re a human. We’re all human. As humans, we all have an inborn tendency to lose focus and be distracted by shiny objects. And there is nothing shinier to stakeholders than promises of bigger and better things—except maybe working software. As the old consultant saying goes: “The client doesn’t know what they want until you show them what they asked for.” It’s not uncommon for the stakeholders to notice missing things that were not mentioned previously, or to realize that a new improvement should actually be made that “adds significant value.” If these not-so-little requests aren’t handled correctly, they start to pile up, and they make the scope of the project bigger, since the stakeholders label them “absolutely required”.
Ask around, and you’ll find a lot of stories about beautiful, shiny websites where most of the features just don’t work, applications with a total lack of usability or accessibility, projects that deliverer two or three times the original amount of work, and software that was implemented to the spec, but just didn’t satisfy the business needs. All these are the result of the same problem: not focusing on the right things
Agile Methodologies are iterative for a reason: It allows the team/organization to revisit priorities after every iteration, to make sure that the team is building the Right Thing, i.e., providing the most valuable features at any given point in time.
Each methodology tackles this differently, but there is a common theme: One single voice (be it a Product Owner, Product Manager, or a Product Committee) should dictate priorities and requirements for a software project. This simplifies communications with the team, and prevents people adding “just one more small feature” until the project is completely bogged down.
Challenge 3: Incorporating Post-Cutover Maintenance
After a while, it finally happens: The software is declared “good enough,” and it’s deployed into production. Praises are sung, bottles are opened, everybody is euphoric, savoring the big victory. And then it’s back to work as usual.
Most (if not all) Software Development Methodologies just plain stop when the software is released. At most, they’ll give guidelines to maintain it (say, add new features), but by and large they don’t provide guidelines on how to tackle production issues. And rest assured, there will be production issues. There’s simply no such thing as “perfect software”.
Agile Methodologies have an advantage on this regard. Why? Because they give enough flexibility to the planning that the same development team can tackle development and production issues as they appear. Just add the issue to the scope of the project, set its priority, and let the team do their thing. Sure, this means that urgent, “I’m losing money” kinds of issues will cause new features to be dropped from the current iteration, but that’s really how it’s supposed to work.
Challenge 4: Providing Strong Leadership
Once the framework is in place, Agile is designed to be self-regulating. Meaning that in an ideal world, the team takes charge and the manager makes sure they have the support and assets they need. The team leader can then offer moral support and mentoring as appropriate.
That said, all Agile Methodologies also have a figure/role—be it an Agile Champion, Scrum Master, Agile Coach, or something similar—whose only purpose is to make sure that the teams apply the methodology correctly, help the team implement any improvements they deem appropriate, and get them back on track if they lose their way. These figures have a managerial status, such that they can remove obstacles or make any decisions that need to be made.
Management is there to manage things, right? Well, yes and no. If we were to pick one trait we think all managers—especially of software development teams—should have, it would be the ability to know when to stand up and take the lead—and when to sit down and let the team do their thing. No team is likely to meet the platonic ideal of Agileness right off the bat, so Agile leaders have to walk the fine line between these two modes. Self-managing teams do not happen overnight, and a strong leadership is necessary at the beginning, especially if the team is new.
Crucially, by “strong leadership” we don’t mean “tell the team” but “teach the team.” In other words, instead of telling the team which task to do next, walk with the team through the process of determining what the right task is. Every situation under your control—whether it’s one-on-one performance reviews, daily standups, sprints, or quarterly board meetings—provides an opportunity to dispense mentorship and guidance. There are times and places for managers to take charge, and there are times and places where they must know when their job is watching the team do what they do best. Guidance looks different in each scenario, so you must understand and know how to deploy it appropriately.
Challenge 5: Establishing a Unified Vision
When you think about the word “agile,” what picture comes to mind? We’d bet it’s something like a Cheetah running across the plain, or maybe a sports car sorting all the twist and turns at top speed. What likely didn’t come to mind was a bloated, bureaucratic organization with layer after layer of middle management imposing their will on the worker bees. The point is that agility is synonymous with moving quickly and easily, and that’s easier with fewer people and well-defined scope. If you’re working with a smaller team, co-located, and who can handle being guided by someone who gets that you just want to write code—Agile may work great for you.
But Agile can fall short on medium to big organizations where there isn’t a shared vision on why Agile is being implemented, how it impacts each department, and which changes need to be made in the culture. Agile will fall flat if the schedule, cost, and scope are fixed, if the PMO insists on using templates for artifacts not designed for Agile projects, or if the organization thinks the development meeting (dailies, planning, or meeting with the “customer”) have less priority than other meetings. There are many more examples, and all of them show a lack of shared vision on The Goal of implementing an Agile Methodology.
(Bonus) Challenge 6: Handling Exceptional Circumstances
This goes hand in hand with the Challenge 1. Sometimes, there will be exceptional cases where the methodology doesn’t offer clear guidelines on how to proceed—which is why it’s so important to have a firm grasp of the tenets of Agile and have an Agile coach/consultant to guide you through your first implementation. Even if this isn’t your first rodeo, there’s always a chance that something new and unexpected crops up, and you’re always better off asking for help than just winging.
If your organization lacks someone with this skill set, Intertec has experienced people who can help you get your footing and understand all the nuances involved in a successful software development project.
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!
