๐ก Agile manifesto, divergence & convergence, career frameworks
Monday Ideas โ Edition #91
This edition is brought to you by ๐บ QA Wolf, which offers a cost-effective approach to getting 80% automated test coverage in just 4 months.
QA Wolf will build and maintain your test suite in Playwright (no more dealing with false positives or flaky tests) + provide unlimited parallel test runs on their infrastructure at no additional cost. The benefit? No more manual e2e testing, no more slow QA cycles, and no more bugs.
They have multiple case studies of customers saving $200k+/year in QA engineering and infrastructure costs. Schedule a demo to learn more.
1) ๐ The Four Values of Agile Manifesto
Last week I had Kent Beck on the podcast. Kent is one of the signers of the original Agile manifesto and we talked a lot about Agile, Waterfall, TDD, and engineering practices.
This is a good opportunity to look back at the 12 principles from the manifesto itself ๐ย with my own annotations.
I believe we can extract 4 major themes from it โ still very relevant today:
(1) Work closely with stakeholders ๐ฅ
Good communication with stakeholders is a primary factor in any project's success. Agile has long preached about keeping customers in the loop and welcoming requirements' changes, over clunky long term plans.
(2) Work in small batches & deliver incremental value ๐
Splitting work in small deliverables is key to the health of your development process. Small batches lead to frequent releases, which in turn make the feedback loop faster and reduce risk.
This virtuous cycle means that, counterintuitively, there is no trade-off between speed and stability in software. Higher speed brings higher stability, because it also brings faster recovery from failures.
(3) Give teams agency ๐
The best results I have witnessed in software have always been delivered by diverse, cross-functional teams who had the skills and trust to independently iterate over a product.
(4) Promote simplicity and good design ๐จ
Good design means minimizing the work to be done, both right now and in the future, and this mostly comes from good communication.
2) ๐ Divergence & Convergence
Following up on the principles above, breaking down work and getting frequent feedback isnโt enough to guarantee that you will ship the right thing in time.
For any sizeable initiative, there is additional work that spawns over the course of the project. Most of it comes from the feedback you receive: other features you may need, tweaks, bugs, etc.
This is healthy, to the point that you should get suspicious when this doesnโt happen โ chances are you are not getting enough feedback.
However, additional work can also easily derail deadlines and create friction with stakeholders on prioritization. My preferred way for handling this and set the right expectations is to break down the project timeline into timeboxed stages that look more or less like this:
50% โ Core features
30% โ Learnings + secondary features
20% โ More testing + bug fixing + final tweaks
Letโs make an example. Say you have a 6-months project for which you are working on the scope and requirements. You may identify a sub-scope of core features, on which to spend the first three months. After these three months, letโs look at the project status. Are you on track? Are you late? How much new stuff has emerged?
You may have now a backlog with:
Leftovers โ a few core items still to complete.
Secondaries โ all the minor features.
Learnings โ tweaks and additional features that came from the learning and feedback over these first months.
Together with stakeholders, you may re-prioritize these and figure out what to fit in the next two months. Finally, in the last month, you focus on convergence โ you do the final tweaks, more QA, and bug fixing.
Some FAQs:
๐ Isnโt this waterfall-ish? โ Nope, you are still demoing features every week, testing, getting feedback, etc. Itโs just that you do the most important items first, and timebox the various stages.
โ๏ธ What if my core features take more than 50%? โ you can go for it, but you should understand what you are leaving on the table. In my experience you canโt really avoid the final convergence on tweaks and bugs, so, if you want to stay in time, you are likely penalizing tasks that come from learning. This is usually not a good deal.
I wrote a full guide on planning and executing software projects last month, and it is literally the most popular Refactoring article of all times! ๐
3) ๐ช Career frameworks stages
In 2022 I wrote a two-part series about creating a good career framework for your team. These days I am doing a ton of research and talking with many people, as I want to create a completely revamped edition about this.
Two of the biggest challenges with career frameworks are 1) when you should introduce it, and 2) how complex you should make it.
My TL;DR advice is that the level of sophistication should match that of the problems you want to solve, and not more. So you can think in stages:
๐ฑย In a team of 5 people โ expectations are probably the same for everybody, and alignment means just writing down a fewย engineering principles.
๐ฟ In a team of 10-15 โ you may get away with creatingย 2-3 simple levels, with descriptions of a couple of paragraphs each.
๐ชด As soon as you have managers โ or leadership roles, you may identify a fewย core skillsย and write down the different expectations for the various jobs.
๐ฒ In a large organization โ you may try a moreย granular assessmentย of your peopleโs skills to help with internal mobility and the deeper career tracks.
You can learn more in the previous pieces ๐
And thatโs it for today! If you are finding this newsletter valuable, consider doing any of these:
1) โ๏ธ Subscribe to the newsletterย โ if you arenโt already, consider becoming a paid subscriber. 1500+ engineers and managers have joined already! Learn more about theย benefits of the paid plan here.
2)ย ๐ปย Read with your friendsย โ Refactoring lives thanks to word of mouth. Share the article with your with someone who would like it, and get a free membership through the new referral program.
I wish you aย great week! โ๏ธ
Luca







We follow the similar model of allocating 50% of the time for your P0s. This is great when the project is new. If the project is in later stages of development then there will be less distractions so taking on more "P0s" works out fine.
Good call on adding โwritten communicationโ to the โface to face communicationโ point. Basically โget in a Slack channel with your users/stakeholders where you can get quick feedback on ideas/proposals