Suggestions
Blendor Sefaj
Marketing manager & co-founder @Cloverlabs.io 🍀
I really enjoy looking for new solutions to given problems and connecting with different people along the way.
Highlights
I came to the conclusion that I should write more, so I'm starting a new series called "It Took Me a While, but Now, I Get It."
My first thought is: "Technical excellence and agile methods are not excluding concepts - they complement each other."
Throughout my career in SW dev, I worked with numerous people. In almost every case, we practiced some form of agile practice: scrum, kanban, scrumban, "our own thing," etc.
We followed the good practices, we did the work - and yet, we still faced issues. We occasionally missed a deadline or two. Bugs were still there.
We blamed everything & everyone:
- the "incompetent leadership",
- "newbie project manager" (in a lot of cases, me),
- "egoistic senior devs" etc.
No matter the complaints, the problems were still there. I first thought that the issue lay in the tools, so we switched from tool X to tool Y.
There were no drastic changes - except more time to get used to new workflows/UIs.
Then it was methods turn - so we went from scrum to a home-brewed-sprint-marathon: same thing as earlier.
"It's probably a people problem - the team doesn't work hard enough." Nope, we're putting in more than enough effort. New issues, regularly.
Slowly, I was getting to a point where I felt lied to about agile. Working? No, that's just a ploy to sell more books/courses!
It looked impossible - then I figured it out: agile and technical excellence go hand in hand. They're like dance partners, each making the other better.
The cool thing about agile is the movement: regular check-ins and sprints are about more than just delivery.
They're opportunities to learn, innovate, and refine our craft. It's like a built-in growth engine.
But here's a catch: to be truly agile, you need a strong technical foundation—codebase, architecture, people. The stronger the base, the more flexible and adaptable you can be. These things give us the confidence to pivot when needed.
I've seen & been part of projects that obsessed too much on either of the sides. Perfect architecture? We slowed down, delivering less, missing opportunities on the market and rushing through sprints. We built things that felt & behaved "shaky" -> extra work down the road.
The lesson learned the hard way? Balance - balance is essential.
So, how do we balance technical excellence and agile methods? Everybody has different approaches to it - for me, I've found that these activities work very well:
I'd suggest to:
- Encourage learning in sprint retrospectives
- Build in time for refactoring
- Celebrate both technical and process improvements
What strategies have worked for you so far?
Most SW companies fail to maintain the quality and pace of development after the first two sprints. They start off strong, then slowly slide into "completing tickets" instead of "building products."
Why? Because their culture is one of running sprints, not marathons. How do we fix this issue? By creating a continuous learning culture.
Your team does stuff, makes mistakes, and learns from them. It's that simple, right? Well, there's a catch: this feedback loop only works if you do it regularly, at a constant pace. How do you implement it?
In the last few months, my team and I built an AI-assisted personal productivity tool. Just like any project, the start was a bit rough: new technologies, learning new concepts, finding our footing, etc. Then we decided to test out a couple of new things. We wanted to see how much better and faster we could get while remaining practical, committed to good practices, and calm.
We decided to learn through collaboration and view minor stumbles as learning opportunities, which is our main goal for this project.
We thought that the following tactics represented the best our values, so we opted for:
- daily pair programming sessions,
- weekly presentation of research/findings to the rest of the team,
- blameless post-mortems after incidents.
We selected these tactics based on several factors, with the most notable being that we had a diverse team of developers working together in the same location, ranging from juniors to seniors. This allowed us to speed up the feedback process, which is especially important for less experienced developers to gain valuable learning opportunities.
Did it work? Yes - for most of the time. Why? Because we're humans, no one/nothing's perfect. There's constant work involved, especially when working with multiple people in different stages of life: alignment, pacing, searching for compromises, etc.
Based on the whole team's experience on this project, I can confidently say that a step towards a continuous learning culture is a step towards a healthier future: for the people, team, codebase, product and more. How do you keep your team continuously learning?
