What is it like to work in a really Agile environment?
For almost six months I have been working here at Clarity AI within a team where there is a strong culture regarding XP. And honestly I never had such a positive feeling since I’m a developer.
Many people may be wondering why I use the tagline of “really” when I talk about Agile. The answer is simple: for a long time I thought I was working in an Agile way when it wasn’t:
- I thought I was doing TBD (Trunk-Based Development) when we only deleted the develop branch.
- I thought we worked with CI/CD but we just deployed once a month.
- I did pair programming from time to time.
- Testing was optional, unfortunately rare and very occasional.
I don’t want to say that it wasn’t Agile either, but it may be unfair to make comparisons…
So what is it like to work in a team doing XP?
In the next paragraphs I’m going to explain the main changes in my day to day working in a really Agile environment in which change, exploration, refactoring and communication are really empowered.
Pair Programming
Getting used to working by myself for days (even weeks) and then passing the hot potato to another colleague as a Pull Request, now I’m always accompanied: most of the time pairing and always supported by the rest of the team. And I’m not just talking about code, everything is done all together (design, refine, create tasks, etc.).
Selfishly talking, it’s amazing being accompanied during the onboarding period. Seeing how the rest of the team thinks and works, not feeling alone and not being afraid to say “I don’t know”.
If something has become clear to me, it’s that this culture greatly improves communication. In a matter of days there is a huge affinity within the team, and the knowledge was shared across the team in real time.
Trunk-Based Development (TBD)
By default say goodbye to the branches.
There is only the main one and the whole team works on it making changes very frequently (in the range of minutes, never hours). This practice, which could be seen as irrelevant, is one of the most important changes that I’ve experienced.
With this way of working everything is simpler:
- Forget about maintaining an infinite number of branches.
- Almost zero probability of having conflicts (something that I personally hate and worries me a lot).
I also want to make it clear that for me applying TBD was one of the most complex things a team can face when applying XP.
Lastly, I would like to emphasize that in order to apply TBD safely and with confidence, a series of previous steps are needed:
- Treating tests as first-class citizens.
- Enforce dynamics such as the pair/ensemble.
- Working in a way that allows pushing to production anytime (parallel changes, feature toggles, baby steps with micro-commits, etc).
Continuous Integration / Continuous Delivery (CI/CD)
Being used to deploying once a week (even once a month), when I started working in the team and saw that with each push to main a deployment to production was generated (with an average of 15–20 pushes per day) my first reaction was disbelief.
- “Are you trying to tell me that we’re going to be deploying continuously all day and any time?”
- “Yes I am.”
Definitely positive at first sight, but I cannot express enough how important it is that, in order to implement this, the team needs a safety net in the form of a wide array of tests combined with the practice of applying very small changes. If this is not the case, as you may already be thinking, it would be a real chaos.
Vertical and Technical Slicing (Baby Steps)
We’ve reached the most difficult part to master and the area I want to particularly focus and improve in the short term.
In previous paragraphs I was talking about the fact that the team pushes to main on a very continuous basis. This is possible thanks to an enormous previous work where a user story is divided into smaller tasks that allow delivering value much faster. Because of that the feedback loop is very fast as well.
Slicing is also about simplicity and deferring commitment, going to the simplest and fastest thing that could bring value to our users and let us learn about the problem.
In order to make an average of 15 daily deployments, it is necessary to work with short iterations and without prior analysis and refinement of the tasks, this is not possible.
Conclusions
To finish, I just want to say that I feel very fortunate to have the opportunity to work in an environment where help is one the most important concepts, where feeling alone is not possible and where doing things following high standards is a MUST, not something negotiable.
But I am also aware of how difficult it is to reach this point in a team, in the great maturity that is needed to be able to apply all these techniques efficiently generating a lot of value.
That is why in the future I will always seek to be in places where this type of culture is the norm and not the exception.
I have nothing against pull requests but I truly believe that there are better alternatives like pair programming.
