The agile approach has become the de-facto standard in our technology industry. However, it seems that in certain situations, it does more harm than good.
The backdrop for this article is Oskar Dudycz’s article “When Agile is not enough” —Oskar rather firmly addressed several agile work practices. I wrote a few tweets in response to the article at the time—today, I have prepared a broader response based on them.
Agile Work
(An image from Henrik Kniberg’s article “Making sense of MVP”)
Some of our development work requires a rather fluid approach to solutions:
- We are not entirely sure if the solution we want to deliver will meet the client’s needs, but
- We understand the goal we want to achieve by creating a solution for the client.
In such a situation, there are not many (if any) examples of how to organize our idea into actual pages and forms. We are not sure if we are collecting all the required information. But most importantly, we do not know how the client will react. The proposed solution is only a guess.
In this scenario, we should focus on very quickly testing the solution to see if we are on the right track. We receive feedback from users and adjust our solution accordingly. We deepen our understanding. Hence the agile approach.
Barry O’Reilly writes excellently about this approach in his article “How to implement Hypothesis-Driven Design." Barry described how to use uncertainty to learn from new examples and create better solutions.
Non-Agile Work
(An image from Oskar’s article “When Agile is not enough”)
On the other hand, there are problems where we are almost certain about what we need to deliver. This usually concerns more stable business areas, such as:
- Time tracking—how to account for the work of a person with a specific contract.
- Accounting—how to handle invoices and calculate taxes.
- Warehouse documents—regulating how to manage stock levels.
- Country-specific legal rules.
- Mathematical and physical calculations.
We have specific input and output for our process.
Or we may want to implement a sufficiently large component that should have certain properties. David Jeske, a former director at Google, describes such an approach when working on their systems (and has a few words against the agile approach).
In these cases, it is better to approach the analysis in advance to ensure that we finally deliver the required mechanism/process. Knowing the entire process helps us create appropriate abstractions that we would not be able to create by working agilely. Or their implementation would require discarding current work.
Such work methods are becoming increasingly popular in various companies. This is evident through:
- The popularization of the Shape Up approach by Basecamp, which involves working in 6-week cycles. Rafał Makara describes this in detail on his blog in a series of articles.
- Descriptions of work methods of typically technological companies in Gergely Orosz’s article “How Big Tech Runs Tech Projects." Essentially, these companies avoid Scrum.
- The growing popularity of work based on project documents like Google Design Document or Uber RFC.
What to Choose and When?
In one product, we can encounter different types of problems. The question arises: when to choose which approach. We do not want to apply one approach to every problem. It will end in disaster.
To analyze which approach to choose for a problem, you can use Wardley Maps:
We divide our business area into smaller components that make it up. Then we add the dimension of market stability. Based on this, we can assess which solution to apply in a given situation:
- The more to the top left, the greater the emphasis on agile approaches.
- The more to the bottom right, the greater the emphasis on non-agile approaches.
Another way to divide it may be the Cynefin Framework:
Where we divide our business area into 5 domains: Obvious / Complicated / Complex / Chaotic / Disorder. Then we apply the appropriate approach.
But note what needs to be done first. We must analyze our business area to decide that we will solve a specific problem agilely (or not). In the case of a large area, such analysis will not be quick. The question is whether this is an agile approach or not?
Lack of Design is Even Dumber
Simon Brown, the creator of the C4 model, starts his presentations on architecture with the quote:
Big design up front is dumb. Doing no design up front is even dumber.
I really like this approach—it shows that there is no one way here. The question is how much of this design to do? Simon strongly promotes the approach from the book “Just Enough Software Architecture: A Risk-Driven Approach," which can be summarized as follows:
- Identify the main project risks.
- Prioritize them by the likelihood of occurrence and impact.
- Design the solution to address the main risks and reduce them.
- Stop designing when the cost of reducing the risk is higher than accepting it.
This approach allows us to use more complex methods when the situation requires it. However, for simpler problems, you can go completely agile and focus on programming.
Organization—How to Go Nowhere
And everything I wrote above may be just a dream if your organization operates only in one work style:
- Everyone is agile—we work in short two-week sprints, but then drastic changes emerge that could have been avoided.
- Everyone is waterfall—we plan the entire solution from A to Z, but then reality punches us in the face and forces changes.
In such cases, proposing a different approach will make us feel like heretics.
To work in a diverse way, the team delivering the product or functionalities (not just programmers—all roles) must accept that there is no one default approach. Sometimes you need to approach more agilely, sometimes less #ItDepends.
And I think we will lack such an approach for a long time. But we need to educate, which I try to do with this article 😉
