For me, agile requires two things (see the-two-pillars-of-agile-software):
- A healthy knowledge culture focused on people (collaboration, learning, respect, team work, creativity...)
- Looking for quality and technical excellence (for example XP practices are a great starting point).
To introducing the healthy knowledge culture, I introduce retrospectives and worked as a facilitator, change agent and "Developer Whisperer".
 |
| In our profession knowledge is the bottleneck |
For the technical excellence I think that we should follow this steps:
- If there is a classic vicious cycle of bad quality or bad practices going on. We should stop and break this cycle immediately. The typical example consists in having technical debt, that generates bugs, that generate even more technical debt that ends in the complete collapse in few months.
- Assume that we have the capacity and very good intentions.
- Help to create a virtuous cycle to improve our technical quality day by day.
- To create this virtuous cycle we need to define a clear goal to align all of our efforts.
 |
| Vicious Cycle of technical debt :) |
In our case, and having in mind that we are a cloud native product, I thought that we can use Continuous Delivery as our team Goal.
Why Continuous Delivery?
The answer is that I thought that we require a good practice that force us to do the thing right and doesn't allow us to hide our unprofessionalism or incompetence. And for this, and in the cloud, I think that in our case Continuous Delivery will put a lot of pressure on doing the things right.
Continuous Delivery implies:
- Low cost and a smooth process for deployment that doesn't affect customers. This requires (or at least recommend) introducing DevOps, automation, rolling deploys and Continuous Integration.
- Having good confidence in our product. This requires Continuous Integration, Automatic testing, and Monitoring for production.
- Automatic testing requires integration tests and unit tests, and for sure, having unit tests put a lot of pressure on doing a good design (for example to have a hexagonal architecture or other architecture that decouple business logic from infrastructure).
So indirectly, trying to implement Continuous Delivery requires or recommend doing the following practices: DevOps, Infrastructure Automation, Zero down time deploys (for example rolling deploys), Continuous Integration (perhaps with trunk based development), Integration testing, Unit testing, Good Design (for example using hexagonal architecture).
 |
| Virtuous Cycle created when CD is the goal |
Continuous Delivery doesn't allow you to hide bad technical quality and force you to introduce good technical practices and work very hard to have a healthy code base.
With this approach, we, as a team, improve a lot our technical knowledge, our code base and our practices. We have to improve many technical practices but we have already come a long way and I sincerely believe that we are going in the right direction. :)
Extraball:
- If you use micro services, CD force you to think about independent deployability.
- CD force you to learn how to make parallel changes (using feature toggles, database refactoring, etc.)
- Some additional insights from @artolamola:
- Above CD you can implement any agile method for team organization (scrum, kanban, etc.).
- CD force you to think how to decompose each feature in vertical slices.
References:
Some of these ideas come from:- Competing On The Basis Of Speed Mary Poppendieck
- The Virtuous Cycle of Velocity: What I Learned About Going Fast at eBay and Google Randy Shoup
Some context about how I understand agile:
- Agile is not a recipe for success...
- The two pillars of agile software
- Remove the excuses for not being a professional
The history of the Honey Badger team:
No comments:
Post a Comment