Unlock the Power of Low Code, No Code: Revolutionizing Development

Measuring the Agility of Agile

Agile methodology has gained widespread popularity in the realm of product development. However, it is notable that there is a lack of discussion concerning the potential drawbacks associated with Agile. While it is widely acknowledged that the vanilla Agile methodology may not be the optimal fit for all product development endeavors, there remains a subtle disclaimer that suggests “Heads I win, Tails you lose” – meaning: if a product is successful, Agile methodology is often lauded as the key contributing factor, while if issues arise, the issue lies not with the methodology, but rather with the need for the individual or team to better align with Agile process.

My tiff with Agile methodology is that successful product development cannot rely solely on the process. Although product development methodologies like Waterfall, Kanban, and Agile stress the need for a systematic approach, the truth is that success ultimately depends on the skills, motivation, and timely completion of the people working on the project. Agile, in particular, does not measure the abilities of the people’s, potentially leading to quality issues, dependencies on specific individuals, and delays in product roadmap delivery.

To build a successful product that adheres to timelines, a solid process is necessary, but it must also account for the evaluation and adaptation of the people ‘automagically’. Here are a few things that need to be catered to while building a robust product that doesn’t slip on timelines!

To have a quick reference point, Agile advocates these 5 steps – Ideation, Development, Testing, Deployment, and Operations in an iterative loop.

Process redundancy with People Mastery

During ideation, there may be different solutions for a task or feature. The traditional approach to ideation involves a single authority figure, such as a Scrum Master or Project Manager, making critical decisions such as whether to build a monolithic or microservice-based application, the architecture of the product, and the deployment process. However, this approach is inherently flawed, as it is dependent on the expertise of the individual making the decision and the associated risks, such as team technical expertise, go-to-market timelines, and budget constraints.

To address this issue, a process must have built-in redundancy supported by People Mastery. An ideal ideation process would involve a discussion where team members engage in a debate, for instance, on the choice of architecture or language. Rather than making decisions based on votes or experience, team members should be tasked with developing a competitive proof-of-concept to test their theories. By allowing team members independence in selecting technology and architecture, they have a chance to showcase their mastery and even venture into uncharted territory, promoting creativity and innovation.

While you may argue that this approach is time-consuming and costly, it is better to be safe than sorry. Moreover, healthy competition between teams can be advantageous, leading to a more thorough evaluation of different logic, process flows, and corner cases, ultimately resulting in a more robust product. This also brings life and enthusiasm to the team because they have a chance to prove themselves. This healthy competition during ideation and development ensures process redundancy and keeps the team motivated, as the system tracks their mastery.

Process Resilience with People Autonomy

During ideation and development, multiple solutions may emerge that appear to address the same issue, but their respective metrics may be quite different. For instance, some members of the team may favor pair programming while others do not. Another case in point is relying on automated tests instead of manual testing, which is especially important when the contract (APIs, integration, etc.) or the UI structure is frequently updated.

The procedure must be sturdy but flexible. What this means is that there can’t be just one way to accomplish the objective; rather, there should be a variety of methods. Here, people’s autonomy comes into play. Empower individuals and teams to follow their approach as long as the expectations are met with specific metrics in mind. Clarity is required in the definition of test coverage, API metrics, and scenarios, among other things. We require an API response time of less than 200ms and test coverage of 85% or higher. The results must always be consistent and idempotent each time. Results should not change in multiple runs with varying loads and different scenarios (automation or manual).

Overall, the key is to strike a balance between process resilience and people’s autonomy. While a solid process is important for achieving consistent results, giving individuals and teams the freedom to choose their approach can lead to more creative and effective solutions. Clear metrics should be established to ensure that the desired outcomes are achieved, regardless of the approach taken.

Process Accuracy with People Performance and Endurance Quotient (EnQ)

In the above quest for process redundancy and accuracy, it’s important that the people’s autonomy and mastery must be measured and tracked regularly to ascertain the accuracy of the product meeting the expectations set. While process accuracy can be easily evaluated based on product or customer expectations, evaluating people’s performance can be subjective and difficult.

Tracking people’s performance is solvable – along with the autonomy and the responsibility to complete a task or feature, the person or pod must also specify their Endurance Quotient.

Endurance Quotient (EnQ) is a ratio that can help the team push or prove its potential.

The EnQ framework is inspired by artistic sports like Diving or Gymnastics, where the difficulty level is pre-decided and considered as part of the final score. Using the redundancy model, pods can compete with each other on the EnQ. For example, Pod-A wants to use Golang for a particular defined task and Pod-B wants to use Java.

The task/feature effort estimates are calculated in the same way they are in any Agile setting: a developer of “meet the standard expectations” caliber finishes the work within the allotted time, with a buffer of perhaps 5 to 10%. Included in this time commitment are the quality metrics (test coverage, etc.).

Now, here is the interesting part: each pod knows its “team caliber” and bets on it! In addition to the effort timeframe, the pod sets a delivery timeframe. While all pods share the same effort estimate for a given task or feature, their delivery timeframe will vary depending on their own caliber.

Endurance Quotient (EnQ) = (Effort in Hours) : (Delivery in Hours)

Higher the endurance quotient, the higher the calibre of the team.

For example, a task has an effort estimate of 180 person-hours. 

  • Pod-A has a team of 3 people, and delivery commitment is 3 calendar weeks i.e. 3 people * 5 days * 8 hours/day = 120 hours.
  • Pod-B has a team of 2 people and the delivery commitment is 2 weeks. i.e. 2 people * 5 days * 8 hours/day = 80 hours.

EnQ Pod-A: 180 : 120 i.e. 1.5
EnQ Pod-B: 180 : 80   i.e. 2.25

If both pods are able to complete their tasks in their given delivery timeframe and meet the quality metrics, you not only have redundancy built-in but also get to measure the team’s calibre. The product can incorporate any of the solutions or maybe a combination of the working solutions but the effort from both teams does not go in vain. Not only is the product getting better, but so is the efficiency of the team!

One may argue that it’s understood that having two teams removes the dependency on a single team. But is this always feasible? Can’t the tech and architecture all be decided in the initial phase and let only one team work on it with high EnQ? Well, to identify the EnQ, we should initially start by asking different teams to solve the same problem or develop the same functionality, especially in situations where there are divided opinions about the approach. Now, though obviously, it’s important to reiterate that the process is followed correctly—documentation, code coverage, and test coverage are critical in all these cases as part of a complete delivery—if this is missed out in the initial stages of planning, it can be detrimental to the product!

Once the EnQ of different team members is known, it can be used to decide the allocation of work. High-priority or critical tasks go to teams and people with higher EnQ.

Over a period of time, it will be clear which people on the team are the high performers because their EnQ is high. The quality of the product AND the team increases, and hence the overall return on investment for the product improves!

In summary, Agile methodology with people-focus works! It’s important for a process to have redundancy, reliability, and accuracy. To achieve this, it’s important to have people who are given autonomy to use their mastery and push their limits using the Endurance Quotient as a measurable metric for their performance. A win for everyone!