Five Barriers To Overcome When Adopting Agile Development
By Jason Moccia CEO, OneSpring
You know that Agile is a superior approach to managing IT development projects, speeding the software development process and producing higher quality results. So why isn’t your company on the Agile bandwagon yet?
Although the advantages of Agile are clear, the steps necessary to move the development process in that direction can be less so. Regardless of organization size, any fundamental change can be difficult. It’s OK to admit that you need a little help implementing a new approach—even if your company currently utilizes a development-centric methodology.
Whether you take the Agile journey yourself or bring in help, keep the following five challenges in mind:
People are resistant to change—any change
The hardest part of any major project is getting people on board. We are creatures of habit and like things just the way they are. By its very name, Agile is the antithesis of stationary.
Before moving to becoming Agile, you must get buy-in from throughout the organization. This is a step that must be taken deliberately and cannot be rushed. There are several change methodologies out there; find the one that best fits your company and your purposes, then follow it religiously. Buy-in starts with the project champion and the executive team, then moves to the early adopters in each department. Cultivate the early adopters to convert the rest of the staff. Do not underestimate this critical step. All of your planning and hard work will go down the tubes if the team members aren’t on board.
A little process goes a long way
The first platform in the Agile Manifesto says it favors individuals and interactions over processes and tools, and that certainly is true. But a little process sprinkled among the chaos can keep a team somewhat focused.
First off, don’t overlook setting high-level objectives and priorities that then can be subdivided into manageable chunks. A product roadmap can help teams set goals for the week, the month or the quarter to avoid feeling overwhelmed.
Second, don’t ignore the roles and responsibilities among the team. Someone has to have the final say-so on when a product is ready for release, for example. Yes, everyone will be working toward a common goal, but recognize that not everyone gets to be first violin in the development orchestra.
Finally, take time to look behind you. If you’re just concentrated on putting out the latest software iteration or incremental change, you lose sight of not only what is working and not working, you likely also aren’t seeking input from your customers and internal stakeholders. Failing to learn from your mistakes dooms you to repeat them.
Being afraid to break things
Agile can be messy, with many false starts and missteps before a project takes a fundamental leap forward. That’s part of the process, a process that must be respected. But it doesn’t mean that progress isn’t made on daily basis. There is a difference between breaking things because the team has found a better path and breaking things for the heck of it. That’s why Agile requires appropriate team leaders who are knowledgeable about not only the methodology but also about the project’s goals—daily goals, overall goals and everything in between. But at the same time, managers are less important overall, which can be a hard lesson for them to absorb.
Being unafraid to break things
At the same time, there is a method to the madness that the Agile process looks like from the outside. Freed from the constraints of traditional development, some programmers may assume a “Lord of the Flies” attitude where anarchy reigns and anything is possible. But that’s not helpful to the Agile process. Trust the process … at least in the beginning.
Think of Agile like merging onto a busy freeway. The merge lane is there for you to get up to speed and gain a little confidence before changing lanes. If you swerve into another lane too soon, you risk imperiling not only yourself but also your fellow motorists.
It’s critical that the team notches a few early wins using the Agile framework. It’s not necessary that the team uses every tool in the arsenal along the way. There will be time for that later.
Change is (and remains) a constant
You’re never done with Agile. The development process is ongoing, with constant feedback, testing and tweaks. That can be overwhelming to teams accustomed to ticking the “done” box and moving on to the next project, so a little culture change (see above) is required.
Actually, though, the constant of change should be exciting, allowing team members to tweak software in response to customer feedback earlier in the process, catch and fix bugs quicker and see the fruits of their labor sooner. A pat on the back for something the team did last year might be appreciated, but that same pat on the back for something the team did last month (or last week, or yesterday) is more relevant, more meaningful and more likely to influence future actions.
---
Jason Moccia has over 20 years of experience in the software development industry and is the founder and CEO of OneSpring LLC, a design consultancy based in Atlanta GA. Mr. Moccia has a Bachelor of Science degree in Business Administration from the University of Florida with a focus in Management Information Systems (MIS) and a Masters in Business Administration (MBA) from the University of Georgia.