5 Fundamental Questions To Test Whether Agile is Feasible For You (Part 2)

Dangers of Agile Technique and Efficient Ways to Counter Them – Offering a pragmatic perspective grounded in our comprehensive journey from initiation to fruition.

Reflecting on the prior write-up, my aim was to see how thoroughly convinced you are about the utility of Agile. I wish to clarify that I did not aim to thrust upon but rather highlighted plausible motivations that may prompt companies to embrace Agile.

However, the organizational intricacies are best known by the top leaders. If the reasons fail to sway them, there’s no logic in following a trend or adopting it half-heartedly.

Your confidence in the Agile manifesto can engineer its successful adoption across the organization. Speaking personally, the conviction needs to be vehement enough to the point of equating it to a parallel doctrine that needs to be accepted.

This paves the way for the following phase.

Assuming you are thoroughly convinced and wholeheartedly believe in Agile, it is time to probe its relevance within your unique organizational environment.

Your belief in the effectiveness and efficacy of Agile alone doesn’t guarantee your triumph. It needs to be congruent with your organization, project, teams, and executive framework.

As I alluded to in my prior piece, there are no documented instances of Absolute incompatibility of Agile with any organizational poise. Nevertheless, the object of this feasibility scrutiny is to validate the degree and peculiar form of Agile that are more fitting to a project or company.

It should also encompass a comparative evaluation of Agile against plan-centric methodologies for the success of a distinctive project.

For reference purposes, you may inspect the below figure that highlights reasons attributed to Agile project failures:

(Note: Click on the image for magnified visualization)

Figure 1

Here are a few significant questions that aid in addressing your main concerns about investing in Agile or not.

Clearly, there is no direct financial implication of the shift to Agile, but there is invariably an inherent investment associated with any sweeping change in the organization.

The expected differentiation in project value, timeline, and quality will be the determining factor for this decision.

Top 5 fundamental questions to ascertain the feasibility of Agile for your organization:

Q #1) Is there support for Agile from the Top management?

As is apparent, Agile devotes 80% to delivery, with merely 20% of exertions allocated to assessment, planning, and implementation. Therefore, it is vital to have the backing of upper management, who are primarily liable for project delivery.

Their agreement with Agile delivery should exceed merely being tacit; they should be enthusiastic enough to endorse the transition.

If their commitment to Agile is shallow and merely for the purpose of experimentation, they will most likely revert to conventional methodologies following a few setbacks instead of transforming them into victories through retrospection.

A major factor behind our successful Agile implementation was our president’s admiration for the Scrum technique used at Microsoft. As a Microsoft collaborator, he had numerous substantial discussions with top Microsoft personnel, which shaped his views about Agile’s viability better than any research could.

Figure 2

We had initiated talks about Agile implementation, but the ball didn’t actually get rolling until our president personally gave his approval. I presented him with certain bottlenecks, obstacles and the inherent risks associated with Agile, and, surprisingly, the obstructions began to dismantle sequentially through his executive mandates. From structural modifications to resource control to infrastructure impediments to workspace allocation, he proved to be supportive and accommodating about enacting necessary alterations.

So, if you are striving to persuade your upper management about Agile and they wish to assess your assertions, your chances of success may be in jeopardy.

On the other hand, if they are exuberant and zealous about facilitating your success using all accessible resources, and you hold onto a “never back down” attitude, you are more likely to overcome challenges. Continuous enhancement and learning are the sole pathways to unravel the most suitable Agile methods for your project, and there are no ready-made solutions.

Top leadership and you must continue to sustain the Agile perspective at all times, for the most gains. I would recommend assigning the responsibility of product development to one of your top leaders, who would then be the primary champion of this mission.

In Figure 1, note the significant portion of survey respondents who believed that their Agile deployment was unsuccessful due to withdrawal of management support.

Q #2) Can you transition to a Task-centric culture?

Corporate culture is a critical yet usually ignored factor that holds the key to Agile adoption, according to my experience. If you are resistant or unable to adjust your power hierarchy, it’s highly unlikely that Agile can be adopted in its genuine spirit.

There exists a widely accepted classification of organizational cultures as outlined below:

There are four distinct types of organizational cultures, primarily characterized by the distribution of power within the institution. Most software enterprises following traditional methodologies follow a “Role” culture, also known as bureaucratic culture.

This type of culture insists on strict adherence to the organizational power structure and top-down power and information flow. Designations are rigidly defined resulting in excessive paperwork. Agile aspires to transition the pre-existing cultures in organizations, including Role culture, to a Task culture, as it’s the only culture that aligns with the Agile manifesto.

Figure 3

The shift from other cultures to a Task culture signifies a radical transformation for any workplace. It will invariably face resistance from those who stand to gain from the alternate power structures, most notably middle managers in the case of Role culture.

In our company, as I vouched for transitioning to Agile, I observed a trio of middle-ranked managers who felt insecure about surrendering power to self-organized teams, Agile/Scrum masterminds, and product guardians.

Even if functional managers are assigned the designation of Scrum master or product owner, they don’t experience as much control as they do in their traditional roles, like development manager, QA manager, and Business Analysis manager. Their command over resources and decision-making prowess is seemingly diminished.

As a QA manager, I also grappled with such initial apprehensions. This realization is relatively easy for me to admit, but if you interrogate other functional managers, they are unlikely to concede to this reality. My personal drive and inclination towards Agile guided me to shoulder an additional Scrum master role for the successful enforcement of Agile.

If you are a startup, this may not pose a big problem. However, for an existing organization intending for a transition, you would need to reassure the functional managers that there are indirect benefits to delegating power, and they would be equipped to perform their functions efficiently by customizing practices as per the demands of separate teams. But implementing this is easier said than done.

Q #3) How big are your projects and what do they entail?

A common misbelief about Agile adoption is that it entails a straightforward “Yes” or “No” answer to this inquiry. In truth, you cannot outright dismiss or completely endorse Agile. Instead, you need to assess whether you can implement it in varying degrees for different projects and the relevant Agile variant that fits each project.

After persuading the top leaders to support Agile, I was keen to execute it across all projects immediately. However, things didn’t pan out as I had envisioned. I swiftly realized that the appropriateness of Agile needs to be assessed not just at the company level but also at a project level. Practically speaking, enforcing Agile principles uniformly across an organization is not possible.

While numerous variables impact the enforcement of Agile within a project, project scale, and characteristics deserve special attention.

If the requirement details and timelines are clearly laid out from the outset and are largely unvarying, then moving to Agile may not yield significant advantages when compared to the risks associated with a dramatic organizational change.

Agile has proven effective for software projects wherein requirement specifications evolve over time, which is true for most but not all projects. Furthermore, for large-scale projects, you must adopt a large-scale Agile methodology with a high degree of complexity and a correspondingly elevated level of associated risks.

The project scale also aids in deciding the suitable Agile technique to adopt, as shown in Figure 4, derived from an academic assessment of varied Agile techniques.

(click image for a magnified view)

<img class=”alignnone wp-image-8147″ src=”https://iptvassist.com/wp-content/uploads/2021/12/Agile-testing-4.jpg” alt=’Agile methods and project size’ width=”650″ height=”398″ srcset=”https://assist.micro

Related