Leonardo de Campos Almeida

Code ownership is a culture problem, not a technical one When a group of teams with roughly twenty engineers writes and supports a codebase, but only two engineers can approve changes to its core parts, it can look like a sensible technical constraint. Someone needs to protect quality. Someone needs to make sure new features do not break production. Someone needs to preserve the history and context of the system. All of that is true. But over time, having only a few engineers act as code owners can reduce quality instead of protecting it. Not because those engineers are doing a bad job, but because the ownership model changes how everyone else behaves. ...

The Three Months We Stopped Pretending: A Kanban Story My team was doing Scrum because that’s what all the cool kids were doing. Then, on a Monday planning session we were struggling to fit a list of unrelated tickets into a 2 week planning, then I heard the infamous affirmation: “this ticket is a priority and needs to be delivered by Thursday”. I had heard it so many times before, but this time I had enough and I realised that this was no longer a Scrum process, it was a mix of a bullet list of objectives and wishful thinking. Looking from outside, it looked like a Scrum methodology, the planning was there, the review, the grooming, and retrospective were there, we meet daily to do stand-ups, but these had become just part of the week, without adding the value they should, and everybody was ok with it, nobody said anything. So I said it wasn’t working. ...

Using DISC to defuse team conflict (not resolve it) We’ve all been there, joined a new company, and a few months later are asked to fill a behavioral questionnaire with hundreds of questions. Then we get a very nice report about ourselves, some things match, some don’t. We read it, and go back to writing the next feature. I did the same, more than once. A few years later, in a big company that ironically didn’t have any of these questionnaires, I saw how useful it can be when managing different people. ...

What waterfall taught me about agile I worked for one of the largest banks in Brazil back in the day, with everything that entails, waterfall processes, PMBOK training, commercial proposals, weekend-long debugging, wearing a suit and tie. I’ve learned a lot, and don’t regret doing any of it. Nowadays, waterfall is used as a cautionary tale. It’s the project management process that we don’t speak about. Back when I was in the middle of figuring out long-running projects that ran inside of the banking system, for a bank with tens of millions of customers, it was just how things were done. PMBOK and waterfall are the way projects are executed in most businesses, so naturally a bank, whose main concern is about making sure that everyone’s money is secure will lean towards it. ...