How to be Agile in a Non-Agile World

The software industry has a very basic objective: to build a top-quality product. To build an exceptional product, developers encounter a myriad of challenges and dilemmas. They must pay close attention to the end-users requirements; at the same time, they must be aware of the current Tech trends and Industry paradigms. They also need to ensure that the development process becomes efficient and better organized.

In order to cover all the aspects of software development efficiently and make the overall process smooth, a developer must have a clear understanding of the process and a well-thought-out plan in place. It is crucial to have a correct software development methodology in place, that can boost the prospects of the software product, however, making this decision is easier said than done.

As far as software development is concerned, we broadly have two types of methodologies to choose from: Agile or Non-Agile. These methodologies can be chosen based on project requirements and different kinds of scenarios.

So, let us get brief information about both the software development methodologies.

Non-agile methodology is also known as the Linear or traditional Waterfall model. It divides the SDLC (Software Development Lifecycle) into 7 different stages, where we can perform a specific set of activities in one stage at a time. We can jump to the next stage only once the current stage is completed.

Non-Agile SDLC stages are Planning, Requirements, Software Design, Implementation, Testing, Deployment, and Maintenance/Updates.

Non-Agile approach offers a rigid structure, and It often called a plan-driven process. It is important to have a concrete plan and vision to effectively use the Waterfall methodology. Project Managers and Developers should have a clear understanding of all the activities, how and why specific activities shall be carried out.

This model works well for larger teams that have defined and clear goals, a set of requirements, and a robust understanding of the scope of the work.

It is an iterative and incremental method of software development. This methodology is indeed a contrast to Non-Agile, as unlike Waterfall method, which is rigid in nature and strictly restricted to its phased structure, agile is highly flexible and always open to changes. Agile methodology revolves around the concept of segregating the project into multiple small units based on their functionality, which is also known as “user stories.”

Developers then work on these stories and prioritized them according to the project need and then deliver them in short cycles which are known as “iterations.”

Agile approach has the primary objective of customer satisfaction, and that is why it puts focus of each iteration towards providing a high-quality solution to the customer. The primary reason why the Agile approach brings results is the engagement of cross-functional teams to complete the work, which is called “sprints” of small duration.

The primary objective of every sprint is to develop a usable software module that can be delivered to the customer for further testing and usage.

Agile offers a unique mechanism of getting the feedback of customers, which developers can assess and schedule future iterations of the same product.

This entire development work is organized into a backlog, which can be prioritized and pushed further based on customer and business requirements and vision.

Agile is more of a mindset rather than a framework or a guideline. It asks developers to prioritize the work as it comes in, along with the existing set of identified tasks. The development team is supposed to handle the most important set of tasks first and then keep on addressing the other work as well.

Agile also talks about adding and delivering value to the customer once everything is streamlined, we can keep up with the changes happening around and enhance the value of the services.

Agile is all about keeping an eye on the changes around you and then keep adapting them. The technology world is changing so fast that adapting to the change is an inevitable choice. Agile helps us to improve the responsiveness and agility of the software development process.

Here, it is important to know that an important key to successful agile delivery is that the organization and resources must also be agile and able to understand the priorities and vision of an organization. But what if other people are not Agile? Will that be an issue? Will that create unnecessary hurdles for the project? How to cope with such a situation?

Well, we will try to answer all these concerns in the next section of our article.

Contrary to popular opinion, we would like to state that working in an Agile environment is indeed a blessing, and it is a curse as well. Though it ensures forward motion, even if things are not moving perfectly, also it ensures that we do not have to pause every day to re-assess the previous decision that led us to the current state.

However, the problems start kicking in when we start working with the section of organizations that are not Agile. The flexibility, agility, and attitude we take for granted will be missing. They may bring non-Agile processes that may be slower and may not keep pace with the ongoing Agile process.

Hence it is very much possible that your team's agility may be compromised due to the lack of agility of others in the environment.

We may face hurdles when external blockers and restraints come into the mix. It does not matter how good an Agile team is performing, but if we place them in a non-Agile environment, then things will certainly crawl.

We know, it must be very frustrating if we identify an external dependency in the middle of a task and we would be asked to follow a process, which may not prioritize that request and getting it delayed due to non-agile processes.

Though there could be some genuine reason for this delay, other teams might be amid a long-going effort that may prohibit bringing any changes until that existing dependency is completed. Sometimes, the team or group may be overwhelmed enough that they form a process firewall to delay or control things. Regardless of any reason, it is the Agile team, which will be at receiving end.

Here we are sharing some important points, which we must keep in mind while implementing Agile methodology in a Non-Agile environment.

Here, we need to pull out some traditional management techniques. We must understand and keep in mind that frustration and anger will never solve any problem; they will only make things worse in the long term. The Agile teams can identify the external dependencies and prioritize the tasks accordingly.

These teams can use their ability to develop distinguished workstreams to resolve the dependencies before any further work is added to the existing work. These mechanics may depend on the structure of an organization; however, Agile methodology can help us reduce the burden of dependencies to a certain extent.

It is important to help the non-agile teams by implementing and modeling an Agile behavior in our day-to-day activities. It is always advised to be flexible and responsive when we are supporting other non-agile teams.

If our team receives any request, then we must assess it carefully and then prioritize it appropriately. Communication is a critical factor, and we must inform the requester with due justification if there is any delay in request execution.

Agile is indeed a Mindset

It’s true that Agile is a mindset, not just a framework or guideline. Agile teams are known for adapting strategies to achieve objectives aligned to their customer’s needs. They always strive to achieve some sort of improvement in processes and deliveries. This Agile mindset helps them to adapt to the given situation, to learn quickly so that they can bounce back in the event of any failure.

If a team adopts Agile as a mindset and religiously follows it, even in a non-agile environment, it will be able to deliver better outcomes. An organization’s leadership would like to take note of such outcomes and want to build on that success. Sometimes, this mindset is necessary to deal with the challenges encountered while working with non-agile teams and environments.

We must always keep in mind that agile is a thing you are, not a thing you perform. Any change requires a disruption, but people usually do not like disruption. Here it is important for us to understand that whatever we are doing, and specifically the way we are doing it, might cause a disruption in other teams' work. Here it is necessary to look at things from the right perspective and offer support to the non-agile teams to fulfill our common objectives.

Always respect existing Processes and Roles

This is certainly an important aspect while working in a non-agile environment. We must understand that just because we are agile, it doesn't mean that we can expect the rest of the resources and teams to bend around us, that is indeed unpractical and unviable thinking, as that will never going to happen.

We must communicate with the non-agile teams, try to understand their processes, we must ask the right questions about how they do perform tasks currently and how they have been doing these things for the last 10 years. We also need to ensure that existing Roles must be respected and understood in correct perspective.

As we said earlier, communication is the key and it is important for us to communicate in a language that could be understood by colleagues from the non-agile team. It is fine to use the Agile terminology and language (words like "sprint" and "iteration” and “standup" ) within our team, as they are very much aware of all these terms. However, when talking to the resources from non-agile teams, we need to use the normal non-agile language with them.

While working in a non-agile environment, we must adopt a different approach rather than waiting for them to come to you, it's better to take the things to them.

We, as an Agile team, must make that additional effort to engage the people and schedule the meetings with them, demonstrate the proposed functionality of the solution to them. These efforts will not go in vain; over the period, these efforts will certainly show their value, and other teams may start coming to our team.

It is extremely important to grow your team in a non-agile environment. The team should be scaled but very carefully, new resources should be added to the team, but only when we need resources with those specific sets of skills and expertise.

The most common challenge is the lack of visibility and understanding of the vision of Agile team. To overcome this, we must invite people and showcase them the real stuff, do demonstrations wherever it is feasible, give presentations, share the printouts, and put them on the walls for better visibility. This will not only enhance the visibility of Agile-based processes and steps but will help you garner the necessary support.

At first glance, it looks like if Agile and the traditional SDLC model are misaligned due to the different kinds of methodology they adopt. If you talk to Agile supporters, they will love to change an organization into an Agile organization overnight.

Certainly, this is not an easy task, there must be a thorough program to transform such top companies, a change management project must be undertaken to carry out such transformation, preferably, top to bottom.

However, if that is not feasible, then we can follow the above-mentioned steps to survive in a non-agile environment quite easily. Transformation of a non-Agile to an Agile is comprised of change of processes as well as the culture, as both are deeply ingrained into the DNA of any organization.

It is important to work together on these challenges and formulate a cross-governance agile community, where everyone (Agile and Non-Agile resources) can share their experience and knowledge. It will only make things open and better and help us achieve our common goals as a Team.