What makes a high performance team tick?
•Download as PPTX, PDF•
0 likes•138 views
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.
Recommended
More Related Content
Similar to What makes a high performance team tick?
Similar to What makes a high performance team tick? (20)
More from Michel Schudel
More from Michel Schudel (16)
Recently uploaded
Recently uploaded (20)
What makes a high performance team tick?
- 1. WHAT MAKES A HIGH PERFORMANCE TEAM TICK? Michel Schudel MichelSchudel 8 tips from the development trenches
- 2. Rabobank Lending & Insurance, tribe “wonen” 500 people, 20 teams
- 5. 8 TIPS TO IMPROVE THE PERFORMANCE OF YOUR 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)
- 9. Make FE Controller Bring Calc To prod Map output from calc Acceptance EXAMPLE Story Design Subtasks Property Transfer Tax Story
- 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
- 13. HOW TO SOLVE? Backup PO Business analyst
- 14. TIP #2 HAVE A PRODUCT OWNER (OR BACKUPS) THAT ARE AVAILABLE ALL THE TIME
- 17. Update UI Work on calculations Mentor Driver’s seat Driver’s seat Mentor HOW TO SOLVE THIS?
- 19. TIP #3: PAIR DIFFERENT DISCIPLINES TO GROW T-SHAPED DEVELOPERS
- 20. Build Build 2 mins Quality control Quality control 4 mins Deploy to Test Deploy to Test 1 mins Performance Test Performance Test UI Chain Test UI Chain Test 45 mins 20 mins • Performance test is too long • Chaintest is too flaky BUILD PIPELINES
- 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
- 23. CODE REVIEW
- 24. HOW TO SOLVE?
- 25. TEAM CODE REVIEW
- 26. TIP #5: DO TEAM CODE REVIEWS FOR EVERY STORY
- 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?
- 32. TIP #6: Have ZERO technical debt at all times
- 33. KEEP ISSUES AT ZERO
- 34. CODE SMELLS
- 35. ID SMELLS DURING TEAM CODE REVIEW
- 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
- 38. TIP #7: KEEPING BEING CRITICAL DROP RITUALS THAT GIVE YOU NO ADDED VALUE ASAP
- 41. The Coordinator The Plant The Implementer The Perfectionist The Investigator The Team worker The Researcher “Let’s do this story first and make a design” “Let’s do GraphQL!” “Get shit done” “Let’s try out Quarkus on a prototype” “It’s all in the details boyz” “How did the other teams solve that?” “Can we call work on this story together?”
- 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
Editor's Notes
- 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!