As a developer, I was fortunate enough to be part of a team at Rabobank Lending & Insurance that grew from a relatively new team, to a team that could, all but literally, move mountains.
During that time, we've tried things that improved the performance of our team… and things that didn’t!
Let me share some of our successes (and failures) with you, all tried and tested on the working floor battlefield. Expect stories about team dynamics, coding discipline, openness to learning new things, and much more. With any luck, there might be takeaways for you to bring back to your own team.
6. From 2021-01-01,
If you’re younger than 35 years,
You don’t have to pay 2% property transfer tax when buying a house
PROPERTY TRANSFER TAX
A TYPICAL STORY IN LENDING AND INSURANCE
8. TIP #1: JIT (JUST-IN-TIME) KICKOFFS
• Whole team involved (that includes business)
• 2 hours max, timeboxed
• Team creates global design on-the-spot
• Team identifies sub tasks (round robin or ad hoc)
• Go to work immediately after finishing the kickoff
• All work on the same story (or max 2)
11. From 2021-01-01,
If you’re younger than 35 years,
You don’t have to pay 2% property transfer tax when buying a house
PROPERTY TRANSFER TAX
if under the max price
if under the max price
21. • Minimize Performance Test
• Minimize chaintest
• Share chaintest responsibility
HOW TO SOLVE?
Build
Build
2 mins
Quality
control
Quality
control
4 mins
Deploy to
Test
Deploy to
Test
1 mins
Flight check
Performance
Test
5 mins 10 mins
Minimized
chain test
22. TIP #4:
KEEP YOUR PIPELINES
FAST AND STABLE
BY ELIMINATING UNNEEDED JOBS
AND MINIMIZING FLAKYNESS
31. TECHNICAL DEBT BACKLOG
• JIRA-123321: Refactor internal structure of calculcations service
• JIRA-645948: Cleanup unused mode fields
• JIRA-843834: Upgrade Guava to new dependency without
vulnerabilities
HOW TO SOLVE?
36. STORY TODO IN PROGRESS DONE
Property
Tax
Rename
getCalc
endpoint
Push down
business
method
Encapsulate
calc method
Implement
FE
Controller
Bring Calc
ToProd
Map output
From Calc
42. No, that button is
two pixels too far left
Let’s put it in production,
Good enough for now
43. TIP #8:
HAVE A GOOD MIX OF
PERSONALITY AND EXPERIENCE
IN YOUR TEAM
44. SUMMARY
1. Do Just-In-Time kickoffs
2. Have at least one PO that is always available
3. Create T-shaped developers by pairing different disciplines
4. Do team code reviews
5. Keep your pipelines in great shape
6. Technical Debt should be zero at all times
7. Drop rituals that give you no added value
8. Have a good mix of experience and personality in your team
So hello! Welcome to J-fall!
Question for all of you to ponder upon: were you ever in the position to be lucky enough to be in a team that could, quote on quote, just “get shit done”? Where every sprint you could move mountains, and burning stories seemed effortless?
I was fortunate enough, and humbled, to be part of such a team at Rabobank, that, to me, grew from a “normal” team to a team that could really get shit done. We did a lot of continouous improvement, failed often, but eventually we made the team perform better and better. So today, I’m going to share some of these improvements that worked for us really well, with you in the form of some tips, that you hopefully can cherrypick and try out in your teams as well.
I’m Michel Schudel, a software engineer 20 plus years in the business, and I’d like to share things I’ve learned, either technical or non-technical, through blogs, articles and conferences, and I’m really glad to be on a stage again today. You probabvly can find some videos of me on youtube about Java, Cryptography, stuff like that, and if you’re interested in my tech ramblings, there’s my twitter account, follow me if you like.
Sso, just to giv
-
e some background information
Tell about the area
Tell about the applications we build
Explain the team
So, at Rabobank Wonen, we use Java 11, soon to be 17, Kubernetes, Microsoft Azure for our repo’s build pipelines, Elastic for logging, Kotlin’s on the way, awesome tech stack.
But I’m not gonna talk about those things today. Instead, I’m going to take you on a journey through one of our sprints, what problems we stumbled upon, what we did to improve things and made us work better together
So, we had to implement this functionality in one of our mortgage productss. It’s a law change that after 2021, you don’t have to pay property transfer tax.
As, what we had in the beginning was refinement of and epic or story, and then three weeks passed and we started working on it…. Having forgot about half of the context and details or why we made certain decisions. So we had to ref-refine, or dig up again why we had made certain decisions… huge time waister.
Now, you wonder, there is no planning poker in here. We’ll get to that later. Now, the benefits of this is:
Everyone in the team gets a shared understanding of what needs to be done
The context is fresh in everyone’s mind so no need to re-iterate what needs to be done at a later point in time
So, tho give you an example, this is how it basically works:
So. Now we’ve got the of the way and can start working on the story itself. It goes excellent!
So, we had to implement this functionality in one of our mortgage productss. It’s a law change that after 2021, you don’t have to pay property transfer tax.
So, let’s look at the PO …. Joehoe…. Where are you, PO?
But product owner is nowhere to be found. Sounds familiar? Well, in our case he was on vacation or something like that. But that really hindered our story.
So how to solve this? So, what we did is making sure there is always someone available to answer questions. In our case it’s a backup
Do team code reviews. How
So, We had something like this… a couple of backend programmers, one or two frontend programmers.
How, I told you that we all work together on the same story. So, that presented another challenge for us: because sometimes, there is no frontend to be built, either in the current story or the next one. Same goes for frontend-only stories because we had a bunch of backenders sitting “I’m not gonna touch that frontend, stupid stuff” or the other way round “stupid backend stuff”
So, maybe we need to fire everybody and replace them with these kind of guys. Well, until you come to the conclusion that this person doesn’t exist.
But what you can do is at least try to get some knowledge across that isn’t in your comfort zone, so other people besides just you can work on an issue. So, we started doing this:
For each frontend task, we started pairing a backender with a frontender. The backender was in the driving seat, while the frontender made sure he didn’t wander astray. Same for backend work, except the roles are reserved. Now of course, you have to be open-minded for this as a developer, otherwise it won’t work. But when this works, you will end up with something like this:
So what happens then, is that the area of knowledge moves closer together. So, now you have frontenders that can handle a lot of backend work, and backenders that can churn out a screen or two. Now, the knowledge doesn’t completely overlap, but that’s not needed. This is what’s actually called T-Shaped developers, who have their core competence, but have no problem tackling issues outside their comfort zone.
Do team code reviews. How
So, let’s talk code reviews. How many of you do code reviews on pull requests? Or peer-to-peer reviews? Not saying that is enough, but…
Do team code reviews. How
It’s a little hard since we have this mortgage product structure that doesn’t really fit into what we’ve been working on the last few months… etc
So, do you reconize this? It’s called technical debt.
No, not this guy, although I could think of several code smells that I could use him as an anlogy… I’m talking about this:
This is a quiagmire. I didn’t know what the english word meant, but it means you will venture into this thing and go slower and slower…. until you come to a virtual standstill…. But still moving! So this is even more dangerous.
And technical debt will show up as vulnerabilities on a tool like Sonar, for example. Oh god, 152 code smells,
So we had this: technical debt backlog. Is this familair? Yes, the problem is that you don’t know what technical debt *exactly* holds you back from completing a story in a fast and concise way. So, we started doing it differently: by making sure that we didn’t have any technical debt to begin with.
So, how did we solve this?
Audience question: who has technical debt stories on your backlog?
Now sometimes you have to put debt on your backlog, because you depend on another team, or maybe have some expand-contract story you cannot fix immediately, but try to keep that to an absolute minimum.
So, now we have tackeled all the technical debt, and things are starting to look really sunny.
…and then we a got a scrum coach! From now on, I will manage your scrum needs! Why don’t you do planning poker? Eh… because we don’t need to. Everybody on the team has been in the team long enough and we’re pretty predicatble at this point. Yeah but how long does something take? Ehr… what about velocity? We can compare it with other teams? Ehr… no… you can’t.
Bottom line of this message is: while still keeping an open mind for suggestions, don’t go through the motions of your favourite agile method just because you need to.
Do team code reviews. How
So, let’s talk about team dynamics for a moment. That’s where I want to talk a little bit about team dynamics and team compositon, because it proved crucial for us as a team to be able to work together optimally.
Do team code reviews. How
So with that, I hope I could give you some pointers as to make will make your team fly, hope you enjoyed this presentation, if you have any questions afterwards feel free to look me up as I’ll be here all day attending session, and have a great J-Fall!