💡 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