Experiences of a Tech Coach
Experiences of a Tech Coach
Disclosure - This article is for my future self, it is way too long and at some point it may make no sense to you, handle with care š.
July 2022 I started working as Agile Technical Coach in Sunweb. It was the beginning of a discovery journey for me, as it was gonna be my first formal experience as a tech coach. This post tries to tell that story.
Finding the job
First of all, landing the job was an experience on its own. On a given day, I went for dinner with Josep Serra and Quim Rodriguez (friends and ex-colleagues from Sunweb who still worked there) and Roger Bramon (friend and ex-colleague from Sunweb who is not there anymore). At some point, the topic of me going back to Sunweb appeared, and without thinking a lot about it I said that I would be open to rejoin the company but only if I had a technical coach role (I was really looking forward to try that - more info in this blog post).
A couple of days after that dinner, Josep and Quim shared the idea with Ariadna MartĆn and Oriol Pueyo (IT managers in Sunwebās Girona office), who were thankfully very open to talk about it. Altogether, in a few sessions, we defined the role and afterwards, thanks to their perseverance, they were able to make it happen. The role didnāt exist in the company and the department of People and Culture struggled to understand its purpose (and price).
After some conversations we agreed to make an experiment: I had a handful of months to demonstrate the role was viable business wise š.
These were the responsibilities of the role as we defined them:
An important thing to mention here is that, even though I was really eager to try to become a tech coach, I was super scared to see if I would be able to contribute as a coach to the people in Sunweb (I trusted I could, but anyway the fear was there and the impostor syndrome was kicking in full throttle).
BTW, I was happy to negotiate a relationship that respected my trend of a 4 day/week contract, which was supposed to give me some time to work on my personal brand on Fridays.
Introducing myself as Agile Tech Coach
So here I was, back in the company, which changed a lot but still had plenty of familiar faces, introducing myself as Agile Tech Coach. Most of the people in IT had never been exposed to a tech coach, so the first thing I did was book an hour with every team so we could get to know each other and to explain what would be my role from now on.
These are the topics I spoke as part of that presentation:
Why a tech coach?
Because of Agile hangover. IMHO the company was a clear example of hangoverness, they had at least 3 Agile coaches during their transformation and none of them ever spoke about technical practices (I knew it first hand, I was there).
I really emphasized my understanding that the creators of the Agile Manifesto were mostly tech guys who had awesome tech practices which are at the foundation of being able to be Agile, and that the fact that their transition to Agile didnāt have any of those into consideration wasā¦ well, letās call it a perversion of the system š.
The catalog of activities I was intending to experiment with
- Coaching teams with the Samman Method - at least I had the intention to, but in the end I only used some parts from Samman.
- Mentoring - In case someone wanted to.
- Brain picking - My head was available for anyone who wanted it.
- Facilitating - Holding meetings, retros or any activity that would benefit from a facilitator.
- Training - I had a bunch of trainings ready to be consumed, so I exposed the catalog. Had a personal dilemma here to be fair, should I offer them for free? Cheaper? In the end it was not a deal breaker and they only asked for one training which I did for free.
- Katas - I wanted to introduce the katas as an opportunity to raise the level while at the same time mixing people from differents teams
- Reading club - I did it in LIFULL and I found it really useful to spread knowledge and align people at a conceptual level.
Disclosure, I didnāt invent anything here, this was mostly a mix-up of what I had seen in LIFULL Connect with Manu Rivero and what I read in Emilyās Samman Method book.
Other sources of info
Apart of those meetings with different teams, I also did:
Poll to whole IT department
I sent an individual poll to everyone in IT. The poll had a twofold purpose:
- To learn about them. The topics I asked for were technical (perceived skill in refactoring, dealing with legacy, TDD, ā¦) and personal (preferred way of receiving feedback? And praise? How can I help you when youāre grumpy? Can I do anything to be a better ally for you? ā¦).
- To share about myself. I did so by providing in the poll my answers to those non-technical questions š.
This poll and the spreadsheet with the answer became a good ally to me. I recall using it several times before giving feedback or praising someone, and I kept using it every time I started coaching a new team to quickly grasp how the people in that team would prefer to be treated. Poll was never mandatory as it wasn't anonymous, but most of the people were answering it.
Organized some katas
I scheduled a couple of katas so people could start experimenting with them. This was an excuse to expose myself so they could see what I could offer them in their day to day work and also a way to realize what was the current level at the company. For example, I discovered that I overrated their TDD skills based on the poll answers thanks to this exercise.
Organizing the katas was also interesting as I discovered that it was gonna be harder than I expected to engage with the developers, I had multiple flawed assumptions about communication:
- People would read Teams channels
- People would read emails
- ICs would be eager and empowered to join sessions.
None of them were true, at least partially. After a week I had an answer rate of less than 20%, so I started asking around if people were aware of the proposal. Answers ranged from āI donāt have timeā to āI donāt read emails or teamsā or āI need to know more about this to understand if Iām interested or notā. At the end of the day I got a full house in both initial katas, but it was thanks to me pursuing people but not about the formal company communication channels š .
Finding a team to coach
After the first couple o of months, I was starting to settle in. It was about time to start focusing on a team š. The IT organization was organized in 12 teams more or less split in two big blocks, 6 in Girona working on the websites, apps and their backends, and 6 in Rotterdam mostly working in the company inner guts (booking system, package configuration, finance, etc). To decide which were gonna be the first teams that I would coach, I sent an email asking for volunteers. This was the final format of my email after 3 iterations:
During my stay in Sunweb, I looked for teams to coach using this strategy 3 times:
- The first time 3 teams volunteered, I coached two of them.
- The second time 5 teams volunteered (2 of them were the teams I coached the previous quarter which tried to repeat, repeating customers are always good news š), I coached one.
- The third time 5 teams volunteered (nobody attempted to repeat, the warning about having lesser chances of being chosen that we introduced maybe had something to do with it, so these were 5 new teams. An increase in demand is also supposed to be good news š).
Deciding which would be my next coached team was always done in a conversation between me and IT Managers, where we took into account the company strategy, importance of projects, team capacity of slowing down, my potential for contribution/impact and other factors (nothing quantitative here, this was very opinionated).
Fake until you make it
Preparing myself to start being a coach
I had plenty of opportunistic coaching moments in the past, thatās how I discovered I liked doing this, but coaching had never been a full-time job for me. Wondering if I could bring value on a sustained and on-going basis was one of my biggest concerns, and this was fuel for my curiosity.
Soā¦ how does one become a coach? (and especially a good one?). I didnāt know, all I had seen so far was my experience in LIFULL Connect with Manu Rivero (and very briefly with Pedro Santos) and reading Emily Bache. What I had seen in those places made very good sense, but I was afraid of the gap between those persons and me (I was pretty confident about their ability to coach, but not about mine š„µ).
Reading
I decided to read some books to catch-up on that, I went for:
-
Extraordinarily Badass Agile Coaching - Interesting take on Agile coaching, especially on the non-technical part but a little bit too āseriousā about coaching for my taste. Probably because the author has a level of coaching consciousness that Iām still far away from.
-
The Coaching Habit - This book is really short and easy to read, it contains a couple of ideas that I incorporated to my 1:1s and individual coaching sessions.
Talking to other coaches
I also tried to speak to as many coaches as I could get the hang on, I stressed the dial of networking to a level I had never tried before, and the results were quite surprising. I met online and talked to people like VicenƧ GarcĆa-Altes, who linked me to Pedro Pardal.
I also joined the Samman Society Open Space event multiple times where I met a lot of interesting persons with whom I had the chance to talk about coaching in a place where I always felt welcome and safe to share about my problems and topics that worried me. Over there I met Olof Bjarnason and Nitsan Avni, with whom is very easy to have very stimulating conversations š¤Æ.
Samman coaching was helpful in many areas, not only because of the open spaces, but also because of the wonder of materials they share in their website (katas, learning hours, trainings, ā¦). IMHO, those materials are good for coaches and non-coaches (I strongly think that those materials make a way better training course for an IC than a lot of the things you can find around).
Coaching baby steps
My first hands-on coaching experience with teams was a flop (surprise! šÆ). Based on the idea of what Emily Bache explains in the Samman method, where she works with two teams at the same time (mob with one in the morning, mob with the other in the afternoon, shared learning hour with both in-between), I decided to start with two as well (no mobs though, I would gently start with some pairing to gain some confidence) .
As my availability was limited to 4 days/week, we agreed with my managers to dedicate 3 days a week to those 2 teams, and keep the fourth one to the rest of the IT organization so everyone could benefit from technical coaching thanks to katas, mentorship or brain picking.
This turned out pretty unfeasible. Brain picking quickly became my most used service by non-coached teams but since most topics ācouldnāt waitā, my agenda was scattered with interruptions. On top of that, the context switching between the two teams was a pain in the ass, both for me and for them, so my flow and my contribution to them was lousy (Iād like to say that their patience and understanding with me was remarkable).
After a month and a half, to reduce context switching, we decided to iterate the experiment to a āone week per teamā mode and to me pushing back harder on some brain-picking questions (can this wait until Thursday?) and pre-blocking some slots in my calendar with āteam timeā. This improved things substantially, and based on this experiment I upgraded the format a notch: next quarter only one team would be coached.
Even though all the problems just described, these first months as a coach (where I was totally faking until I made it), I started to gain confidence in my coaching skills. Among others, these are some of the topics I worked with those teams:
- Introduced characterization testing and extract and override/ Peel & Slice
- Parallel change
- Improved ease of usage of Git thanks to interactive rebase
- Introduced mobs and explained better pairing practices
- Started TDDing with some peers in the teams
- Setup SpecFlow tests with a controlled data store.
- Introduced Approval Testing
- Raise awareness of code strongly smelling to primitive obsession and other code smells
- Refactored some codes to design patterns
- Help a team setting up their first load test
Being able to help those teams by introducing some of those ideas, seeing the reactions and observing the adoption, helped me move past the āfake until you make itā phase into the feeling that āhey, I think I can do this hereā (the here was important for me, here š).
At the end of the quarter, I made a retrospective with each team, and I got out of those sessions thinking that teams were happy with the coaching buuuuutā¦ the impact was not clear š. Letās say itās nice to learn things, but there was a lack of clarity on how those learnings would be internalized and what would be the ROI of the coaching investment after I moved to another team.
Anyway, somehow it was clear for the IT Directors in Girona and Rotterdam (Ari, Oriol and Martijn Bottermans) that the Tech coach experiment was a success and the role of a tech coach was viable business wise. At least I had one thing less to worry about.
Extending the tentacles + When Life gives you lemons
Around that moment in time, more or less when I was finishing my first coaching period, I got a proposal to join a workforce to change the company culture. This initiative had the support of the CEO and was lead by two fantastic women with whom I had (and Iām still having) very enriching conversations (order doesnāt matter): Lisa de Schepper and Rishita Jonas, and the potential to allow me to seat in a table I always had plenty of curiosity for, impacting the organization as a whole while bringing the point of view of the Tech part of the company.
Also during that time frame, live decided to give our home some lemons and I turned down the offer (which required some traveling) to make lemonade instead šš. Doctors diagnosed my wife with breast cancer and we decided I would stop all my traveling and Friday projects until we managed to go through the situation (which is the case as I can happily say š„³šŖ). In this regard, I really would like to give a huge shout-out to the people in Sunweb and the organization, they gave me plenty of facilities to cope with the situation at home.
Luckily for me, the opportunity appeared again after a while in an online friendly mode, teaming up with people like Jonas Friismose, Leslie Folker, Santi Malinowski, Oriol Pueyo and John van Straten. Unluckily for me, although the team and context seemed to have a lot of potential, the initiative didnāt go very far. Due to an unfortunate chain of events, the company got into crisis mode and they decided to save some money here.
Still, I have very fond moments of that group and the conversations we had, plenty of expertise from different angles in the room, among others, I learned Lean stuff from John, heard for first time ever about Garret Model from Lisa, did a lot of introspection and learnt some new dynamics with Rishita and, of course, enjoyed the infinite energy of Jonas š.
Dropping the Agile
At some point in my experience in Sunweb, I started interviewing Agile coaches as we were looking for a new one. Considering the sums most of them were asking for, I was expecting people with a broad set of excellent skills, and I may say that I was disappointed with what I saw.
As part of this process, I formed an opinion that, based on the sample of people I talked to, thereās a bunch of people who hopped onto the Agile hype train and made a living out of it. Most of my sample had very low experience (if any) with the technical side of Agile, and at the same time felt very comfortable ātelling teams how to improveā thanks to their knowledge of other topics.
At some point, I decided to change my self-defined title to āTech coachā instead of āAgile Tech coachā as I wanted to dissociate myself from that kind of proposition (very respectable, just not my cup of tea. IMHO most of the useful feedback I can give is thanks to my personal experience developing Software and based on a holistic understanding of the system).
All that being said, I must say I did really work with some Agile coaches whose contribution I highly valued and respected, specially Santi Malinowski and Oriol Pueyo. For a while, we teamed up and we were able to move some cross-team initiatives (mostly methodologic and cultural) and we had an insane amount of deep conversations about the org culture and how to influence it in positive manners (according to our opinions, ofc). I cherish those conversations and all the learning I got in them. Itās so easy to see all the areas where you can still grow when working with such professionals (thanks a lot fellows!)
Staffing
If you recall my list of responsibilities, I had one bullet point which said: āEventually be injected into a team to initiate or help on critical projectsā, kinda staff engineer style.
Wellā¦ a critical project happened to benefit a lot from my skills while most of the company workforce was under a lot of stress due to that project. After discussing the case with the IT Managers, we decided that until the go live of that project (a month and a half away), I would stop coaching to focus on helping build and orchestrate a cross-team load test that involved multiple APIs from several teams.
Almost all teams working on the project were swamped due to the big bangish deadline and I helped them create the load tests, analyze results and discuss possible improvements and solutions to the different bottlenecks we identified (a lot of circuit breakers involved). This was possible thanks to the introduction of dark launch, which wasn't on the radar until I joined the group.
The relevant part of this anecdote is not in the project per se, but in the fact that one of the values of having an internal coach is that it can be seen as pre-built slack in your organization, which at that moment in time seemed to be very useful.
Back to coaching
After the staffing period ended, I moved back to coaching so I looked for another team. As I told you, this time we decided to focus on one single team. It felt like a whole different story, I recall this coaching period was way less stressful and with more flow to go deep with the team.
With this team I got a couple of interesting learnings:
- They were trying to move a conversion metric and I tried to sell them the idea of making an Opportunity Solution Tree to approach the problem. (I failed miserably, changing ways of working of people is not as easy as making a workshop š„µ)
- They were revamping a considerable part of one webpage and I advocated for AB Testing the impact of the change (I failed miserably again and I generated a lot of frustration in the team, as some people got really invested in the AB test that didnāt happen š)
- They were stuck trying to test something āuntestableā. I started mobbing with them and showed them how to introduce seams and setup some tests, but then I went nuts on my own branch all alone because the mob was too slow and after a couple of days, I came back to the team with the āRefactored codeā (added seams, tests with approval testing, refactored via lift up conditional and then factory+polymorphism). I had a lot of fun, and it made for a very interesting conversation afterwards with them, but that code was still lingering in a branch when I left the company, I even made an internal talk at some point explaining the whole story, the name of the talk was āHistory of a failed refactoringā š.
After that team I worked with a third one for another quarter, the experience was very similar, so I wonāt delve on that more (have you noticed the article is very long already?)
Experimenting with Coaching styles
Look, in general, I have a hard time imposing my opinion, especially if Iām coaching and weāre talking about some code or problem which is not mine and I will leave you with it. With that premise I never shoved my ideas down the teamās throat, sometimes, I was given a NO, and I had to live with it. I lived these situations with frustration, IMHO some of these NOs prevented the team from growing. A lot of times, these NOās were very contextual, in a short something like āI love your idea but we wonāt try it here because we have all these impedimentsā.
To try with a whole new setup where this was not a problem, I organized an experiment during one of our Tech Labs (days dedicated to personal growth around technology, think a little bit into a hackathon with open topics).
The experiment was as follows:
- With me strong coaching and imposing elections in case of misalignment
- We would create a project from zero (we chose a project to measure DORA metrics)
- In a group of persons following the way of working that I wrote
- Pairing or mobbing was enforced, with swaps of persons in the pair on an hourly basis
- Driver rotation every 10ā top
- Shared code ownership, every pair was entitled to change code without asking others
- Retrospectives every 4 hours (the Tech lab was 2 days)
- Refactoring and Pre-factoring was valuable
- Longest time without pushing to trunk allowed was 20ā
- Trunk based development
- ATDD and TDD was enforced
In an excess of generosity, I allowed them to choose how to deal with the breaks š.
So, we started with a small theoretical introduction to ensembling and ATDD as not all of them were familiar with them, and afterwards we mobbed our first ATDD test, defined together the architecture of the solution (very Lean) and made it work, ready to go to production in one morning š!
Going through that exercise together allowed the team to become comfortable with the codebase, and after a morning of working we were ready to start splitting the ensemble into pairs. Before doing it though, I shared some extra tips on how to pair (in contraposition to mobbing).
At the end of the second day, we were all pretty amazed with how the team was working smoothly and together, hereās a summary of some of the numbers they achieved:
- The person with the team with less commits had 8
- We made around 50 builds in two days
- They had a test bed that was covering all the features they developed in a human readable way
(sorry for the bad quality of the image)
And I think in general, the team was pretty happy with the outcome!
I have to say though, that even with the good results of these strong coaching days, I struggle switching my coaching style š , I guess at some point I should try in a real environment instead of such a synthetic experiment.
In those Tech labs, I did other minor experiments worth mentioning, like Willem Larsenās Mob RPG (super funny, heard about it in Samman Open spaces) or setting up some codespaces in my katas so they were easy to quick off.
Other activities
Outside of coaching teams and working on delivery, there were some other activities I held during this period in Sunweb:
Mentoring individuals
I mentored 5 persons during my year and a half in Sunweb. Mentoring maybe is too strong of a word, as I ājustā had a 1:1 with them every month and a half or so. My impression was that they were happy (they were repeating customers and said so in the semi-anonymous polls I shared with them - sample is so small it was hard to anonymize, so I just asked for numbers).
Most of the time the conversation was about their potential growth, books they could read or talks they could watch. I had fun and I made some friends along the activity, so worth it :)
Invite people to Sunweb
I always had the feeling that Sunweb is a little bit of a closed ecosystem, so I tried to push some boundaries by inviting people from the outside to tell us about their experiences, I managed to invite 3 persons to whom Iām very grateful:
- Aleix DomĆØnech from Funda, came to share his experience about being a Staff Engineer. In Sunweb the role of Staff engineer didnāt exist, but several were persons interested in becoming one. Aleix testimonial was specially relevant as he worked for Sunweb in the past, is Catalan and working in Netherlands (Sunweb is a dutch company)
- Jose Carlos Gil from LIFULL Connect, came to explain a mini introduction to Non Violent Communication, which in turn incentivised the reading club to go for Rosenbergās book :)
- Clare Sudbery came to Sunweb to experiment with her āLift up conditionalā conditional Learning Hour. I met Clare in Sammanās Open space and it was a pleasure to learn from her (also, it was an excellent opportunity for Sunweb people to see a real tech coach in action š)
Reading club
I organized a reading club and we read:
- Radical Focus 2.0 (Christina Wodtke)
- Measure what matters (John Doerr)
- Microservices Patterns (Chris Richardson)
- Non Violent Communication: A Language of live (Marshall Rosenberg)
In order to spark some conversations, I read the agreed chapters and took some notes with the intention of mapping the contents of the book into the reality of the organization (not always a good idea, believe me).
That being said, itās worth mentioning that even though the reading club started as a tech reading club, a lot of non-tech books were the ones chosen by the attendants (we dot voted most of the choices). As you can see, we went through a phase of OKRs in the org (recall that cultural shift I was talking about) and somehow reading the books helped settle some ideas, on the other hand I had the impression that it also generated frustration, as they were not used in the end.
After OKRs we moved into Microservices patterns, which wasā¦ too long and almost destroyed the reading club. The lesson I learned here is that 500 page books are not the best option for reading clubs, as hard as it is to keep people engaged. Finally, Iām super happy about reading the NVC book, to me that one is a game changer in human relationships inside an org.
Overall, our assistance was around 6-7 persons per session, and the best of it was that the mixture of teams and opinions in the room, for me it was a valuable cross-org connecting point and a conversation starter :).
Organizational disalignment āļøāļø
At some point in time, there was a lot of churn in the management of the tech team. Both Ari and Oriol, the persons who brought me on-board and made the bet for a tech coach, were out of their roles (Ari and Martijn left the company, Oriol moved into the coaching team luckily for us) and a new CTO joined the company explicltly stating that she didnāt envision coaches in the org, as coaching was part of the duties of team leads.
With this new setup, my personal alignment on some of the practices (cultural and technical) that were promoted from the new management team made it very hard for me to feel comfortable and valuable in that setup - to put it simply, sometimes I felt like I was a pain in the ass for some people.
Other times, in the past, Iāve been pretty quick at pulling the trigger to jump ship, and I think Iāve learned from those that thereās crap everywhere and, in general, itās worth trying to fix things. I tried to have some conversations on my concerns about Sunweb, also I took it slowly in appreciation of all the excellent friends and professionals that I have in the company plus for all the facilities they gave during the illness of my wife, but nothing changed. At some point I gave up and had a serious conversation with Manel IbaƱez (Voxelās CTO) with whom I had interleaved contact for a while and it was very easy to find the alignment I was lacking in Sunweb.
Iād like to think the conversations with Sunweb were not a complete waste of time/energy, after I left Sunweb management changed and they seem to be shifting again into healthier cultural practices (luckily for them IMHO).
Conclusions
These are some of the results of a poll I did run just before leaving the company. The poll was answered by 31 persons (around half of IT):
- 22 developers
- 4 POs and an architect
- 2 Others
- A manager
- A Uxer
- An architect
Also, 16 of the answering persons had been in the teams I coached, and the remaining 15 had not.
ā ļøWarningā ļø - Thereās a strong selection bias in this poll, I was leaving the company (for second time) and totaled 8 years working there, a lot of the persons who answered the poll are probably friends of mine.
One of the major questions was if people would recommend me as Tech coach (classical NPS). I had 1 single detractor, which happened to be a PO who didnāt know about my services š¤·āāļø, and 24 promoters š„³.
The next most significant question to me is one that I borrowed from Emily Bache, where I ask people if they felt an impact on different areas thanks to my coaching:
If you take some time to look at those numbers, youāll see that thereās a bunch of people for whom the question doesnāt seem to apply (non-developers I guess but I still wonder about teamwork).
To simplify the numbers a little, I decided to remove from the equation the persons for whom the question didnāt apply, and to merge in one single group the persons who said Raised awareness and things are slowly changing, my team is more likely to do this in the future and Noticeable improvement (as they were the ones positively impacted by the coaching).
After adjusting those numbers, the result is worth checking! Except for TDD (which has a decent 40%), in all other disciplines at least 65% of the people to whom that knowledge apply, felt that the coaching had a positive impact for them and/or their teams!
Iām really happy about this number, and I think this is one of the reasons people should be considering a tech coach in their org (think about it at least!).
The last question I want to share was an opportunity for them to let the company know if they were interested in more tech coaching. Consistently with the rest of the answers, they were indeed interested in one.
The poll assessed other activities like katas, reading club and others, the sentiment was the same all over the place (I have the full form and I donāt mind sharing it in case someone is interested).
In general, people were happy, and they were very grateful which is something I could also appreciate in the comments. This was fulfilling and validating for me. While the impact was not clear from a quantitative point of view, specially at a RoI level for the company, the purpose I had to help people grow seemed to be achieved (maybe on an individual level more than on a team level, still I was happy with that)
So whatās next? How to improve from here?
An unanswered question for me would be how to measure ROI of coaching, and the ideas I have revolve around DORA and Space metrics, also considering team happiness, retention, flow and business success. Other ideas are about tracking the usage they make of the practices introduced during the coaching period, but this seems too fine grained.
Anyway, another learning that I take with me is that coaching needs some degree of sponsorship (that I had in the begining but I missed after a management change). Some needles can be moved, but you need institutional support and more than one person (or more time, or someone more capable than me) to change things for real, otherwise the feeling was that I was sticking to some patches here and there but organizational gravity was removing them quickly after.
To be fair, it is also probably significant that the company has not hired nor looked for another tech coach, even though the coached people seemed to be interested in one š.
All that being said, it was an awesome ride, one that I expect to repeat some day with even more energy and tools. Thanks Sunweb for #creating memories!
Appendix
Sessions facilitated
I was able to experiment with lots of sessions during this period in Sunweb, this is the list of some of them (pretty sure Iām forgetting a handful):
-
Katas/Learning hours
- Vending Machine approval kata
- Git Interactive Rebase
- Tire Pressure Kata
- Theatrical players
- Scientist Kata
- LH Load Testing
- Attack calculator kata
- Trunk based development (this was a failed experiment, someday I may pick it up)
- Tennis
- Primitive Obsession
- Keyboarding skills
- Lift up conditional
- Refactoring Golf
- Law of Demeter with refactoring tools
- LH on micro commits
- Beckās rules of simple design
- Tic tac toe kata with object calisthenics
-
Other trainings/sessions
- Mob programming RPG
- The DORA retro with some nice twists from Oriol Pueyo
- Elephant Carpaccio
- Pair programming
- Mob programming
- Unit testing workshop
- Slicing
- Talk about VS and ReSharper shortcuts (the repo)
- Skill matrix
- Stakeholder mapping
- SWOT team analysis
- Opportunity solution tree
Hero image created with Microsoft Designer.