In this blog, we will discuss the various challenges and solutions to adapt Agile in the organisation.
Agile can proliferate throughout the entire software development and delivery lifecycle. The management structure is designed to deeply ingrain Agile principles. To achieve this extension and depth, teams must embark on an ongoing journey toward Agile implementation and embrace a continuous improvement methodology. This lengthy topic covers various Agile complexities and concerns, so it’s divided into two parts.
How to adapt Agile in the Organization
Pilot Testing
In the same way that Agile advocates for “Iterative development” and “Minimum Viable Product,” it also applies this principle to how it is implemented.
The adage “He who chases two rabbits will catch neither” is well-known.
It can be as difficult as trying to capture a rabbit when implementing Agile in a project, particularly when switching from another methodology. Therefore, it’s best to try catching two bunnies at once rather than being overly ambitious at first. As a pilot, you must test a little portion, which could be a module or a small product.
Though inherent in every process, we must recognize that experimentation, learning, and iterations are equally important and essential components of effective Agile implementation. To kick things off and persuade everyone in the organization of Agile’s value in our situation, we need a success story.
Second, it was relatively simple to identify the problems and address them early on by beginning with smaller, simpler teams and products. Over the course of the following few months, we finally established and adjusted some procedures to test in different items.
Reinforcement
When the product is simpler and the team is smaller and has less energy to dedicate to the process, it is easier to get it right the first time. Although noteworthy, it does not meet the criteria for “Excellence.”
It’s interesting to note that when we attempt to consistently reinforce the same efficacy and value, it gets harder. In order to learn, management does not expect you to make mistakes all the time. Thus, the pressure to do well never stops.
Reusing the same procedures and fixes for more recent issues that need for distinct approaches is another issue. You may soon discover that unlearning something is even harder than learning it. Therefore, just because you have a hammer doesn’t mean you have to handle every issue like a nail.
Finding the “Reinforcement issue” is not meant to dissuade you from using your knowledge. Instead, it serves to inspire you to learn more by incorporating relearning and unlearning into the process. Just because you’ve completed something comparable before doesn’t mean you should take it for granted while trying it again.
To get it right the second time, and so on, you need to pay even more attention and exert even more effort. Retrospectives are the most effective method of reinforcement.
Teams often regard it as a secondary or optional practice that they only carry out when there is sufficient time. To make it sustainable, we must solicit team feedback and continuously improve the practice.
Trying to standardize practices across teams is the worst mistake an Agile practitioner can make. Unfortunately, standardized models like CMMI and ISO, which promote repeating practices across multiple projects, are the source of the most common error among Agile practitioners. Admitting that I was one of those practitioners does not make me feel guilty. Realizing it quickly and allowing for flexibility in practice among the different teams is something I would rather take pride in.
When one project has a success story and a model that works, there is typically a temptation to duplicate it in the other projects. While it may seem wise to stick with a winning approach, this method ignores a crucial element—the diversity of team psychologies. Certain practices or methods may be preferred by one team, but others may not feel comfortable with it. Being a process guy doesn’t mean anything if teams don’t feel comfortable and take ownership of the process.
The psychology of the technical leads is typically in charge of team psychologies. They lead the opinion. They each have a unique working style, which is somewhat reflected in the team.
We recently encountered an intriguing situation that we should share with organizations aspiring to become Agile.
The Problem
We were using remarkably similar procedures for two distinct products, each with a different set of technical leads, product owners, and team members from two distinct teams. It is believed that both technical leads are equally capable and dedicated to their positions. I began to receive feedback from upper management that one of the technical leads is not as deeply involved with the product as the other lead and does not appear to be in control of the situation.
Top management believed that the application’s serious design flaws were caused by his over-delegation of tasks and lack of attention. His background and abilities might have made a significant impact on the user interface and application architecture.
He told us he was not really happy with the standup and sprint planning meetings and pushed him to be more passive in his leadership when we asked about his lack of control over the team and the product itself.
He was unable to divide up the PBIs into tasks and follow up with the developers because the product manager, who enjoyed micromanaging the team members, attended and dominated these meetings. After obtaining the business requirement from the product owner, he desired to assume responsibility for the technical solution. It was not in his best interest to expose the product manager to every member of his team.
The Solution
I felt that this issue was unnecessary since I was aware that these meetings are a crucial component of the SCRUM methodology. These gatherings serve as a means of bringing the idea of teamwork to life. But after some discussion with the upper echelons of the organization, we arrived at the conclusion that “people should be served by processes, not the other way around.”
We must therefore look for a different approach if a specific practice is creating conflict among significant stakeholders or a technical lead is losing their sense of ownership.
In light of that, we devised a somewhat tailored SCRUM for that product. We chose to have daily standups with representatives from all three functions rather than the entire team and stakeholders present at every meeting.
For now, the developers are represented by the technical lead. As a QA lead, I speak for testers, and the product manager speaks for the product owner. Every day when we get together, we discuss the agenda, general team issues, and the state of each of our individual functions.
We check each team member’s task status before meeting and have a conversation with them as needed. During the daily standups, we occasionally even give each of them a call to ask questions regarding the status of a specific task or assignment. Every week, developers present their updates or new features to the stakeholders and the entire team. That gives us a starting point for our three-person sprint planning meeting the following day.
This modification of the standard SCRUM process may seem absurd to someone viewing it from outside the context. I know that some typical Agile supporters might be incensed at me for defending the removal of something as crucial as sprint planning and standups, but I intentionally brought up this change.
Here, I want to emphasize that the teams and the leaders—even in their own terms—must fully own the process and the final product. Team members’ decreased ability to collaborate is the cost of this, though we have made an effort to reduce it through alternative methods. Even though the prior approach succeeded with product A, we had to temporarily modify it for product B based on the team’s psychology.
