Being the latest player in the ever-changing environment of software development practices, Agile has become the focus of many a heated discussion. Is it benefiting or redundant? Is it good for managerial practices or just a fad to be glossed over with time?
Agile has its fair share of fan following, but still faces ire of many developers. The primary reason being that it’s often forced on developers in the company or team without their consent or understanding of Agile practices. Preferred by project managers, it is sprung upon team members. Since Agile involves short scrums or sprints, it is often found to be unnecessarily bothersome by some developers. On the other hand, its iterative runs and close connection with clients provide for a more customer-centric approach. This implies a higher acceptance level for Agile amongst stakeholders, clients, and team leaders.
No wonder there are so many extreme views about it. Some swear by it with all their might. Others reject it for Waterfall techniques. But the truth is, reality lies in between.
Let’s have a look at the various arguments for and against Agile:
REASONS FOR DISLIKE:
It’s still young
IT industry has seen its fair share of ‘fads’ coming and going. So it’s natural if service engineers are reluctant to accept a technique before seeing all its facets fully. So Agile being the new guy in town, is still in the doubtful category.
But the truth is: Agile is nearly 2 decades old now. Way back in 2001, the Agile Manifesto was published for the first time. The Scrum Pattern language came into being even earlier, as a concept presented in the Object-Oriented Programming, Systems, and Languages (OOPSLA) conference in 1995. The seeds of Extreme Programming were sowed in PLoP 1995, through its predecessor the Episodes pattern language. So Agile cannot exactly be called new.
Instead, Agile techniques reinforce adaptation in the dynamic environments where much variability is expected, for instance, in evolutionary theory. It works as a way of interacting with others on a team daily. In a world where communication is the key, it is the only way of established interaction in a complicated world.
Easy come easy go, not:
Agile sounds like it’s easy to implement. Simply divide the project into smaller tasks taken up by different members of the team. Followed by periodic meetings with managers/scrum leaders for progress status. Sounds simple? But in reality, many believe it’s hard to transition from one complex system and delivery lifecycle to a simpler one. Some assume it makes the development process all that much more difficult. And even if some companies have adapted to Agile, they are often pondering, can agile be scaled when a new technology comes into existence? It is worth the hassle of being accepted?
Without proper knowledge on the 12 guiding principles of Agile, some try to implement the Agile operating model or a single Agile based framework by the textbook. But Agile is known for its flexibility. So without proper knowledge on the transformational complexity of Agile, one is bound to flounder. There are so many Agile frameworks in the works, each suited to one style of operation. The key is to not implement an Agile framework simply because it’s popular. Instead, one has to understand the strengths weaknesses of the company along with the consequences of assimilating a framework. Subsequently, failure to do so leads to disappointment on the Agile practice itself. Or even if they manage successfully implement it, it incurs greater expenditure due to lack of effective transformation.
To experience the benefits of Agile completely, one needs to develop a particular, relevant mindset first. Only then, it is possible to incorporate it fully with all team members understanding and accepting the framework.
Planning is non-existent
Or so the traditional Waterfall supporters like to claim. True, compared to Waterfall where the planning process is charted out at the beginning of the development cycle, Agile may seem lax. However, detailed planning is essential for Agile to be effective too. The difference lies in how the two approaches differ in planning timing. While waterfall likes it at the outset, Agile planning is an ongoing process.
This kind of incremental planning approach has its benefits. It puts a cap on large scale upfront investments on uncertainty. It also leads to the adapting of projects and assignments to rapidly changing demands and priorities as the project progresses.
Usually, there are sprints preceded by a planning meeting. It addresses requirement, tasks and the exact time it will take to complete the tasks with all necessities. Different tasks are collaboratively prioritized by the team members. The meetings during each sprint determine the work for the day at in depth. The scrum master must ensure retrospection at the end of iterations among the team members.
With incremental planning approach, there is the challenge of technical debt management. However, most of them are solvable due to openness to reworking on modules as information and kind of requirements desired to become clearer with project progress.
Lack of project documentation
Documentation is like a blueprint an application development project. It details the objectives, end goals of the client and the company, system description and working.
However, Agile calls for less need for documentation because of the involvement of client and owners at every level and iterative run, so the project makes more sense to every party at the end of the sprints.
But Agile does produce documentation, only quite different from Waterfall’s style of documentation. Instead of making a single, lengthy document with all project requirements, Agile brings forward the concept of user stories. Team managers compile them such that they are easy to update and maintain automatically with software help. They are built on the go and ensure real-time transparency and visibility.
Not good with centralized software solutions
It is unheard of to use Agile with federal software development, no matter what the requirements are. The only challenge is that some specific federal practice demands may be challenging with developers using Agile. Primarily, the challenges lie with acquisition, accreditation, architecture and security certifications.
Most companies make a list of requirements with a detailed description of the end product before contracting a software development company. The aim is to obtain a specific kind of end result from a particular vendor. But if this result changes with each iteration, some believe that the federal software requisition falls flat.
But Agile isn’t only about being fast, it’s about being flexible. If the project requirements are all detailed in the contracts from the start as is the case with federal software, then there is a shift in dynamics. The number of sprints, user stories and the overall time become set and similar to Waterfall framework.
REASONS FOR LOVING IT:
Stakeholder first
Agile puts the stakeholder above all, including the clients, project manager, development and testing team. With clear visibility of the project from every side, success is guaranteed. Agile principles dictate the participation of the end ‘user’ in the product’s development cycle and encourage a cooperative collaborative approach. This generates a high amount of visibility for key stakeholders in the progress `of the product or project, leading to efficient management.
Highly productive
In the Agile framework, teams are self-organized. This gives developers the authority and responsibility to agree to work with each other and the client or product owner. This is a stark contrast from the Waterfall framework where the team leader or project manager assigns works to teams and makes all the critical decisions. This induces a sense of belonging and ownership to the team while increasing overall morale. All these factors culminate into increased productivity.
Faster
Since the delivery style is incremental, the time take to reach the market is faster, meaning higher revenues. This is a guaranteed way to ensure customer satisfaction with a greater return on investments.
Better Quality
Quality determines the fate of any project. In the Waterfall model, the testing and debugging phase starts after the development phase. This style has its limits and leads to greater time for testing. In an Agile framework, testing is a continuous part of sprints. With testing integrated throughout the product development lifecycle, regular inspection is facilitated. This means the client can recommend adjustments if necessary, at an early phase. The development team gets early access to any quality issues.
satisfaction for developers
If implemented correctly, Agile provides the best kind of flexibility. It makes work enjoyable for the team with provisions to select tasks in some Agile frameworks. With active involvement from all, the team members can suggest changes to other members stuck on a task. The task can be estimated through games and recreational activities that provide rest to overworked mind as the sprints are fast and short term. Creative task boards, new styles of conducting boring meetings, etc, make it up for a rewarding experience
To conclude, transitioning to Agile framework for an agency used to non-agile frameworks is painful admittedly. While managers may feel they have lost a lot of authority or tools in their bag, it is not necessarily the case. Instead, Agile calls for a harmonic division of workload for faster productivity. What is necessary is to work out the kinks by going over and understanding Agile principles before implementing them. A thorough study of which framework suits the company best and an enlightening the employees involved is necessary for the right transition to Agile. There are so many misconceptions and myths surrounding Agile, so developers need to be explained how it’s for the better instead of worse. And Leadership Tribe conducts courses that can teach both managers and their subordinate developers the core concepts of Agile ensuring that misconceptions and myth never plague their actions and decisions.
