How to Cultivate Agile In Your Organization – Issues and the Practical Solutions

Hello everyone! By now, you should have a good understanding of the basic principles of Agile adoption in your company. However, this is just the first step towards successful implementation of Agile in an organization.

Before we proceed, I recommend checking out the articles we have published so far in our series on “Successful Agile Implementation.”

Agile has the potential to permeate all aspects of software development and delivery. It is designed to be deeply integrated into the management framework. To achieve this level of expansion and integration, a continuous improvement approach and an ongoing journey towards Agile implementation are necessary.

In this article, I will discuss some essential ingredients you will need for this journey, as well as the milestones and guidelines to keep moving forward in the right direction.

Since this is a complex subject with various challenges and complexities related to Agile, we have divided it into two parts.

The Pilot Testing

Just like Agile emphasizes the importance of “Minimum Viable Product” and “Iterative development,” it applies the same principles to its own implementation.

There’s a famous saying, “He who chases two rabbits will catch neither.”

Trying to implement Agile in a project is as challenging as trying to catch a rabbit, especially when transitioning from another process. It’s better not to be overly ambitious and try to achieve too much at once. Instead, start with a small pilot project, such as a small product or module.

Experimentation, learning, and iterations are fundamental aspects of every process, but they need to be explicitly recognized as necessary ingredients for successful Agile implementation. We needed a success story to kickstart our Agile journey and convince everyone within the organization about the importance of Agile in our context (learn more here).

Moreover, starting with smaller teams and products made it easier to identify and address issues early on. This helped us refine and customize certain practices in just a couple of months, which we were then able to use in other products.

Figure 1

Reinforcement

“Excellence is not an act but a habit,” said Aristotle.

Getting it right the first time with a simple product and a small team is relatively easy. It’s commendable, but it doesn’t qualify as “excellence.”

However, maintaining the same level of effectiveness and value repeatedly is more challenging. Management doesn’t expect you to make mistakes all the time in the name of learning. So, there is always pressure to get it right.

Another problem is the tendency to apply the same practices and solutions to new problems that require a different approach. Sometimes, it’s harder to unlearn something than to learn it. So, you might end up treating every problem as if it requires the same solution you used before.

The purpose of addressing the “Reinforcement issue” is not to discourage you from using your experience. It’s to motivate you to keep learning, unlearning, and relearning as an essential part of the Agile implementation process. You can’t assume that doing something a second time will be as successful just because it worked before.

Maintaining mindfulness and putting in extra effort are key to achieving success the second time around. One effective way to reinforce your Agile practices is through retrospectives.

Based on my personal observation, teams and even process engineers are often reluctant to conduct retrospectives. It’s considered a secondary or optional practice that is implemented only if there is enough time. However, gaining input from the team and working towards continuous improvement is the only way to ensure long-term success.

Figure 2

Pragmatism

The biggest mistake an Agile practitioner can make is attempting to standardize practices across different teams. Unfortunately, this is a common mistake made by Agile practitioners who are influenced by standardized models like CMMI and ISO, which emphasize replicating practices across projects.

I have no problem admitting that I fell into this trap myself. However, I quickly realized the drawbacks and the need for flexibility in practices among different teams.

After achieving success with one project and following a model that worked, there is a natural temptation to replicate it in other projects. While this approach may seem sensible in theory, it overlooks an important factor—the diversity of team psychologies. Not every team will be comfortable with the same practices. Without the teams feeling ownership and connection to the process, you won’t be able to achieve significant progress as a process facilitator.

Figure 3

Team psychologies are often shaped by the psychology of their technical leads, who are the opinion leaders. Their working style influences the team to a certain extent.

I want to share an interesting situation we recently encountered, which is relevant to organizations aspiring to be Agile.

The Problem:

We were following similar practices in two different products with two different teams, each with their own technical lead, product owner, and team members. Both technical leads were seen as equally competent and committed in their roles. However, top management started expressing concerns about one of the technical leads, noting that he seemed less in control and less involved in the product compared to the other lead.

Top management believed that his delegation of tasks and passive leadership style were causing major design flaws in the application. His experience and skills could have made a significant difference in the application architecture and user experience.

When we inquired about his lack of control over the team and the product, he explained that he was not happy with the standup and sprint planning meetings, which made him take a more passive approach to leadership.

Because these meetings were dominated by the product manager, who liked to micromanage the team members, he couldn’t take ownership of the technical solution after receiving the business requirements from the product owner. Exposing his entire team to the product manager was not favorable for him.

The Solution:

Initially, this problem seemed unsolvable because I believed that these meetings were essential practices in the SCRUM methodology. They are meant to facilitate teamwork and collaboration. However, after discussions with top management, we realized that “Process is there to serve people, not the other way around.”

If a particular practice is causing friction among key stakeholders or a loss of ownership for a technical lead, we must find an alternative solution.

Therefore, we came up with a customized version of SCRUM for that specific product. Instead of gathering the entire team and stakeholders for daily meetings, we decided to have representatives from each function participate in daily standups.

Currently, the technical lead represents the developers, I represent the testers as the QA lead, and the product manager represents the product owner. We meet daily to share the status of individual team members and discuss any issues or agendas.

Before the meeting, we review the task statuses of all team members and follow up with individuals if necessary. Sometimes, we even call team members to inquire about specific task statuses or assignments during the daily standups. Developers demonstrate their enhancements or new features to the whole team and stakeholders every week, which serves as the foundation for the sprint planning meeting the next day.

The customization of the standard SCRUM method might seem unconventional to those outside the context, and I understand that some Agile purists might not agree with modifying critical practices like standups and sprint planning. However, I mention this adaptation intentionally.

The key point I want to emphasize is that teams and leaders must take complete ownership of the process and the product, even on their own terms. There is a trade-off in terms of collaboration among team members, but we have implemented other practices to minimize this impact. While the previous strategy worked well for product A, we had to customize it for product B based on the team’s psychology at that time.

You may need to modify some standard Agile practices to make them work for your organization. Adaptation is inevitable. Don’t be afraid to be innovative! If necessary, create your own tools or practices from scratch, as long as you are convinced they will work.

Standardization

Standardization and discipline are just as crucial in Agile implementation as customization.

I might seem contradictory and confused, but it’s not a dichotomy. It’s about maintaining a balance between pragmatism and standardization, which is a universal rule.

In this case, the balance lies between being pragmatic and customizing practices and maintaining a level of standardization that ensures consistency and reliability. Endlessly altering recommended practices and guidelines to make them work in the short term is not sustainable. At the same time, being rigid and sticking to strict discipline all the time is impractical.

Figure 4

Standardization becomes crucial once you have customized a practice or tool to an acceptable and necessary level. For example, I have made it mandatory for my team to update their daily tasks before the daily standup meetings where I represent them.

They follow a standard format to list their tasks and statuses. Additionally, I have designated specific time slots for meetings between the technical lead and the product manager, which must be adhered to strictly and consistently. Providing further flexibility in timing or formats could lead to chaos given that we already compromised on the collaborative practice of daily meetings.

Standardization can be extended to an organizational level as well, beyond individual products. We can establish some golden rules that can be shared across the organization and even the industry as a whole.

To achieve organizational standardization, it’s advisable to share the good and bad experiences of different teams with certain practices. Teams should have the freedom, guided by the company’s experiences, to adopt or modify practices according to their needs and preferences. This allows for flexibility while maintaining a certain level of consistency.

To reiterate, finding the balance between pragmatism and standardization is an art learned over time, rather than from a book or an article.

Defining Roles & Responsibilities

One of the main challenges in an Agile-based organization is defining roles and responsibilities. Agile organizations typically have a task-oriented culture with flat hierarchies and a high level of flexibility and cross-functionality. This is well-aligned with the Agile process.

However, the challenge lies in transitioning from a role-based culture to one focused on tasks. Even within a task-oriented culture, some boundaries in roles and responsibilities are needed to avoid conflicts and ensure that expectations are met. It’s not practical or even desirable to hold the entire group or team responsible for every single action or outcome.

There’s a concept of “Collective Ownership,” “Self-managed teams,” and “Headless units” that promotes an enabling environment, but they are more of a underlying philosophy than a rigid set of practices. In reality, there are situations where someone needs to be assigned responsibility and held accountable for specific tasks and objectives. If you leave everything up to “anyone can do it,” you risk ending up with no one doing it.

Figure 5

Simply converting traditional roles into Agile roles by changing titles is a recipe for failure. Agile requires a shift in responsibilities and authorities that goes beyond superficial changes. Some roles have standardized responsibilities, while others are subject to organizational context.

For example, in our organization, we decided to follow the SCRUM methodology, which has standard roles such as Product Owner, SCRUM Master, Technical Lead, Team Members (Developers and Testers), and other stakeholders (product manager, top management, client, vendor, etc.). We assigned existing team members to these roles based on their closest function.

The Business Analysts became product owners while the Development Team Leads became technical leads. Other team members remained intact. As the initiator of Agile implementation, I took on the additional role of SCRUM Master to oversee the methodology and ensure it was developed and executed correctly.

All roles were clearly communicated what was expected of them. Product owners were responsible for coordinating with stakeholders to address their needs, views, suggestions, and concerns related to the product and plan product priorities and scope accordingly.

In the next and final article of this series on “Cultivating Agile in your organization,” we will delve deeper into this topic. We will cover further guidelines to help you continue making progress towards successful Agile implementation.