Background

Agile as a Soft Skill

Agile is not just a method or a set of principles for software development; it can also be considered a type of soft skill.

While the waterfall model can be characterized as plan-driven or process dogmatism, Agile could be deemed as experimentalism. Rather than getting bogged down by "work for work’s sake" such as planning or processes, Agile prioritizes quick exploration and learning.

Of course, not all tasks can be covered by exploration alone. Once things become "visible" through exploration, it’s necessary to move on to a phase of proper execution, which is challenging to achieve through mere exploration.

Not Every Engineer Has Mastered It

For engineers, being agile is probably something you practice regularly. You may think, "I must have mastered this."

But is that really the case?

What we are discussing here is Agile as a soft skill, not in the context of development. Even if you practice Agile development as a developer, there’s a possibility that you haven’t mastered Agile as a soft skill. To see if you have mastered it (this is just one indicator), please read on.

Organizing Agile as a Soft Skill

Articulating Agile as a soft skill is not an easy task. Simply conveying what we engineers use won’t suffice, as it’s too specialized and lacks broad applicability.

This is where Soft Skills Engineering comes into play. As a current engineer and the proponent of this concept, I have made an attempt to put this into words.

In true Agile fashion, I’ve quickly articulated some thoughts.

Casual Agile

Casual Agile is about organizing Agile as a soft skill, and it includes tips for practicing Agile casually, as the name suggests.

Currently, I’ve prepared five tips, but there could be more. It might be beneficial for a collective gathering of engineers to compile suggestions, similar to an awesome list. It could also be organized within teams or organizations, allowing each to reflect its unique culture.

Let’s dive in.

1: 3R Cycle

The flow of Agile can be aligned with 3Rs.

• 1 Rough Plan
• 2 Run
• 3 Retrospective

In the Rough Plan, you create a rough plan. It’s fine if it’s just a rough idea like, "We’ll do something like this." Neither Excel nor spreadsheets need to make an appearance; you should be able to manage with text. It’s a caution sign if spreadsheets do show up.

Next, guided by the Rough Plan, you proceed to take action. This might involve brainstorming, discussions, document writing, or of course, implementation. Perhaps understanding is lacking, leading to book reading, engaging with stakeholders, or conducting other research. Essentially, anything you think of, you do. You exercise initiative. The Rough Plan is just a guide; it’s okay if things don’t go as planned.

Finally, there is the Retrospective. After finishing the Run, you reflect on it and consider the next steps. This is what we call the 3R Cycle.

Simply put, the 3R Cycle is "determining roughly what to do, working until reaching a decent stopping point, and reflecting on how it went before repeating the process."

This should also be understandable for generative AI. You probably throw in rough prompts, experiment based on them, and once you reach a reasonable stopping point, you reflect on your progress. It’s the same principle.

2: Mechanical Style

When presenting messages or materials, in the past, people used to prepare them diligently (PowerPoint), or in a rough manner (plain text or a page in notepad). However, now you can also showcase something generated by AI, particularly chat sessions, as they are.

This is referred to as Mechanical Style.

• When humans prepare diligently: Formal Style
• When humans prepare roughly: Rough Style
• When relying on AI outputs: Mechanical Style

Since Agile is exploratory, surprisingly, it doesn’t necessarily need to be Formal or Rough. There is a lot to learn from merely viewing AI chat sessions, and they can convey subtle nuances. In fact, if someone is too passive to even look at the chat session, they cannot handle Agile.

This can also serve as an indicator to assess whether someone is capable of engaging in exploratory behavior through Agile.

3: Affordable Loss in Effectuation

Effectuation is an agile theory that presents five principles, with one being Affordable Loss. It’s about setting a line on resources where "up to this point, it’s fine to expend them completely." In essence, it’s about being limitlessly used.

This straightforward concept aligns well with Agile. Being limitless means no management occurs. If you provide resources up to the Affordable Loss line, it’s as if you’ve discarded them from the onset. It might be cumbersome for a resource manager, but it’s incredibly gratifying for someone moving Agile, as freedom is crucial for exploration. Management is a hindrance.

4: Advice Process

In teal organizations, there exists a concept known as the Advice Process.

It consists of two main points:

• Advice can be given without having decision-making rights
• To prevent runaway decisions or critical failures, advice must be sought

Traditionally, advisors were often superiors, making advice tend to become orders. However, in the Advice Process, advisors do not hold decision-making authority. This means the person receiving the advice can make their own decisions. For instance, one can ignore advice they find mediocre.

Nonetheless, guardrails are put in place to prevent unilateral actions from the person receiving the advice—meaning the fundamental principle is that advice must be sought. This is more significant than what it appears, often leading to rules in teal organizations where "those who intentionally continue to not seek advice become subject to dismissal."

5: Monitoring Over Management

The importance of developer experience has been recognized. Moreover, I have authored an article titled Beyond Productivity: Embracing Experiencity. Just as waterfall has become outdated, management is heading in the same direction.

This feeling is succinctly expressed in Monitoring Over Management.

Monitoring involves satisfying both of the following:

• 1: Automatic measurement. It should be assessed automatically
• 2: Factor-based. Treat it as a factor, not a goal

For automatic measurement, it means no human entry or inquiry; it occurs automatically. The reason for automation is that manual daily entry by humans is tedious and inaccurate, making it prone to becoming a mere formality. However, full automation isn’t always possible.

For instance, if you want to monitor "the number of interruptions" as part of Engineering Effectiveness, automatically recording this might prove challenging. A simple button for counting could be implemented instead.

Regarding factor-based, it means not turning measured indicators into quotas. Think of them as logs. They’re just "factors" to look at and refer to during retrospection. It’s not about creating KPIs that you desperately strive to meet.

Conclusion

We have introduced Casual Agile, presenting Agile as a soft skill.

Particularly, I have shared the five tips that I have prepared. I hope you gained some understanding of the essence of Agile. I encourage you all to explore your version of Agile, be it individually or within your organization! Until next time!